DKIM Deployment

[Jesse Thompson <>]

Well, it seems that my understanding of DKIM was way off.  I had always 
assumed that DKIM was immune to the issues involved with forwarding.  I 
had hoped to use DKIM as a way to whitelist mail from specific 
organizations (and to not depend the messages coming to our servers from 
specific sources.)  Now, I don't see how DKIM is significantly better 
than SPF, or just plain old IP exemptions. :-(

I feel dejected.  Does anyone care to enlighten me?

Jesse

--- Begin Message ---

• From: Ned Freed <>
• To: Jesse Thompson <>
• Cc: Ned Freed <>, , Rolf E Sonneveld <>
• Subject: Re: [Info-iMS] Date field and dayofweek channel keyword in relation with DKIM signatures
• Date: Wed, 13 Jan 2010 11:43:28 -0800 (PST)
• Original-recipient: rfc822;

On 1/13/2010 11:13 AM, Ned Freed wrote:
> This sort of comparison is pointless and so is attempting to preserve
> all this stuff across multiple hops. If you're going to try and use DKIM,
> you're going to have to do it by being EXTREMELY careful where you apply
> and where you verify DKIM signatures, and also how you choose ot attach
> DKIM signers and verifiers to the MTA.

I guess I was misled by statements such as:

" If the only modifications en-route involve the addition or
modification of header fields, the signature should remain valid;

This is total bunk. DKIM signatures typically cover the content of any header
field the signer chooses, and often cover various headers that end up getting
modified in transit.

also the mechanism includes features that allow certain limited
modifications to be made to headers and the message body without
invalidating the signature.

Features which are used more often than not.

Some suggest that this limitation could be addressed by combining
DKIM with SPF, because SPF (which breaks when messages are
forwarded) is immune to modifications of the e-mail data,

http://en.wikipedia.org/wiki/DomainKeys_Identified_Mail

I have to say that this is also pretty silly. Forwarding is a major problem
with both DKIM and SPF; albeit for different reasons. You can solve SPF
forwarding issues by using SRS - which actually isn't that hard to do. The
only
reliable way to make DKIM work across all the stuff intermediaries do
(forwarding, iist expansion, MIME downgrading/upgradinng, content conversions,
the list of possibilities goes on and on and on) is to resign. But the new
signature will be done by a different authority who probably has a different
associated reputation.

Mind you, I'm not saying DKIM is useless. It solves a certain class of problem
fairly well: Validation of emails sent from one administrative domain to
another. The issue lies in trying to use it outside it's realm of
applicability.

I [mis]interpret that to mean that DKIM should be used in a way that
supports forwarding, which led me to believe that the signatures could
be verified at any hop.

Well, now you know better.

Ned

--- End Message ---

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature