On Wed, 2004-11-03 at 07:44 -0800, Dave Crocker wrote:
what is significant about the current thread is the nature of the
analysis that needs to be done, to handle the changes a mailing list
can introduce into a previously-signed message.
<...>
This track record calls for taking the most narrow, focused approach
we can. This means the specification should be absolutely minimalist.
We should strive for the most basic and straightforward capability we
can.
Ok. I'm happy enough to drop the requirement that an RFC2822 scheme
should survive mailing lists -- on the condition that we don't actually
_expect_ the scheme to survive mailing lists. I think that seems like a
reasonable compromise :)
So if a message has a Sender, Resent-From or Resent-Sender header
indicating that it wasn't injected into the mail system directly by its
author, then the mailsig RFC should make it clear that a compliant
recipient MUST NOT reject that mail purely on the basis of an invalid
signature for the From address. Likewise a recipient MUST NOT reject on
the basis of an invalid signature for the Sender address, if there's a
Resent-From header.
You may reject (or mark as spam or otherwise disadvantage) the mail only
if the most recent sender (that's the Resent-Sender from the most recent
Resent- block, the Resent-From from the most recent Resent-block, the
Sender or the From header, in that order) advertises that they will
always sign mail and there is no valid signature.
If signature headers can survive but the signature is likely to be
invalidated in transit and resubmission, then I suppose it's OK for a
recipient to reject mail if there is _no_ signature for one of the
previous senders who claims to always sign mail. It's just not permitted
to reject because such a signature is invalid.
--
dwmw2