|
|
|
Click the comments link on any story to see comments or add your own. Subscribe to this blog |
12 Jun 2005
In my spare time when I'm not dealing with the world of e-mail, I'm a politician so now and then I put on my cynical political hat. At the FTC Authentication Summit one of the more striking disagreements was about the merits and flaws of SPF and Microsoft's Sender-ID. Some people thought they are wonderful and the sooner we all use them the better. Others thought they are deeply flawed and pose a serious risk of long-term damage to the reliability of e-mail. Why this disagreement over what one might naively think would be a technical question? SPF does what's known in the mail biz as path authentication, that is, it attempts to check whether the route that a message took to get to the recipient is valid for that kind of message. In particular, SPF provides a very complex scheme through which a domain can publish the IP addresses from which it expects its mail to be sent. Microsoft's Sender-ID works almost identically to SPF, with the only difference being which of several possible return addresses on a piece of e-mail it checks. If all of a domain's mail is indeed sent from the same place, then SPF or Sender-ID works fairly well. (It still has problems with mail forwarders, but that's a separate issue discussed at great length elsewhere.) On the other hand, if the domain's mail can legitimately come from lots of different places, particularly lots of different places that are hard to predict in advance, SPF and Sender-ID are useless. So what kind of domain sends all its mail from one place? Corporations, mostly. A business will often have a single mail server, or a mail server per branch office, and a policy that all company mail is sent through the company's server. If employees are travelling, they have to connect back to their home network to get and send mail. A bulk mailing service, known in the biz as an Email Service Provider or ESP. sends all of its mail from its own servers. That's both because that's why the servers exist, and because it's easier to get recipient ISPs to whitelist their mail if the ESP can give the recipients a small set of IP addresses to add to the whitelist. On the other hand, mail from university domains can come from all sorts of unexpected places. Students and faculty travel, and being clever academics, lash up all sorts of ad-hoc schemes to send and receive their mail. Many universities provide courtesy mail addresses for alumni that the alums can forward to whatever ISP they happen to be using. The alums send their outgoing mail from their own ISP, so mail from the university's domain can originate at any ISP in the world. Internet Service Providers are in about the same situation as universities. Their customers may check mail from work, and send mail with a personal ISP address via their work servers. Or they might move and keep an old account to avoid changing their e-mail addresses, sending mail with their old ISP address from their new ISP. Corporations and ESPs run a lot of Microsoft servers. Businesses use Microsoft's Exchange to integrate e-mail and calendar facilities, ESPs run various integrated mail and database applications. Universities and ISPs are more likely to be running Unix or Linux servers. Universities do so since they're been running Unix since before Windows existed, ISPs because Unix and Linux mail software can support vastly more users per server than Windows mail software can. So places that run a lot of Microsoft software tend to be set up so that Microsoft's Sender-ID works, and places that don't aren't. Coincidence? You make the call.
|
TopicsMy other sitesOther blogsCAUCE A keen grasp of the obvious Related sitesCoalition Against Unsolicited Commercial E-mail |
||||||||||||||||||
© 2005-2024 John R. Levine.
CAN SPAM address harvesting notice: the operator of this website will
not give, sell, or otherwise transfer addresses maintained by this
website to any other party for the purposes of initiating, or enabling
others to initiate, electronic mail messages.
