Re: [exim] How to include transport info

[Todd, you may need to forward this to exim-users for me as I'm not on that list.]

> -----Original Message-----
> From: opendkim-dev-bounce@??? [mailto:opendkim-dev-
> bounce@???] On Behalf Of Todd Lyons
> Sent: Thursday, September 30, 2010 6:45 AM
> To: exim-users@???; Todd Lyons; opendkim-dev@???
> Subject: Re: [exim] How to include transport info
>
> > AFAICT it's unspecified and up to you.  The identity being asserted is
> > included in the DKIM signature header.  It's worth noting though that
> <snip>
> > So, it makes most sense to me to match the signature to the From:
> > header.  Against this, do remember that the From: header is allowed to
> > contain multiple email addresses, while the envelope contains only one,
> > so the envelope is easier to work with.

All correct.

> > I haven't thought about this deeply, but: what are the circumstances
> > under which you'd want to sign an email where the envelope sender isn't
> > the same as one of the addresses in the From: header?  For instance, is
> > it worth having the signing Router have a:

A mailing list posting often has a different envelope sender (the list) than what's in the From: field. That's one classic example.

> > This appears to be an area which the RFC writers have punted upon.
>
> Agreed, it could use more detail WRT to virtual hosters. Maybe a
> mention in the IETF-DKIM list as well? Murray, should I? (Offlist or
> in irc is cool.)

DomainKeys, its antecedent (RFC4870), did make a binding of the signing domain to either From: or Sender:, and a conscious decision was made to drop that requirement in DKIM. There was no obvious reason to tie the signing identity to anything specific in the message. The From: field seems the most intuitive, but that would render third-party signatures impossible up-front and it wasn't clear this was a good thing. In fact it turns out not binding it to anything at all makes DKIM quite flexible.

The "d=" is used to identify which domain holds the private key used to sign, and is the strongest identifier because, by virtue of the crypto involved, is actually validates as being correct. There's also "i=" but that's not as strong because there's no way for a verifier to confirm that the value therein is real.

Anyway, to answer the question about guidance regarding when to sign and what signature(s) to add, I think we're not yet in a position to provide such advice to the industry. The jury's still out on whether to value third-party signatures differently than author signatures. A currently dominant school of thought suggests the idea that DKIM signing a message means "taking some responsibility for it", and that would then feed the signer's domain(s) into reputation analysis at the verifier end, for better or worse. So if you think lending your domain name to a piece of mail transiting your MTA is a good thing to do, then sign it; if not, then don't.

This is the main reason OpenDKIM is deliberately so flexible about deciding which mail to sign and with which signature(s).

Of course if people have opinions about best common practices, that sort of information would be interesting to collect especially if there's consensus on both sides (senders and receivers). This kind of thing is what organizations like MAAWG love to tackle.

-MSK