David Woodhouse wrote:
On Mon, 2004-12-13 at 15:17 -0800, Dave Crocker wrote:
Removing any attempt to transit mailing lists makes a mass
specification simpler (since it does not require adding mechanisms to
survive that transition).
Agreed. And it means that you cannot guarantee that any of the From:,
Sender:, or Resent-From: headers will be validly signed. If a message
has all three, then either the Sender: or Resent-From: header may be the
most recent, but you don't necessarily know which -- unless one of them
matches the RFC2821 reverse-path.
Those headers aren't always visible; for them to be reliably visible
you'd need to modify the MUA anyway, which is not something we should be
relying on.
Can you offer any reason why this mess of RFC2822 headers should be used
for verification, rather than the RFC2821 identity which is again much
simpler?
As others have pointed out, the RFC 2821 address has a different meaning.
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.
-Jim