Finding new ways to fight spam

With Barry Leiba, co-chairman for the Internet Engineering Task Force (IETF) DKIM Working Group, member of the IETF's Internet Architecture Board, and senior technical staff member, IBM's T.J. Watson Research Center.

Question: What is DKIM?

Leiba: DKIM is a mechanism for using digital signatures at the domain level instead of at the individual user level in order to confirm that the email was sent from the domain it says it was sent from. That's kind of an oversimplification. People I work with have slightly different ways of putting it. DKIM is derived from systems by Yahoo and Cisco. Yahoo's is called Domain Keys and Cisco's is called Identified Internet Mail. When the proposals were merged they also merged the names. It's aimed at reducing a technique used by spammers, it's not in and of itself an antispam technique. The technique is spoofing. A spammer says this mail is from bigbank.com, but it's obviously from a spammer. The idea of DKIM is that legitimate mail from bigbank.com would have a DKIM signature on it. That's signature that can be verified by the recipient's domain. The recipient's domain can make a decision on how to use signed mail versus unsigned mail. For instance, mail that has a signature could be put on a white list. Mail from bigbank that doesn't have signature would be scrutinized more closely. This is all an oversimplified.

Question: Sounds pretty straightforward, but I'm sure it's difficult. What are the issues?

Leiba: There are issues with signing the mail and having signatures survive. When mail goes on the Internet it can go through a series of email servers. Some of these can change the mail a little bit in ways the recipient doesn't care about but that can cause the signature to become invalid. One of the hard things we had to do is define the way to build digital signature in a way that is most likely to survive the process. Another issue [is that the DKIM base specification] only tells you the message that has a signature and did come from the bank. It doesn't tell you anything about mail with no signature. We have some continuing work on sender signing practices.

Question: What does this entail?

Leiba: That's a way to have the domain like bigband.com tell you what its policy is on signing messages. It can say that bank signs all messages. Then if you get mail that says it's from bigband.com you can check Big Bank's practices. If the information says that they sign everything, and there is no signature on the email, you can make a decision based on that, perhaps treating it as spam. But you can't do that without knowing something about Big Bank. Some of our work now is to enable that sort of thing, to have domains specify their practices.

Question: Spam and email are big issues. Who else is working on them that are related in some way to the DKIM effort?

Leiba: There are organizations that we call reputation services that collect lists of domains and associate some sort of reputation with them. Big Bank has a good reputation, spammer.com has a bad reputation. DKIM can use this in that process to confirm addresses and say whether [an e-mail] has been spoofed or not.

Question: Are their other standards that seek to do what DKIM does?

Leiba: There are other mechanisms that use different techniques from digital signatures. Two best known are related to each other. One is the SPF — Sender Policy Framework — and the other is called Sender ID. Both use the IP address of the mail server contacting you to try to confirm that the IP address is allowed to send mail on behalf of Big Bank.com. DKIM uses digital signatures and has problems of the signature surviving the trip through the network. SPF and Sender ID have a problem due to its use of the IP address of the server. If the mail goes through multiple relays, SPF and Sender ID don't work because the IP address that immediately connects to the recipient is not the original one from bigbank.com.

Question: It sounds like SPF and Sender ID would really be in trouble. Isn't the typical email sent through many relays, each of which would knock them out?

Leiba: In recent years the topology of networks has changed somewhat. Now, most often, if Big Bank sends mail to someone at aol.com, for instance, it really is Big Bank's server contacting to AOL at the boundary where SPF and Sender ID work. In the old days it may go through some university computers. It's changed a lot in the last 20 years.

Question: So where would it not work?

Leiba: Let's say someone from optonline.net sends mail to somebody at alum.mit.edu. The mail is just sent along to the alumnus at their new address. Now mit.edu is connecting and sending mail that originates at optonline.net. So when the recipient is asked whether it is okay for mit.edu to send mail originating from optonline.net, it says no. So that's going to fail an SPF check. But DKIM will work in that scenario.

Question: So both have strengths and weaknesses.

Leiba: The point DKIM can work in that relaying situation where SPF won't, but it is possible for SPF and Sender ID to work in a scenario where the signature got broken. Each of the systems has advantages and disadvantages. It may be that both survive in the long term because both are needed.

Question: Where are the three in the standards process?

Leiba: SPF and Sender ID both went into IETF and formed a group called MARID in 2004. It was not able to complete its work and collapsed after some months. Both specs were published as experimental specs. DKIM managed to hold itself together and come to consensus and has been approved and is in final editing process. It will be RFC 4871.

Question: Is it in the field?

Leiba: There are a number of major email senders and receivers that were using Domain Keys that are in the process of switching to DKIM. Yahoo obviously is one of those because they developed Domain Keys. There are a number of others companies, including software developers, who have put DKIM into email server programs.

Question: What is the future path of the standard?

Leiba: Certainly over the next year it will be widely deployed. RFC 4871 was just published. That means it has a status of a proposed standard. After it is used for a while and proves to be able to interoperate between different implementations, it will advance to draft standard. Then, if is used for a number of years and proves to be mature, it may be advanced to a standard. The bottom line is that once it comes out as proposed standard, implementations start getting cranked out..

This Executive Briefing originally appeared in a weekly report from IT Business Edge.