August 26, 2004

Email Sender ID: The hype and the reality

Author: 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

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

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

Spitzer spokesman Brad Maione said neither Scott Richter nor 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
$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.


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 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.

Click Here!