[exim] Fwd: How to include transport info

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Todd Lyons
Date:  
À: exim-users
Sujet: [exim] Fwd: How to include transport info
Murray isn't on the opendkim ML, so I'm forwarding his response. He
is one of the people working on moving and molding DKIM capabilities
to something that can be used in many different scenarioes (direct
signatures, signing by a third party (such as mailing lists), etc).
Murray was the lead programmer for the dkim-filter sendmail project
and is currently the lead programmer for the opendkim milter project,
which includes the libopendkim library. He is a mover and shaker
within the DKIM community and thus I respect his opinion greatly.

Regards...       Todd


---------- Forwarded message ----------
From: Murray S. Kucherawy <msk@???>
Date: Thu, Sep 30, 2010 at 10:22 AM
Subject: RE: [exim] How to include transport info
To: Todd Lyons <tlyons@???>, "exim-users@???"
<exim-users@???>, "opendkim-dev@???"
<opendkim-dev@???>


[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



--
Regards...      Todd
I seek the truth...it is only persistence in self-delusion and
ignorance that does harm.  -- Marcus Aurealius