Wandering Thoughts: Recent Entries For 2010/09

My new view of DomainKeys

Now that I actually understand how DKIM works, I have a much better view of it than I used to and as a result it's much more attractive and likely to be implemented here some day.

The way I choose to look at it is that for us, it is essentially a lightweight anti-tampering feature. We can sign outgoing messages to transparently add some basic integrity protection for our users' mail, and verify inbound DKIM signatures for a basic integrity check. This makes using it a lot like our existing habit of using TLS SMTP whenever possible, ie it does some good for frustrating bad people and basically no harm.

(We're not going be able to actually start using DKIM any time soon, because all of our mail servers are running Exim versions that are too old to have DKIM support. The inbound gateway is due to be upgraded soon since it's still running Ubuntu 6.06, but the mail submission machine is running RHEL 5 which is good for years yet. And supporting DKIM is in no way important enough to justify compiling a local version of Exim from source.)

The one fly in the ointment would be if people implementing DKIM checkers (whether in MTAs or MUAs) had made my mistake and are reading more into DKIM than is actually there, especially if they're treating it as a kind of SPF. In that case, adding DKIM DNS data and DKIM signatures to some of our outgoing email might harm the delivery prospects of email from us and our users that wasn't DKIM signed by us, as would happen for, eg, email that our users send from GMail using their CSLab addresses. Hopefully this is not the case.

(Making it harder for our users to use GMail would be, to put it one way, an extremely unpopular move.)

Sidebar: Where we would put DKIM in our incoming email flow

Our inbound spam and virus filtering can alter the message body (if a virus is removed) and the Subject: header (if a virus is removed or spam is detected). My current opinion is that we should thus do DKIM signature validation before spam and virus filtering, essentially treating it as a validation of the message state before we started mucking around with the message. I can justify this from a message integrity view by saying that our alterations are automatically okay (well, from our perspective).

(Logically this implies that we should re-sign messages when we forward them, but I'm not quite comfortable with that for various reasons.)

If we do DKIM validation after the filtering, all virus-cleaned messages will fail DKIM checks and most spam-scored messages will (the Subject: header is usually part of the signature). I don't think that that's useful, whereas it could be somewhat useful to know if a spam or virus message was altered in transit (or sent by a spammer that forged the DKIM signature) or clearly came that way originally.

Sorting out DomainKeys and understanding its limits

Okay, first a disclaimer: most everyone talks about DomainKeys, but it is formally DomainKeys Identified Mail (DKIM). Plain 'DomainKeys' is the name of the earlier specification that was folded into DKIM.

Until I started digging into this in detail, I had the basic idea that DKIM signed email header fields, crucially including the From:, in order to assert that the email had been sent from a valid mail server for the sender's domain. In other words, I thought it was the message header version of SPF (which attempts to authorize the envelope sender); because it worked on message headers instead of the envelope sender, it avoided SPF's problems with forwarded email.

It turns out that this is totally wrong, and the Wikipedia DKIM page even sort of explains how it is wrong, if you read it carefully.

Simplified, DKIM is nothing more and nothing less than a way of letting a domain take authoritative responsibility for a 'message', where the message is the email body plus selected message headers (which headers are up to the DKIM signer, but the RFC requires From: to be included). Note especially that this responsible domain does not necessarily have anything at all to do with the domain of the From: header (and the RFC update is very explicit about this); you can't conclude that the From: is valid or honest from the presence of a valid DKIM signature, or conversely that the From: header is forged because the message is lacking a DKIM signature from the domain.

Thus, when GMail DKIM-signs their outgoing email all they are saying is 'this really originated on GMail, and you can verify that it has not been tampered with in transit'. They are not saying anything about whether the email really came from who it claimed to come from in the From: header, at least not in the DKIM signature; what From: addresses GMail lets people use is a local policy issue that is outside of what DKIM has anything to say about.

(As it happens, GMail does try to verify From: addresses before it lets people use them.)

It follows that you cannot use DKIM for two useful things without outside knowledge:

• you cannot use DKIM to verify that email From: your bank is actually from your bank, unless you already know that your bank always sends email with a DKIM signature pointing to its own domain and thus that email without a DKIM signature or with a valid one that points to another domain is invalid by policy.

• you cannot use DKIM to verify that email really originated at a domain's mail servers unless you have already know that the domain always, without any exceptions at all, DKIM-signs all outgoing email and thus an email message with anything but a valid signature from that domain is invalid by policy.

As far as I can tell, without such advance policy knowledge there are only two useful things that you can do with a DKIM signature. First, if there is a signature but it does not validate, either the message has been tampered with in transit (possibly accidentally, possibly due to having a virus sliced out of it by someone's mail filters) or the header has been forged. Second, if the signature does validate you theoretically have someone to blame if the message is spam or otherwise bad (not that this does you much good in practice).