[Previous entry: "Backups"] [Main Index] [Next entry: "Blogging on the installment plan"]

03/02/2004 Archived Entry: "Now my email needs ID?"

Time to kiss another slice of your privacy goodbye... in the name of "protecting the children", of course. I'm referring to Microsoft's recently announced "Caller ID for Email", which is apparently just a variant of SPF, a proposal that has been circulating around the Internet Engineering community for some time.

Here's the problem with both Email Caller ID and SPF (Sender Policy Framework): both are intended to prevent "spoofing" of the From: address in emails. Both overlook the fact that there are legitimate reasons to do this.

When you send email, you send it through an SMTP server (Simple Mail Transfer Protocol), usually provided by your ISP (Internet Service Provider). The SMTP server is a computer which is attached to the Internet, so it has an IP address. This IP address is attached to your outgoing mail (you can see this if you look at the headers of an incoming mail message). This is not under your control.

Your email also carries a "From:" and/or a "Reply-To:" address which you supply; this is under your control. "Spoofing" an email address means putting something phony for the "From:" address. This is easy to do. I can tell my email program to mark my messages "From: billgates@microsoft.com" if I want. Spammers do this so you can't reply to them, and you can't filter messages based on where they're from.

Why would a "legitimate" user want to do this?

Here's how SPF works, as near as I can figure it out. Domain owners designate a list of IP addresses (the "SPF list") from which they send mail. So as the owner of the "zetetics.com" domain, I would publish the IP addresses for every SMTP server I use. When an email is received, SPF looks at the originating server's IP address, then looks at the user-supplied "From" address, and asks that domain name if it uses that SMTP server to send mail. The answer can be "yes", "no", or "don't know" (no list has been published). If the answer is no, SPF concludes that the sender (SMTP server) has forged the From: address.

Now consider some of the problems with this.

1. Can't use email aliases or email forwarding. Many email forwarding services exist. These are very useful for people who don't own their own domains: you can switch ISPs and still receive your email. To invent an example, suppose I use the address brad@ieee.org. If I try to send mail from home, using my ieee.org address, it will bounce: ieee.org doesn't know my sending IP address. To fix this, every organization that does forwarding would have to allow each user to specify (and change) his SMTP server addresses.

2. Can't use remote accounts. When I visit my family, I reconfigure my laptop to dial into their local ISP (using their account), rather than dial long-distance to my own. If I send mail from there, it will bounce, because their SMTP server isn't listed for my domain. In this case, I could in theory get their IP address before travelling and add it to my SPF list, but very often when I travel on business I use a client's SMTP server, and I don't know that in advance.

3. SPF can't be implemented by the user. This has to be implemented and administered by your ISP. Do you get prompt and astute technical support from your ISP? I don't! I've been trying for months to get our ISP to close its open relays and get off the spam blacklists. All of my tech support requests get form letters in reply. I had a problem recently with dialup service and their only question was "Do you use Windows? No? Sorry, can't help." So these are the people I'm going to have to ask when I want to use a new domain name for email?

The problem is little better if you're a domain owner and use a web hosting service. I don't know about you, but I don't control the DNS records for either my ISP or my web hosting service (and that's where SPF lists are published). Unfortunately, the people who think of these proposals are ISP administrators, not ISP users, so they never have these problems... and never think of these problems.

4. Server changes break email. Suppose I get all my sending IP addresses nicely configured in my private SPF lists... and then my ISP changes the address of their SMTP server. (Yes, this has happened to me.) Until they notify me of the change (ha!) and I can update my own domain's SPF list, I can't send email. So I can encounter unpredictable email outages for a few days while I straighten this out... and of course, I won't know that my outgoing email isn't being delivered.

5. Publishing IP addresses violates privacy. I don't particularly want people to know what ISPs I use. We get enough abusive email and harassment already, thanks. True, you can discover this if I send you an email, but why make this information available to complete strangers with an axe to grind? And I know advocates (and victims) who take their privacy much more seriously than I do; why deprive them of one of the few safe communication channels they still have available?

6. Prepare to be assimilated. Despite the fact that this has been largely invented by others, Microsoft is claiming patent rights in "Caller ID for Email." Right now they're granting free licenses to use this technology, but I observe that the license is not perpetual, which means Microsoft can revoke it at any time. We've seen this before: first get 'em hooked, and then hike the fees. (I'm sure it's no coincidence that the license is also incompatible with the GPL under which Linux is licensed.) This is not an objection to the open SPF proposal, but which do you think will be adopted?

It's conceivable that someone will come up with feasible solutions to all of these objections. In which case, I might be persuaded to adopt SPF. But in the meantime, I won't be publishing SPF lists, and if you start filtering using SPF, don't expect to receive email from me.


Powered By Greymatter