Linux.com

Everything Linux and Open Source

Email Sender ID: The hype and the reality

August 26, 2004 (8:00:00 AM)  -  5 years, 3 months ago

By: Joe Barr

There are a number of promising technical papers under consideration by the Internet Engineering Task Force which deal with the ever-growing problem of spam. Most of them seek to attack the spam problem obliquely rather than head on. These techniques avoid looking at message content in an attempt to determine if an email is spam or not. Instead, they focus on authenticating the sender. Since most spam comes from forged email addresses, eliminating such forgery would be a big step up in the fight against spam. In this article we'll look at the evolution of the current Sender ID proposals, and we'll also examine some of the non-technical barriers which might prevent any of the proposed solutions from ever working.

The genealogy of Sender ID

In 1998, Jim Miller sent an email to Paul Vixie which outlined a basic plan for rejecting forged email. In 2002, Vixie published his Repudiating Mail-From" protocol based on Miller's work. Mail-From in turn inspired two other techniques, "Reverse MX" by Hadmut Danisch and "Designated Mailer Protocol" by Gordon Fecyk.

In 2003, Meng Weng Wong picked what he felt were the best features of Reverse MX and DMP and came up with SPF. To date, SPF has become far and away the most popular of the DNS-based anti-spam efforts. But the morphing has continued. Microsoft has wrapped its own Caller ID proposal around SPF and now calls it Sender ID.

How it works

SPF/Sender-ID requires changes to DNS and MTAs in order to work. The changes to DNS involve the addition of new records which identify machines authorized to send mail for a specific domain. MTAs (like Sendmail or Postfix) would add new functionality to verify that the email has not been forged; that the address of the person who sent the mail is in fact authorized to send mail for that domain.

Of course, it's not nearly so simple as I describe. And some issues are not yet well settled, including which bit of information should be used to identify the sender. The TCP/IP protocol upon which the Internet is based contains the IP address of the machine attempting the mail transfer. That's called the envelope sender address. The email itself also includes a header record indicating who the email is from. It's called the header sender address. Your email client shows you the header sender address when it displays the "From" line of the email.

Spammers typically forge the header sender address. That's why the note purportedly from your Aunt Nadine turns out to be about enlarging your manhood instead of the family reunion. There has been much debate along the way over which of the two -- the envelope sender address or the header sender address -- to use for verification. Prior to Microsoft's sandwiching SPF into Sender ID, the choice was to use the envelope header. Now it's the email header.

There has also been some quibbling over Microsoft's choice of XML for the new DNS records. Some feel it is akin to HTML email, an aberration that has done much to spread viral infections to the unwary. A darker sin may be that XML is driving the "unspecified patent issue" that is also of much concern.

Technically, many of the competing proposals show real promise in putting a dent in the volume of spam. But economics, IP concerns, and not-quite-open standards all threaten to prevent them from ever fulfilling that promise.

The economics of spam

Hadmut Danisch makes a pertinent observation in his paper on Reverse MX:

As has been recently illustrated in the initial session of the IRTF's Anti Spam Research Group (ASRG) on the 56th IETF meeting, sending spam is a business with significant revenues.

But a much bigger business is selling anti-spam software. This is a billion dollar market, and it is rapidly growing. Any simple and effective solution against spam would defeat revenues and drive several companies into bankrupt, would make consultants jobless.

Therefore, spam is essential for the anti-spam business. If there is no spam, then no Anti-Spam software can be sold, similar to the anti-virus business. There are extremely strong efforts to keep this market growing. Viruses, Worms, and now spam are just perfect to keep this market alive: It is not sufficient to just buy a software. Databases need to be updated continuously, thus making the cash flow continuously. Have a single, simple, and permanent solution to the problem and - boom - this billion dollar market is dead. That's one of the reasons why people are expected to live with spam. They have to live with it to make them buy anti-spam software. Content filters are perfect products to keep this market alive.

In this day and age -- in the United States, at least -- commercial interests have great influence with both the legislative and the executive branches of government. To think that the anti-spam industry will sit quietly by and allow their cash cow to be slaughtered without a fight is self-deluding. Neither are the courts necessarily a hostile place for spam artists. A major spammer -- reportedly the second largest in existence -- recently settled a case brought by New York state attorney general Eliot Spitzer for what amounted to a pittance -- $50,000.00 -- compared to the $20,000,000.00 fine that had been threatened.

As reported in USA Today:

Spitzer spokesman Brad Maione said neither Scott Richter nor OptInRealBig.com admitted any wrongdoing in the settlement.

When announcing his suit, Spitzer said special Hotmail e-mail accounts set up by his investigators found thousands of e-mails in May and June 2003 that carried bogus "from" and "subject" lines, often indicating that the messages were part of ongoing conversations instead of being unsolicited commercial come-ons.

The spammer's lawyer was quoted in the same article as saying, "The fact (that) the attorney general settled for $50,000 while initially talking about $20 million in damages 'speaks for itself...'"

Intellectual Property issues

IP figures in this story in two ways.

First, Microsoft's licensing terms exclude free software from being able to use the proposed standard now called Sender ID, as Richard Stallman's recent post to an IETF mailing list made clear. Stallman wrote:

Microsoft's Sender-ID license is directly incompatible with free software regardless of which free software license is used. Free software means users are free to run it, study and modify the source, and to redistribute it with or without changes. Free to do so means there is no requirement to ask or tell anyone that you are doing so.

The Microsoft license for Sender-ID directly forbids release of software with all these freedoms, so it is impossible for any program to be free software under Microsoft's regime.

Stallman wasn't the only one unhappy with Microsoft's involvement, as Larry Seltzer recently noted at eWeek:

Nothing got members of the working group more upset and caused the chair to threaten banishment more than complaints about Microsoft's involvement in the drafting of the specification. Midway through the process, Microsoft and Meng Wong negotiated a convergence of SPF with Microsoft's Caller ID for E-mail specification.

While many participants objected to working with Microsoft simply on principle, the biggest objection had to do with intellectual property rights. Microsoft's contributions to Sender ID are based on their Caller ID for E-mail specification, and they make unspecified patent claims on this technology.

The second major IP problem with Microsoft's involvement comes in the form of a claim of infringement by Failsafe Designs on both the name SenderID and the methods used to verify the sender in Microsoft's "Caller-ID." As reported August 11, 2004, by InternetNews, "F. Scott Deaver, owner of Failsafe Designs, says Microsoft is guilty of the 'outright theft' of his product name and intellectual property (IP), and will seek legal and financial redress from the Redmond, Wash., software giant and anyone else that uses his technology that verifies e-mail is coming from the domain it claims." I've also heard -- off-the-record -- that the SenderID project has been told to expect legal trouble because of claims of infringement.

Although I have not been able to verify this with Failsafe Designs, I've been told by Meng Wong that if SenderID stalls or dies because of these IP issues, there is no reason why SPF (or "Classic SPF" as he now calls it) can not go forward on its own. As a matter of fact, AOL and a number of other firms have already implemented SPF. The claims against Microsoft are yet another reminder that IP law -- especially in regard to software patents -- is a spectre that hangs over all software development, not just free software.

Conclusions

Technical methods of verifying sender identification are going to go forward. Exactly which ones make it and which don't are the only real questions. But the non-technical barriers make it seem unlikely to this writer at least that they will have much of a lasting impact, given today's commercial environment.

Paul Vixie, who wrote the "Repudiating Mail-From" paper in 2002, noted in a recent online post attached to a CircleID.com interview with Meng Wong about SPF that he has low expectations for success. He said:

Finally, an observation. After co-founding MAPS and turning that crank for a number of years, I know that spam is "like a drug" in that people will go to almost any lengths, no matter how absurd, to send more of it. No "designated sender scheme" will ever be able to cut down the amount of spam that's sent, or received. All it can do is help domain holders avoid the brand dilution of having their domain name forged by spammers. This is a valuable contribution, but we must make it clear that none of these schemes will stop or even slow spam, and that their benefits accrue to domain holders, not to spam recipients.
<p
Read in the original layout at: http://www.linux.com/archive/feature/38601