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.
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:
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  in conjunction with our Sender ID/SPF testing."
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.