From: Tony Finch [mailto:dot(_at_)dotat(_dot_)at]
Sent: Thursday, September 01, 2005 8:43 AM
To: Frank Ellermann
Cc: ietf(_at_)ietf(_dot_)org; ietf-mxcomp(_at_)imc(_dot_)org;
spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
On Thu, 1 Sep 2005, Frank Ellermann wrote:
Regarding RFC 822, the S-ID draft doesn't mention the fact
that a large proportion of software which does something
useful with Resent- headers still implements the 822 syntax,
not the 2822 syntax.
Except from all PRA-purposes and maybe MUAs displaying these
Resent-* header fields somehow (822 or 2822): What other uses
do you have in mind ?
<snipped Tony's description of issues with differences between 822 and 2822
usage of Resent-*: headers>
Sender-ID effecively requires that this kind of submission server fix-up
must be implemented by MTAs and MDAs that do aliasing / redirecting /
forwarding.
I think it is worth pointing out that the use of Resent-*: headers to
indicate forwarding activity, rather than resending, appears to violate
_both_ RFC822 and RFC2822. In 2822, IIRC, there is an actual prohibition
against the use of Resent-*: by forwarders.
No matter which of the two RFC's SID prefers to reference, the description
of how forwarders should use headers is incompatible with what SID
specifies. This creates an issue for the MUA that I do not believe can be
resolved. It does not appear possible for a MUA to support both the SID
proposed use of Resent-*: and the traditional uses. As far as I know, there
is no reliable way for a MUA to determine whether a chain of Resent-*:
headers represents resending, forwarding, or a mixture of the two.
--
Seth Goodman
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com