|
|
|
Click the comments link on any story to see comments or add your own.
|
30 Nov 2004
The Federal Trade Commission and NIST had a two-day Authentication Summit on Nov 9-10 in Washington DC. When they published their report explaining their decision not to create a National Do Not Email Registry, the FTC identified lack of e-mail authentication as one of the reasons that it wouldn't work, and the authentication summit was part of their process to get some sort of authentication going. At the time the summit was scheduled, the IETF MARID group was still active and most people expected it to endorse Microsoft's Sender-ID in some form, so the summit would have been mostly about Sender-ID. Since MARID didn't do that, the summit had a broader and more interesting agenda. As part of the run-up to the summit, the FTC posed a series of questions about authentication. They got a few dozen more or less relevant responses including one that I wrote. They also accepted requests to speak and set up an agenda. At the conference, I got to go first, laying out what authentication can hope to do and all the ways it could mess up mail if done poorly. After that there was a series of panels with technologists, marketers, lawyers, and a smattering of other interested parties. People's positions fell into largely predictable groups. Microsoft talked about Sender-ID, which they think is wonderful. Since Sender-ID only really works for senders that have full control over their mail stream and send it all from one place, bulk e-mail marketers, who are just about the only mail senders that fit that description, also think that Sender-ID is wonderful. People who run more heterogeneous mail systems with more varied mail sending methods, such as consumer ISPs and universities, think that Sender-ID is considerably less wonderful. The consensus I heard among mail recipients is that while valid Sender-ID can help to whitelist known friendly domains, there are so many ways for legitimate mail to fail Sender-ID that nobody with any sense will ever reject mail based on failure. A panel consisting largely of lawyers also had unsurprising results. Microsoft's lawyer thinks that the license they offer for Sender-ID is just like every other patent license and is completely adequate for all purposes. Daniel Quinlan from the Apache Software Foundatation explained why the open software world can't use it but since he's neither a lawyer nor a lobbyist, he didn't make much headway. Yahoo's Miles Libbey did say that their license for Domain Keys avoids the problems that Microsoft has. The Electronic Frontier Foundation reiterated their usual position against any kind of filtering of political or anonymous mail, but as usual failed to explain how we can tell political from non-political mail and how to deal with the costs of dumping vastly more spam into people's mailboxes. The EFF rep said she manually sorts through 2000 spams a day and apparently believes that is a productive use of her time. The next few panels described the various technical proposals. The audience expressed considerable interest in trying them all out, in one case despite an utterly baffling presentation. On the second day, I sat in on the international panel, in place of the ailing Neil Schwartzman, to describe what's happening in Canada (nothing too surprising.) Hadmut Danisch presented a proposal for country-specific mail sending scheme of debatable practicality, but went on to discuss the severe limits that European privacy laws can put on a reputation system. For example, if a domain belongs to an indvidual, like my johnlevine.com, information about that domain could be considered personal information subject to privacy laws. As far as I know, there's no case law or regulatory statements to tell how serious an issue this is, but it's not one that can be dismissed out of hand. I commented that reputation systems are likely to be country-specific since the mailers in the US are different from the mailers in Canada and other countries. I missed the final panel on reputation systems, but I gather it said that they don't exist, and they'll be a challenge to create in ways that are both legal and effective. At the end of the conference, Commissioner Orson Swindle said there'd be another conference next year with the strong implication that we'd better have progress to report Or Else. posted at: 00:49 :: permanent link to this entry :: 0 comments Trackback link is http://weblog.johnlevine.com/Email/ftcauth.trackback 27 Nov 2004
It's a Final Ultimate Solution to the Spam Problem. Vernon Schryver of Rhyolite Software coined the term earlier this year in his highly informative web page called You Might Be An Anti-Spam Kook If.... It lists 48 warning signs to look for in any proposed anti-spam system, and particularly in proponents of an anti-spam system. Schryver is the author of the widely used Distributed Checksum Clearinghouse, a system that counts signatures of mail received at servers all around the world, so participating servers can tell how many previously received messages have been seen by other DCC users, i.e., whether the message was sent in bulk. DCC currently is counting checksums for about 165 million messages a day, twice what it was doing in January. Based on the counts, about 55% of the mail it's seeing is spam. The DCC site has some horrifyingly informative graphs showing the amount of traffic and fraction of spam. posted at: 20:20 :: permanent link to this entry :: 0 comments Trackback link is http://weblog.johnlevine.com/Email/fussp.trackback 23 Nov 2004
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 fred@abuse.net, 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. posted at: 00:51 :: permanent link to this entry :: 1 comments Trackback link is http://weblog.johnlevine.com/Email/authnov.trackback 16 Nov 2004
The country's first criminal trial about spam ended in Leesburg, Virginia earlier this month with a conviction of Jeremy Jaynes, better known under his nom de spam of Gavin Stubberfield. I was an expert witness for the prosecution, the Commonwealth of Virginia. The case was brought under Virginia's state anti-spam law, not the weaker Federal CAN-SPAM act. Virginia's law makes it a crime to send unsolicited bulk mail using forgery, so the Commonwealth had to show first that Jaynes sent lots of unsolicited mail and second that it was sent using forgery. The mail in question was sent on three days in October to AOL, which is why the case was heard in Leesburg, the county seat of Loudon county in which AOL's mail servers are located. The first few days of the trial, which I didn't attend, largely consisted of AOL employees documenting the volume of mail they'd received from Jaynes' networks on those days (millions), and the number of user complaints (20,000.) Then MCI confirmed that the networks were Jaynes'. The prosecution showed some CD-ROMs found in Jaynes' house, full of vast lists e-mail addresses, as many as 30 million on one of them, and a nearly full set of AOL addresses on another. The trial went slower than the prosecutor expected, mostly because of a lot of procedural skirmishing with the defense, so I spent the day on which I'd expected to testify waiting outside in the hall reading a book. They were finally ready for me about 10 AM on the next day. The prosecution asked me to testify as an expert on e-mail technology, specifically to explain why it was utterly implausible that the people on Jaynes' lists could have asked to be on them. The prosecutor had collected some summary numbers about the mail that Jaynes had sent to AOL, showing the IP addresses and the HELO domains he'd used. I explained that legitimate bulk mailers send mail from a consistent place using consistent names and formats, so that recipients can recognize the mail they've asked for. Jaynes, to put it mildly, didn't do that. The HELO domains his mail hosts used were obvious forgeries, several being in .bz which I explained was Belize, a nice place to visit but an unlikely place to run an ISP. He sent mail from hundreds of different IP addresses, a good idea if you're trying to disguise the nature of a spam run, but unlike what legitimate mailers do. We repeated this for subsequent spam runs. Then the prosecutor asked whether it was likely that mail sent to all of AOL's addresses was legitimate. "Only if it was AOL who sent it." Then Jaynes' lawyer cross-examined me, to try to discredit what I'd said. We went off on a detour through click-wrap licenses, in which I agreed with him that few people read them and it was easy to imagine that on page 17 of a license that people hadn't read, there was small print agreeing to receive bulk mail. He then asked what I'd do if I mailed to a list like that. After thinking for about two seconds, I said that since he was talking about a list collected by deceiving people I wouldn't use a list like that, so I couldn't speculate about how someone might use it. Hmmn. Next question. Then we fenced about the Belize issue. He argued that country domains can be cheap, wasn't that a reason to use them? Since normal domains cost only about $15, I agreed that if someone's business was in such dire shape that five bucks made a big difference, I suppose maybe. (I later checked and found that .bz domains cost $35, which is more than normal .com or .biz.) Since they'd previously established that Jaynes had about $20 million in assets, hmmn, next question. We went through a few more exchanges like that, then the defendant's other lawyer asked whether I ran the ASRG, which I said I did, and we were done. That was Friday afternoon, so I went home. The case went to the jury early the next week and as has been widely reported in the papers, they sentenced Jaynes to nine years, and gave his sister the largest fine they could under the charge that the judge gave them. Since the court agreed with the prosecution that Jaynes was a flight risk, they put him in jail until they worked out a bail agreement of $1M bail, and confined him to Loudon county wearing a GPS ankle bracelet until final sentencing. The defense lawyers are making brave noises, but the conviction seems quite solid to me, and the first amendment issues that they want to raise have all been rejected in other cases about spam and junk fax. While it's certainly satisfying that such a major spamming crook got the jail time he deserves, this case cost the Commonwealth of Virginia a whole lot of time and money money for preparation, staff work, and expenses. (We experts don't work for free, we wouldn't be credible if we did.) Going to this level of effort to knock out the top 10 or top 20 spammers is plausible, but going after 100 or a thousand just isn't going to happen. That tells me that we still need more effective civil remedies that individuals or small networks can afford to pursue. posted at: 13:59 :: permanent link to this entry :: 0 comments Trackback link is http://weblog.johnlevine.com/Email/leesburg.trackback |
Topics
My other sitesOther blogsWord
to the Wise
Related sitesCoalition Against Unsolicited Commercial E-mail
|
||||||||||||||||||||||
© 2005-2008 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.
![[Valid RSS]](http://www.taugh.com/valid-rss.png "Validate my RSS feed"){kind=small}