Have you ever experienced a difficult problem that seemed unsolvable —
until you realized at the last moment that a simple solution was staring
you right in the face?
Something like that is happening in the battle to eradicate spam.
Two major proposals to identify and screen out the senders of unsolicited
bulk e-mail are from Microsoft, with its "Sender ID," and Yahoo.com, which
is promoting "Domain Keys." But, as I reported in this space on
Sept. 28, Sender ID was dealt a crushing blow when it was
rejected by both America Online, the largest Internet service provider in the
U.S., and the IETF (Internet Engineering Task Force), a key standards body.
Although that seemed at the time to be good news for Domain Keys, Yahoo's
proposal requires a certain level of encryption to work. That's a prospect that
can be daunting to companies with millions of messages to process each day.
While these two high-profile technologies were garnering all the publicity,
a new antispam technique was quietly making the rounds at the E-Mail
Authentication Summit held last month by the U.S. Federal Trade Commission.
The new kid on the block is variously known as "Certified Server Validation" or
"Client SMTP Validation" (CSV).
I just call it Certified Server. But you might call it
an idea that's so simple and brilliant that it could actually succeed.
How Certified Server Fingers Spam
The Certified Server proposal requires just three lightning-fast tests,
unlike other proposals that make heavy demands on corporate resources.
Only features that have been standardized in Internet e-mail for years are
employed by CSV. Here's how it would work:
• Step 1: Authentication.
Internet pioneer Jon Postel defined SMTP (Simple Mail Transport Protocol) back
in 1982.
Ever since then, a computer that wants to send e-mail to another computer
begins a communication session by using a command called HELO (pronounced
"hello"), followed by the sender's domain name. A few years ago, this concept
was built upon to
define
an "extended hello." Most modern mail servers now use the new command,
EHLO (pronounced "ee hello"). The beginning of an e-mail transmission from
a server named "mail" at a company called Example.com might, therefore,
look like this:
EHLO mail.example.com
The Certified Server technique proposes that receiving mail servers should
check whether the Internet Protocol (IP) address of the computer sending
the hello matches the domain name's IP address. This is called a "forward
lookup." It's extremely fast, because IP addresses and domain names are
usually cached within a mail server's memory.
If the domain name in the hello and the IP address of the sending server
match, Step 1 is passed. It's very likely that the receiving mail server is
communicating with a known domain name.
• Step 2: Authorization.
Merely knowing that a communication session is coming from a recognized domain,
however, doesn't prove that that communication is legitimate. The e-mail
might be coming from a "zombie" — a computer that's been taken over
by a virus and is now sending millions of pieces of spam.
The second step in CSV, therefore, is to determine whether the computer that's
doing the sending is authorized to send mail for that domain name. In most
companies, no matter how large their internal network, only a few servers
are specialized to send out all the e-mail.
The Certified Server proposal calls for the receiving server to use the
Domain Name Service (DNS) record of the domain name to find out which servers
are so authorized. A response should come back that looks like this:
_client._smtp.mail.example.com SRV 1 2 0 mail.example.com
_client._smtp.www.example.com SRV 1 1 0 www.example.com
These two lines are SRV or "service" records. SRV is a feature of DNS that was
first defined
in February 2000. These records, which require only "one round-trip" from
the receiving server to the sending server, are also very fast.
In this instance, the records certify that the server known as "mail" is
authorized to send mail for Example.com, but the server known as "www" is not.
That's the meaning of the "2" in the first line and the "1" in the second line.
If the administrator of the EHLO domain name hasn't authorized a specific
computer to send mail, the receiving computer can simply reject the connection
and refuse to accept any falsified mail, which is highly likely to be spam.
Content-scoring spam filters, by contrast, require the receiving mail server
to accept everything and then waste valuable time analyzing its content.
• Step 3: Reputation.
Refusing to take junk mail from bogus servers is a big help right there. But so
far, we've only certified that the sending mail server is willing to identify
itself truthfully as belonging to a registered domain name. Many companies
that send spam are more than willing to identify themselves.
The final step in Certified Server, therefore, is to check the reputation of
the domain name that wants to send mail. A large company can do this almost
instantly by looking up the percentage of e-mail that previously came from
this domain name that was spam. Optionally, a recipient could contract with any
of a number of rating services that currently rate IP addresses, such as
Spamhaus.org and
BondedSender.
Such services could easily compute reputation scores for named domains, which
would almost certainly be more reliable than rating IP addresses.
It's increasingly hard to calculate reputation scores for IP addresses.
Spammers quickly jump from address to address and use viruses to turn
legitimate computers (and their IP addresses) into zombies.
That's why Certified Server is so promising. The company that owns a domain
name enjoys password-protected access to that domain's DNS records. Spammers
can't hijack them. Simply rejecting communications from unauthorized computers,
and rejecting communications from authenticated domains that send mostly spam,
can immediately cut down a huge volume of junk you'd ordinarily get.
All of the above takes a lot less time to do than it takes to explain.
The Road To IETF Adoption
If the three giants of e-mail — AOL, Yahoo, and Hotmail (which is owned
by Microsoft) — ever agreed on a sender-authentication standard, that
scheme would quickly be adopted by smaller parties. But the three industry
leaders are going their own ways.
John R. Levine, the author of the bestselling book
"The Internet for Dummies," is the chair of the IETF's
Anti-Spam Working Group and is impressed with CSV. At the same time, he
recognizes that Microsoft can put millions of dollars of marketing muscle
behind Sender ID and induce many companies to try to implement it.
That's fine, says Levine. "They are not at all mutually exclusive," referring
to Sender ID and CSV. "You can do both."
At the same time, Levine warns that the open-ended negotiations that the Sender
ID protocol allows senders to initiate can be extremely expensive for the
receiving computers. Levine set up a test server to handle requests conforming
to the Sender ID spec and was shocked by the time that a malicious sender could
consume. "It took an hour to get it," Levine said in a telephone interview.
The CSV proposal is close to IETF consideration. This means the simple standard
(with the support of Levine and others) could receive a stamp of approval as
early as 2005.
Security Implications Weigh Down Sender ID
The back-and-forth nature of the Sender ID authentication process is one of the
biggest weaknesses of that proposal, according to Douglas Otis, a proponent
of CSV. In a 10-page
formal comment to the FTC's summit, Otis
argued that mail servers following the Sender ID protocol would be open
to devastating denial-of-service attacks.
As opposed to the onerous performance penalty that Otis says Sender ID would
impose on companies, the adoption of CSV would actually reduce overhead.
Three time-consuming steps that mail servers now perform to try to avoid spam
— reverse DNS, address record, and MX record lookup — could be
skipped by following the CSV protocol, he informed the FTC.
Levine warns that a different aspect of Sender ID might have even more serious
consequences. He's published an
analysis
of patent applications on Sender ID that Microsoft released on Sept. 11.
The IETF largely rejected Microsoft's proposed standard because of
those applications. Levine found that the actual claims in the filings
are "much broader" than anything Microsoft had previously disclosed.
Levine quotes from the text of the applications to show that Microsoft claims
not just patent rights on anything similar to Sender ID, but also on
spam filters that compute scores based on the content of messages. That's
not the kind of patent that standards bodies have ever wanted anyone to have
on an Internet protocol.
The Future May Hold Both CSV And Domain Keys
Dave Crocker, the principal of
Brandenburg
InternetWorking and another proponent of CSV, says corporations could
adopt the Certified Server concept very soon and follow it up by adding
Domain Keys when that protocol has been tested and refined.
"The thing about CSV is it's a one-hop mechanism," Crocker said in
a telephone interview. Domain Keys, with its strong encryption strings,
requires a larger investment but would complement CSV and guarantee that
e-mail messages hadn't been altered in transit. "It will only cost about
$100,000 to upgrade Yahoo.com for Domain Keys," Crocker points out. He notes that
Yahoo is one of the largest e-mail providers in the world and that most
companies would spend far less or nothing to convert.
One of the biggest e-mail players, AOL, is pounded by spam every day and
seems ready to do something about it. It's been rumored that AOL has conducted
test of parts of Sender ID, which haven't been entirely successful. But
Sender ID is only one approach it's evaluating.
"We remain committed to other IP-based approaches and see a lot of benefit to
the 'newer' CSV idea," said Carl Hutzler, director of antispam operations
for AOL, in a
posting last September.
"AOL already gets more than 85% of
our spam from other ISPs' main outbound MTAs [mail transfer agents].
SPF, SenderID, and Domainkeys will not change that, as this
mail also uses the legit domain of that local ISP," Hutzler continued.
"CSV and certain best practice documents shift the responsibility to
the sending organization for the mess they create through their insecure
networks and insecure practices..."
In an e-mail interview, Hutzler confirmed that AOL plans to test some form
of Certified Server technology. "CSV provides a way for someone to take
responsibility for an email that is about to be sent, and by someone we mean
the domain owner specified in the HELO," Hutzler says. "We will be testing a
very modified CSV approach in late Q1/early Q2 [2005] in conjunction with our
Sender ID/SPF testing."
Conclusion
At the moment, there's nothing about Certified Server that corporations can
adopt today. While discussions within the IETF go forward, important details
such as the exact format of the SRV records mentioned above could change.
But that doesn't mean that you can't inform yourself about this simple
technique that could have a big payoff.
Detailed information about the proposal is available at the Web site of the
Mutual Internet Practices
Association, a not-for-profit trade organization. Give it a look.
Have you ever experienced a difficult problem that seemed unsolvable —
until you realized at the last moment that a simple solution was staring
you right in the face?
IE 7
Firefox 2.0
