DomainKeys is a technology proposal that can bring black and white back to this decision process by giving email providers a mechanism for verifying both the domain of each email sender and the integrity of the messages sent (i.e,. that they were not altered during transit). And, once the domain can be verified, it can be compared to the domain used by the sender in the From: field of the message to detect forgeries. If it's a forgery, then it's spam or fraud, and it can be dropped without impact to the user. If it's not a forgery, then the domain is known, and a persistent reputation profile can be established for that sending domain that can be tied into anti-spam policy systems, shared between service providers, and even exposed to the user.
Let me summarise the mechanism with my own words. Details can be read on the Internet draft.
For an email to be sent from a sender's MUA (S) to a receiver's MUA (R), it generally needs to go through the MTA of sender's domain (S') and the MTA of receiver's domain (R'). So,
- Sender click on "Send" on S to dispatch a new email (E) to S'.
- S' signs E with the private key of sender's domain to become E'. Signature sits in the RFC822 header of out-going email.
- S' connects to R' and sends E' via SMTP.
- Upon receiving E', R' verifies the signature against the public key published on sender domain's DNS.
- If signature cannot be verified, then it would be flagged as a spam. Otherwise, deliver to receiver's INBOX.
- Receiver collects E' in R, which gives R another opportunity to verify the signature.
Well. Sounds good. Using a DNS based distributed PKI to authenticate emails. But the real question is, will in work in practise? Here are some issues that I can think of.
- What if the participating parties do not support DomainKeys, either in DNS server or MTA? There are millions of legitimate mail servers out there, and surely not all of them can implement DomainKeys. For a legitimate email that is not MTA signed, do we discard? At the end, this kind of technology is pretty useless if not everyone you want to interact with is using it.
- It does not work well with emails that content might be altered on forwarding, for example the mailing lists. According to the FAQ, mailing list cannot modify the content, otherwise it has to take the authorship. Neither solution is feasible in mailing list applications today.
- It does not work well for roaming users, who might configure the "From:" envelop address to be different from MTA. My email client is configured with multiple email addresses so I can send home emails using work's MTA while I am at work, and send work emails using home's MTA. In my situation it is actually not that bad, as one can add multiple private keys of different domains to both my home MTA and work MTA. However, it would be impossible to get my ISP to sign on behalf of Hotmail, if I would like to use my Hotmail address in my out-bound emails.
Another problem I see is the signature, which only applies to message body, and is only signed with sender's domain. That means the same message with the same signature can be used multiple times with different envelops. Sounds like an useful application for spammers. For example,
- Spammer crafts a spam email, and with his legitimate Hotmail account, he sent the email to himself.
- Spammer then receives that spam email, with properly signed "DomainKeys-Signature" header with Hotmail's private keys.
- Now, spammer would fit the spam mail plus DomainKeys' signature into his mass mailing software, using large number of virus infected machines on the Internet to distribute the spam.
- Bing! You got mail! A freshly Hotmail signed... SPAM!
I think we need a revolution, not just an evolution.