On Tue, 2004-12-21 at 01:36, David Woodhouse wrote:
On Mon, 2004-12-20 at 17:13 -0800, Douglas Otis wrote:
I suggested another method would be to flip how Resent-Sender and Sender
are handled in the case of user forwarding.
If we want to change how things are handled in the case of user
forwarding, surely we might as well have adopted SPF and SenderID?
Signatures protect the Submitter entity. Unlike path registration, a
signature is a safe method for assessing an accountable entity (domain)
granting access. Just as CSV allows name identification beyond the IP
address, the signature allows name identification beyond the last hop.
Accurate accountability is required to establish reputation, and that is
not possible using path registration that requires intervening security
and consistent checking, neither of which are verifiable.
I really think we need to design something which actually works in the
majority of the real world, without requiring change from people who
Requiring a small amount of change from people who _are_ participating
(like "thou shalt add Return-Path: headers if you want to do this", for
example), is a different matter. If they want to implement any new
scheme _themselves_ of course they have to make _some_ changes to do
The suggestion _did_ only affect handling for Submitters that signed
messages and does not affect legacy systems that don't. Attention would
be drawn to the entity signing the message, which seems a desireable
outcome. This change ensures that Sender, as a reference header, would
remain static with respect to a signature reference. Forwarding would
otherwise tend to muddle certainty which header serves this function,
and the reason for considering a change in handling, again _only_ in the
case when signatures are applied by the Submitter.
Your comment seems to suggest that the signature should simply be viewed
as a new header. This would be a choice, but one that would seem to
integrate more slowly within existing mail handling.