Thursday, September 07, 2006

Getting email through: SenderID, DomainKeys and SPF

I've been trying to see how I can stop Google from tagging my email as spam. Only Google, which has the worst spam filtering in the industry, has this problem. I've been looking into what's available in terms of sender authentication. Alas, things are not in great shape. There are 3 options currently:
  • DomainKeys: "cryptographically proves that the mail did in fact originate at the purported domain, and has not been tampered with in transit." Supported by Yahoo, Google, and, I think, Earthlink.

  • Sender Policy Framework SPF: Wikipedia - "SPF allows software to identify and reject forged addresses in the SMTP MAIL FROM (Return-Path)". Spammers, however, were early adopters of SPF. SPF has been championed by AOL.

  • SenderID: was a combination of SPF and "Caller ID". Unfortunately Microsoft has the relevant patents and they chose to use those patents to attack open source software. The result was the rejection of SenderID. (SenderID also uses SPF, so it's "SPF + Caller ID")
SPF has an open source implementation, but it's not encouraging that it was widely adopted by spammers. Also, AOL is not a great champion. SPF isn't enough by itself to bother with.

SenderID has the advantage of Microsoft's support, but the Wikipedia article makes it sound awful on several levels.

That leaves DomainKeys, which has been adopted by Google and Yahoo. Yahoo owns the key patent, but they produced an open source type license.

I have two ISPs: VISI and Lunarpages. VISI doesn't do support any form of email authentication (they promised to put my request on the list), but Lunarpages supports SPF -- unfortunately SPF doesn't seem to amount to much.

I get the sense that first rank ISPs will support DomainKeys, and that corporate pressures may force support of SenderID too -- no matter how ugly it is. In the meantime, I'll just encourage my ISPs to look at DomainKeys more seriously.

iusethis.com: some interesting products

iusethis.com has some interesting products I'll check out:

1. Memtest check system memory. Highly recommended for new memory or when buying a used system. Freeware.

2. code collector: manage code fragments

3. Alarm clock II

4. Google maps Plugin

Wednesday, September 06, 2006

Retrospect Pro needs internet access to backup my LAN

The program formerly known as 'Dantz Retrospect' was a mainstay of the Mac community in the 1980s and early 1990s. Sometime in the late 1990s, when the Mac was really dying, Retrospect ran out of steam. By the time the Mac flamed on again, Dantz had lost its mojo; the application never got the care and feeding it needed and the customer base never returned. (In fairness to Dantz, the 21st century Mac is a consumer product and Retrospect was a SOHO/corporate solution.)

Now the decaying remnant of Retropsect is owned by EMC Insignia. I still use Retrospect Pro, but I don't know anyone else who does. There are few Amazon reviews and no respectable reviews anywhere else. No decent blogger confesses to using it (ok, there's me, but I'm not decent). There are no free downloads and no user forums. It's fair to say that EMC is simply feeding off a decaying user base.

All of which is by way of introducing a curiousity. I recently terminated NAV and installed a trial version of Microsoft OneCare. That means I have a better firewall than I used to. Today I found that Retrospect Pro had hung during a LAN backup. The firewall told me that it had blocked Retrospect's acccess to the net. I allowed access to Retrospect and the backup resumed.

Retrospect uses an internet registry to find the address of machines it backs up. That's how it can do backups across a WAN. One day, of course, EMC will give up and turn off that service. I think there's a workaround (hard code the IP addresses probably), but it is interesting to see examples of remote application disabling that date back to the 1990s.