On 14-11-16 14:00, John R Levine wrote:
[ resent with a reasonably correct date header ]
I can write this up as a draft if people think it's interesting.
Murray's draft puts the envelope recipients into the DKIM hash, which
means that the message sent to multiple MTAs be signed separately for
each target MTA.
My version puts the recipient addresses into the DKIM-Signature header
in an r= tag, separated by colons, using the usual quoted printable
to quote colons, semicolons or any other inconvenient characters, e.g.,
DKIM-Signature: v=1; ... r=foo(_at_)example(_dot_)com:bar@plugh.example; ...
At the time SenderID was proposed, back in 2004 or something, the act of
propagating header information into the transport stream was seen by
many as a layering violation. The proposal of Murray and Johns suggested
kludge alternative do the reverse: propagating envelope information to
the header. In my view this is, again, a layering violation. The
downside of crossing layer borders is that transport and header
information are (too) tightly coupled, which makes that the flexibility
of the original mail design (RFC821/RFC822) is lost.
Another aspect, in addition to (3) in Ned's answer, is that changing the
way DKIM works brings a huge risk with it, now that DMARC is widely
deployed and DMARC heavily relies on DKIM. So any change that is
proposed for DKIM must have zero impact on the DKIM verification that is
used by DMARC implementations currently in use.
/rolf
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html