Click the comments link on any story to see comments or add your own.
Subscribe to this blog
12 Jun 2005
The FTC Authentication Summit a few weeks ago featured a blizzard of three and four letter abbreviations of proposed authentication schemes. Here's a rundown of the current candidates.
SPF and Sender ID: The SPF and Sender-ID juggernaut continues to roll on. Sender-ID has evolved considerably from its origin as Caller-ID, almost entirely by replacing parts of the Microsoft design by their SPF eqivalents, moving Sender-ID to the point that it's now indistinguishable from SPF other than the modestly important detail of which of the six or seven sender address fields on a message it checks.
Both of them do what's known as path authentication, attempting to validate an message by listing a set of sending computers for each domain. Each time a SMTP server receives a message, it looks up the list of permitted computers for the domain of the sender address that it wants to check, and if the actual sending computer is in that list, the message passes. This works a lot better for some senders than others; a cynic would say that the ones for which it works well tend to be Microsoft customers.
Large ISPs I've talked to say that the only thing they plan to do with SPF or Sender-ID is to whitelist known domains. That is, if the SPF or Sender-ID validates, and the domain is one that they already know, they're more likely to give the message a pass. Otherwise, it's as though there wasn't any SPF. A few small providers through a combination of desperation and overenthusiasm have started rejecting mail that fails SPF, with the predictable result that they lose a lot of valid mail and alienate their users.
Domain Keys: Yahoo's Domain Keys (DK for short) takes an alternative approach of message authentication. Each domain can publish a set of cryptographic validation keys for its mail. When it sends a message, the sending computer adds a header line to the message containing a cryptographic signature based on the contents of the message. The recipient computer looks up the sender's validation key and checks the signature. If the signature passes, the message is good. The important difference between message and path authentication is that message authentication says that the message itself is good, while path authentication only says that the message came from someplace plausible.
In recent months, Yahoo has been working aggressively to get people to try DK, by paying for development of open-source DK libraries and working with mail software vendors to provide DK add-ons. Since DK is somewhat more complex than path authentication, the first few months were spent working out imeplementation bugs and ensuring that everyone was signing and checking consistently. Yahoo and Google's Gmail are now signing their outgoing mail, and several large ISPs say they're planning to test DK validation to see how useful it is.
Identified Internet Mail: Cisco's Identified Internet Mail (IIM) is about 95% the same as DK, with the differences in minor details. The IIM signature includes a copy of the message headers it signed so a recipient can compare them to the actual received headers and see if they changed ``too much'' (for some definition of too much.) DK and IIM are far more similar than Caller-ID and SPF were, and DK and IIM remain separate more for political reasons than technical ones.
CSV and BATV: CSV and BATV are two simple but useful anti-forgery proposals that were submitted to the IETF MARID group, got lost in all of the noise, and have resurfaced recently.
CSV (Client SMTP Validation) is a simple path authentication scheme that arguably provides 90% of the value of SPF or Sender-ID with about 5% of the work, and none of SPF's false positive problems. Rather than asking whether a particular computer is allowed to send mail for a particular domain, CSV merely asks whether that computer is allowed to send mail to the rest of the net at all. On a typical network, a few computers handle the mail for the whole network, and the rest of the computers shouldn't be sending mail directly to the outside world at all. CSV keys off the HELO name that a computer uses to identify itself when it starts an SMTP mail session. If the HELO is valid (the name is in fact the name of of the computer at that IP address), CSV allows a simple lookup to see whether the name is authorized to send mail.
While SPF and Sender-ID check the domain name in the return address, CSV checks the domain name of the computer sending the mail. In practice, the two checks seem likely to be about equally reliable, since a given computer tends to send either all spam or all good mail, and if it sends a mix, at least now you know who to complain to. At the FTC Authentication summit, several network operators expressed interest in testing CSV even though the CSV presentation was rather hard to follow.
BATV (Bounce Address Tag Validation) is a very simple trick to deal with what's known as spam bounce blowback. As an example, I operate a service called abuse.net that people can use to look up addresses to send abuse reports to responsible parties. Spammers are not fond of abuse.net, and a couple of Russian spammers out of spite put fake abuse.net addresses on vast amounts of their spam. Since their spam lists are no better than anyone else's, a lot of that spam is undeliverable and bounces back, with the bounces coming back to the real abuse.net. On a bad day, I can get 300,000 bounces even though the real abuse.net typically sends only about 500 messages a day. BATV lets me pick out the handful of real bounces from the mountain of bogus ones. All that BATV does is to put a simple cryptographic signature into the bounce address in mail. If the original bounce address was firstname.lastname@example.org, the simplest form of BATV rewrites that to prvs=fred/0744abcdef@abuse,net, where the prvs stands for private validation signature, and the stuff after the slash is a signature of the bounce address and the date. When a bounce comes back, my server checks the signature and if it's good, it's a real bounce. By good fortune, I did my original BATV prototype about a week before a new virus started forging large amounts of spam from several of the domains hosted here, and it's been a lifesaver, efficiently rejecting tens or occasionally hundreds of thousands of forged bounces every day.
Unlike all of the other proposals, prvs-style BATV can be implemented unilaterally, that is, one mail system can use BATV perfectly well whether or not anyone else does. If a message signing scheme such as DK or IIM becomes widely accepted, a likely extension to BATV will use the same keys as the message signatures do, so that recipient hosts can make a quick check of the bounce addressses in incoming mail to reject obvious forgeries.
comments... (Jump to the end to add your own comment)
Add your comment...
Note: all comments require an email address to send a confirmation to verify that it was posted by a person and not a spambot. The comment won't be visible until you click the link in the confirmation. Unless you check the box below, which almost nobody does, your email won't be displayed, and I won't use it for other purposes.
My other sites
© 2005-2018 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.