IETF approves DomainKeys as an official standard

  • Article

The Internet Engineering Task Force, after years of wading through the process, has finally approved DomainKeys as an official standard.

DomainKeys is essentially a sender authentication mechanism.  It enables domains to insert an encrypted signature into the headers, then when the recipient receives it they can decode the header to verify that it came from the sender it claims to come from.  The signature is generated with a private key on the sender's end and the content of the email message.  On the recipient side, the receiver decrypts the hash value in the header field and also recalculates the hash value for the contents of the email body.  If the two match, then the message did indeed originate at the supposed originating domain.

This is similar to SPF and Microsoft's Sender ID.  In this mechaism, the sending IP is used to verify that the domain that claims to have sent the mail is actually authorized to send mail from the originating IPs.  For example, if <some_guy@fictional_domain.com> is sending mail from 292.168.11.44, but fictional_domain.com is only authorized to send mail from 272.168.11.0/29, then chances are some_guy is spoofing the domain.

I think that both systems are pretty good systems in the fight against spam but I think that it will find a more suitable niche in the fight against phishing.  With overall spam fighting, I can think of two weaknesses with regards to Sender Authentication:

1. Joe from accounting is on vacation and takes his laptop with him.  He connects using his wireless account from the cottage (he's got a nice cottage, it has high-speed and everything) but his personal ISP is different than his organization's IP.  He sends an email to his client Frank but attaches his work email to it.  Frank's work email is using SPF/Sender ID/DomainKeys, sees that Joe's email is coming from an IP not associated with his domain and flags it as spam.  This is not a hypothetical situation, I have seen a lot of false positives matching just this scenario.

2. Cliff at the Bank of Spamatopia has opened up a mail with a virus and now his system is part of a botnet (unbeknownst to him and his IT department won't find out for several weeks).  His computer now starts sending out spam but because he is "validly" sending mail from his domain, so SenderID / DomainKeys doesn't pick it up.  In other words, Sender Authentication doesn't help the case when spammers hide behind a good sender (a lot like my Gmail/Google spammer).

Now, I'm not saying that Sender Authentication is a bad idea, I actually think it's a very good idea.  But let's not fool ourselves into thinking that it will solve the spam problem; it only helps.  Unfortunately, while I have only listed two weaknesses, you can mark my words that spammers will find more.

However, where this will help is in the fight against phishing.  If we get a mail from Paypal/eBay/Bank of America that fails a Sender Authentication test, I think we can be reasonably sure this is a phishing mail and should flag it as spam (safety first).  In other words, combing Sender Authentication with some heuristics about what we want to target (financial fraud), this strategy can find a very effective niche.  There are some instances where this strategy has a natural application.