On Wed, 2004-12-15 at 10:29, 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?
Although the MAILFROM is set by the Submitter, it represents the
return-path. Current use of MAILFROM allows retaining this field to
avoid establishing a mailbox to handle returns. The HELO is closely
tied to host and thus is not as flexible as the Sender header, which is
also set by the Submitter. This seems to point to the Sender header as
being a good choice to reference Submitter signatures. There is an
exception allowed, in that when the From is the same as Sender, Sender
may be omitted. Perhaps a better way of viewing this would be to
consider the only valid field for Submitter signatures is the Sender
header, where this may be found, by virtue of compression, within the
From header when it is not present within the message.
Is there a problem using this approach?
-Doug