Antispam spec sets off on path to standard

An antispam technology that focuses on identifying forged e-mail addresses has been proposed as a standard by Cisco Systems, Yahoo and partners.

The companies, along with software makers Sendmail and PGP, submitted their DomainKeys Identified Mail specification to the Internet Engineering Task Force this weekend. The IETF, a standards setting body, is expected to start discussing the technology during its meeting at the end of July in Paris, a Yahoo representative said on Monday.

With DKIM, which relies on public key cryptography, a digital signature is attached to outgoing e-mail so recipients can verify that the message comes from its claimed source. The idea is to make it easier to eliminate spam or phishing e-mails with spoofed addresses by marking out legitimate messages. The specification merges two earlier proposals, Yahoo's DomainKeys technology and Cisco's Internet Identified Mail system.

"This is a big milestone for us and the e-mail authentication world," said Miles Libbey, an antispam product manager at Yahoo Mail. "This submission to the IETF represents collaboration between a lot of players in the e-mail authentication world." Other companies involved include Alt-N Technologies, America Online, EarthLink, IBM, Microsoft and VeriSign, Yahoo said.

Standardization of a technology is important for its acceptance. Nonstandard technology is not likely to be implemented in products or adopted by users. The IETF will likely establish a working group to further debate DKIM, the Yahoo representative said.

The specification calls for e-mail domain owners to create a pair of public and private cryptographic keys. The public key is published in the Domain Name System record, while the private key is stored on a DKIM-enabled mail server. Each outgoing message is then signed, with the signature stored in the e-mail header.

On the receiving end, a DKIM-enabled mail server extracts the signature and uses the public key to verify that the signature was generated by the sending domain.

The announcement of the IETF submission comes a day before the start in New York of the Email Authentication Implementation Summit 2005, where experts will discuss e-mail security technology and encourage its adoption.

At the event, attention is likely to turn to another e-mail security technology, Sender ID, which has Microsoft as its main backer. The Sender ID specification is making its way through the standards process.

Sender ID and DKIM have similar goals: to improve the security and reliability of e-mail and to stop the tide of spam, phishing and e-mail fraud. The technologies can work side by side, Yahoo said.

Yahoo first submitted DomainKeys to IETF last March. The new submission is for the merged technology with Cisco. The partners now have some real-world examples of DKIM at work, the Yahoo representative said.

[Bytesmiths]

YAY! ITEF Rocks!

Stamp out proprietary, controlled solutions!

Where can I sign up? I get THOUSANDS of spams a week!

[Bytesmiths]

YAY! ITEF Rocks!

Stamp out proprietary, controlled solutions!

Where can I sign up? I get THOUSANDS of spams a week!

[hadaso]

One major disadvantage compared to SPF

One major disadvantage compared to SPF is that Domain Keys requires that email headers be received before the sender's address can be authenticated, which is rather late in the process. SPF is better in that as soon as the sender's envelope address is given it can be authenticated, before any part of the message is passed. SenderID suffers from the same disadvantage.

And all of these systems suffer from the basic design, which is trying to authenticate the wrong data: the sender's alleged address. The only part of an email transaction that cannot be forged if the email transaction is to succeed is the recipient envelope address, and this is the data that should be used to authenticate that email received is wanted.

[hadaso]

One major disadvantage compared to SPF

One major disadvantage compared to SPF is that Domain Keys requires that email headers be received before the sender's address can be authenticated, which is rather late in the process. SPF is better in that as soon as the sender's envelope address is given it can be authenticated, before any part of the message is passed. SenderID suffers from the same disadvantage.

And all of these systems suffer from the basic design, which is trying to authenticate the wrong data: the sender's alleged address. The only part of an email transaction that cannot be forged if the email transaction is to succeed is the recipient envelope address, and this is the data that should be used to authenticate that email received is wanted.