Microsoft isn't getting everything it wants these days, and this month provides
yet another example. In the space of a few days, its "Sender ID" proposal to
identify legitimate e-mail was voted down by an Internet standards body and
rejected by the world's largest Internet service provider (ISP),
America Online (AOL).
That reversal of fortune gives a backhanded boost to "Domain Keys," a
competing and arguably superior proposal supported by Yahoo.com and
other Web players.
Since both protocols are billed as fighting the evils of identity theft,
phishing, and spam — a cleanup that only ne'er-do-wells would oppose
— it's fair to ask whether the public humiliation for Sender ID may
actually have the good outcome of hastening the adoption of Domain Keys as a
single, unified standard.
Much Ado About E-Mailing
I analyzed Domain Keys, Sender ID, and a third proposal, SPF, in this space on
April 26, 2004. All three protocols grapple with the fact
that anyone can make any e-mail message appear to be coming from any address
they like. The three specs go their separate ways from there:
• SPF.
Sender Policy Framework is a simple principle that's been promoted
for many months by Meng Wong, the CTO of the Pobox.com e-mail service.
Owners of domain names, such as Example.com, would announce in the World Wide
Web's registry a list of Internet Protocol (IP) addresses that are authorized
to handle mail related to their domains. E-mail messages could not contain
a "bounce" address that didn't correspond to one of the IP addresses on
the list. This would prevent spammers from sending out e-mails, some of
which would bounce back to whomever they picked as their victim (a
harassment technique known as a "Joe job").
• Sender ID. Microsoft's proposal began life as "Caller
ID for E-Mail." The name was later changed to "Sender ID" when Microsoft
accepted the SPF concept into its own proposal. In addition to checking that a
message's "bounce" address is legit, e-mail recipients who checked for Sender
ID compliance would verify that the domain name in the "from" address of each
message was plausible. Recipients could reject messages that claimed to be
from "Someone@Example.com" if they came from IP addresses that Example.com
hadn't declared.
• Domain Keys. Rather than verifying merely the "bounce"
address and the "from" address, the Domain Keys proposal would also guarantee
that the contents of the message hadn't been altered by anyone along the way.
To accomplish this, each outgoing e-mail server would "sign" each message
using a digital certificate. recipients could reject messages that didn't sync
with a domain's centrally stored value in the World Wide Web registry.
The above summaries, of course, are oversimplifications of three quite
technical proposals. But it's enough background to let us forge ahead on the
main question: If you want e-mail to be reliable once again, and you're willing
to implement a small change on your servers to help end spam, is Domain Keys
the horse you should bet on?
One Small Step For a Server, A Giant Leap For Antispam
Miles Libbey, the antispam product manager for Yahoo Mail, naturally feels
that Domain Keys' time has come. He ticked off several advantages Domain Keys
has over both Sender ID and the original SPF proposal:
• Real Authentication.
"The original sender of the e-mail is authenticated," Libbey says of
Domain Keys, "rather than the last server that touched the e-mail." Under
the Sender ID proposal, the IP address of a sending e-mail server is
checked. In the Domain Keys scheme, both the IP address of the sender and
the digital signature of the sender's message must match.
• Mail Forwarding Still Works.
Unlike Sender ID, which Libbey says has tricky implementation issues for
messages that are forwarded from one server to another, Domain Keys doesn't
interfere with forwarding at all. "They don't have a good solution for
forwarding," he asserts. "E-mail is a store-and-forward system," Libbey
notes, and long-established practices must continue to work if any e-mail
authentication spec is to gain acceptance.
• It's The Reputation, Stupid. Merely checking that an e-mail
comes from a known IP address won't eliminate spam or phishing. Spammers can
easily buy cheap, disposable domain names (such as Citibank-Example.com) and
send spam that really comes from that domain. Many consumers would still be
fooled into revealing their passwords to phishing sites with such confusing
names. Authenticating the source of e-mail messages must be combined with a
reputation rating system that totes up positive scores for legitimate senders
and negative ones for spammers. Yahoo has for more than two years operated
such a rating service — SpamGuard — which Libbey says gives Yahoo a powerful
tool to identify "good" senders and filter out "bad" senders.
Taking Hits Over The Performance Hit
One criticism that's been leveled against the Domain Keys proposal is that
the digital signing of outgoing e-mail messages requires more CPU time
than simply sending messages raw and unsigned, as it were.
Domain Keys doesn't require the encryption of an entire message, but it does
require the signing of a snapshot or "hash" of the message. This would
inevitably consume some fraction of a CPU-second.
Fortunately for us, this question was thoroughly tested by Sendmail
Professional Services, the company behind Sendmail, software that ranks among
the world's most widely used e-mail server back ends.
In a benchmark report released last July, Sendmail's testers
established that the signing of average-sized messages would reduce
a server's potential e-mail handling only 7.8 to 15.2 percent. The adoption of
Domain Keys could easily give back more processing power than that by merely
denting the volume of spam that a company's servers have
to analyze every day.
Domain Keys "will prove to be far more efficient than current methods
of filtering and evaluating all messages," Sendmail said in its findings.
It should be noted that Sendmail executives have, in the past, also endorsed
the concept of Sender ID. Sendmail is expected to support a number of
different protocols so mail administrators can implement the ones they prefer.
Who Wants To Play?
Microsoft's Sender ID proposal hasn't been dealt a death blow, but it's at
least limping from the highly public Sept. 11 vote against it by a working
group of the IETF (Internet Engineering Task Force) standards body.
A co-chair of the group, Andrew Newton,
said
a patent application Microsoft has submitted regarding Sender ID was an issue.
The Redmond company says it will license the intellectual property for free to
anyone who pledges, among other things, not to sue Microsoft over patent claims.
Five days later, AOL let its
views
be known. The ISP said it wouldn't support Sender ID, partially because the
current Microsoft proposal seems to have altered the nature of SPF from its
original design. AOL has already posted SPF information for its own domains
and says it will start rating SPF compliance as part of its spam-filtering
formula, possibly as soon as the end of this year.
In response to questions about its recent political setbacks, a Microsoft
spokesperson said in an e-mail that the company "is pleased to offer its
necessary Sender ID patent rights on a royalty-free basis but only to those
who are also willing to make their Sender ID patents available on a reciprocal
royalty-free basis."
The spokesperson, who declined to be identified by name, added:
"Microsoft has disclosed the existence of those pending patent claims
and has provided its assurance that if such claims are granted Microsoft
will make licenses available on reasonable and non-discriminatory terms."
Asked whether the company might revise its Sender ID proposal, perhaps to
incorporate support for Domain Keys, the spokesperson replied:
"Microsoft continues to believe complementary technologies such as
signing solutions (of which Domain Keys is one) and computational proofs
will be important to address other technical aspects of spam that these
IP-based authentication mechanisms do not address."
An AOL spokesperson did not respond by press time to telephone calls seeking
comment.
Conclusion
SPF temporarily represents a silver lining in the Internet cloud. Adding to your
servers a small SPF-compliant text file would require very little time
and might slightly improve your e-mail delivery success rate. Microsoft's own
Hotmail and MSN e-mail services — as a first step toward a full-blown
e-mail authentication scheme — will start giving brownie points to
SPF-compliant e-mail this October or soon thereafter.
It's too early to tell whether Sender ID or Domain Keys will emerge as the
winner to handle e-mail properties that SPF doesn't.
But it's not too soon to say that Domain Keys is a stronger proposal to
clean up the e-mail mess than Microsoft's more limited and patent-entangled
Sender ID.
Microsoft isn't getting everything it wants these days, and this month provides
yet another example. In the space of a few days, its "Sender ID" proposal to
identify legitimate e-mail was voted down by an Internet standards body and
rejected by the world's largest Internet service provider (ISP),
America Online (AOL).
IE 7
Firefox 2.0
