On Thu, 2004-12-16 at 08:10, Tony Finch wrote:
On Wed, 15 Dec 2004, Douglas Otis wrote:
These resent headers could be seen as optional and happen to be
unlimited in number. Resent-Sender/Resent-From is created when the
entity identified in this field resends a message with the intent of the
message appearing to be unchanged.
Resent fields prepends to a message reintroduced, where this set of
fields are added each time this is done.
You're assuming 2822 semantics here, but in my experience most
implementations follow 822 semantics for Resent-*. The implications of
this are that ordering of Resent-* does not generally follow the 2822
prepend rule, and software is likely to be confused by the presence of
more than one Resent-* set.
There's a general problem in 2822 that although it re-defines Resent-*
as being part of the trace fields, it doesn't allow for general extension
of trace fields despite the fact that this is a common requirement (e.g.
Delivered-To: headers in alias-forwarding).
This is a general question: Should the behavior of user Forwarding
change as a result of signing?
Changing the behavior of using Resent-* headers would be involved and
822 does not use the 2822 cascading mechanism as Tony points out.
Depreciating the use of this Resent mechanism would not seem to create
any difficulty as a result of the differences between 822 and 2822
however. Adding a means to trace information removed as a result is a
separate problem, but there could be a solution for this as well.
There could be a hybrid approach of sorts. When the signature header is
present, change the conventions for the Resent-Sender by flipping its
definition by having it contain the previous instead of the current
Sender or add a Sender, if there is no current Sender (a typical case).
Standardized notation within the Resent-Sender could indicate this
change in conventions. This would allow the From header to be preserved
and the user would see the same results as now normally seen with user
Forwarding in their mail user agent. This would allow the Sender
header, when used with signing to _always_ reference signature
validations. As this header is typically not seen anyway and seldom
used, this change in use will not be noticed by many.
A static header assignment for the signature reference would remove any
header selection process. On the other hand, if things are to be kept
"as-is" with respect to Resent headers, then it would be beneficial to
bind the signature to the correct header, due to issues created by
non-signing aware handling. The idea of being sure about which header
to use would seem to be a major benefit by allowing a slight change to
the Resent conventions. This would also take advantage of 822/2822
conventions that normally preserve this field when passed through
non-signature-aware handling. There would be a greater chance, that if
nothing changed within the message, the signature could still verify.
The alternative would be to bind the signature to a header in some
manner. With 2822, this is more of a challenge.
-Doug