Another approach that has been suggested is to ignore the mess of
RFC2822 headers entirely, and just make the signature stand on its
own. The address on behalf of which the signature is made needs to
be explicit in the signature, a property neither IIM nor DK have at
present but perhaps should. But I'm not convinced that the signature
needs to be tied to a particular address in one of the other headers.
If the recipient wants to know, "why is this address signing this
message?" it can try and match the address in the signature with one
of the other headers, but I'm not convinced that question normally
needs to be answered.
Then it's this signing address that ought to be visible by the MUA,
if we had control over the MUA that is.
Yes, exactly! There's no question in my mind that this is the right
thing to do, and that if we did that AND the MUAs showed THAT address
as the authenticated source of the mail, we could get somewhere useful
and get around the disagreements about what to sign. It wouldn't solve
everything, of course, but it would solve enough to enable the things
we're hoping to enable here.
The catch, of course, is that until the MUAs change, this accomplishes
nothing (or extremely little). But lacking this, I'm afraid we will,
as a group, *agree on* nothing. Having been in on some of the
organization of this as an IETF entity, I've now been watching the
arguments here, and I can't see any agreement developing.
Barry
--
Barry Leiba, Pervasive Computing Technology
(leiba(_at_)watson(_dot_)ibm(_dot_)com)
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam