Wandering Thoughts archives

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.