Domainkeys started off as a very simple system. Take a hash of the email, sign it using a private key, base64-encode it, stuff it in a header, and send the email. On reception, if the header exists, take a hash of the rest of the email, compare it to the hash in the header, and check the signature against a public key published in a DNS record underneath the domain name of the From: address.
Simple to sign, simple to check, simple to implement.
Then came reality. You see, a standard is no good unless everybody can implement it. That is the goal -- widespread implementation. However, some people have unnaturally restricted their concept of "implementation" when it came to DK. They said "well, this MTA munges the message $THIS way, and this other MTA munges the message $THAT way, and mailing lists don't change the From: and will append a trailer to the message." Thus was born the complexity in DK, which has resulted in DKIM.
However, a complex standard is also hard to implement. Thus there needs to be a balancing act. DKIM has gotten so complicated that it will be hard to implement. In the end, I think that we need to cut some MTAs loose. Some MTAs were never really written to Exchange internet email. I think that there is no hope for them. Adding complexity to DK was a mistake in the first place. It's hard to write authentication software. In the end, it produces a binary result, and that result can be seen to be right or wrong. Adding complexity is intrinsically the wrong thing to do.
So a stand must be taken against DKIM's complexity (DK is already complex enough; no more!). Mailing lists SHOULD resign messages if they munge. Munging MTAs SHOULD use a lightweight proxy MTA front-end that faces the Internet, checks the signature, inserts a result header, and relays the email to the munging MTA.
Anything less is insanity. implement DomainKeys like Yahoo and Google Mail have done. Ignore DKIM.
posted at: 15:09 | path: /opensource | permanent link to this entry