ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] NEW ISSUE: Restriction to posting by first Author breaks email semantics

2007-12-11 05:16:49
On Mon, 10 Dec 2007 14:57:14 -0000, Eliot Lear <lear(_at_)cisco(_dot_)com> 
wrote:

Dave,

     The underlying problem is with coupling the From field to the
DKIM signature.  At most, the Sender value should be used.


It would indeed be nice to use the Sender field, but I would be
concerned about the Sender field not at least matching one of the
domains of one of the RFC2822.From lines, lest someone attempt to bypass
the tests by inserting a Sender.  But then we need an extra rule in the
state machine.  Perhaps it is better to explicitly deprecate multiple
From lines?  As UIs have developed they really don't index well against
multiple From lines anyway.

I think if the Sender matches one of the From addresses, and is itself signed, that should be regarded as a valid originator signature, even though it doesn't match the first.

I could even accept that a Sender (signed) from the proper domain should be regarded as a valid originator signature, even if none of the Froms was from that domain - why else would the signer have signed it?

No verifier should have any problem testing for those conditions. True, it might confuse an end reader whose MUA did not show the Sender, but we can't build standards around the (many) quirks of poorly designed MUAs. In any case, it has always been our assumption that signatures would be checked by the boundary MTA, and readers should either be happy to accept that check, or they should repeate the check themselves (in which case we must assume they know how to do it properly).

--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>