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 ?
Ignoring PRA, there are two current sides to the handling of Resent-*:
message submission and message display. An 822 display end can probably
muddle along OK when presented by a 2822 message. An 822 message
submission server will probably do something wrong when fixing up a 2822
message that has been re-sent more than once. A 2822 submission server
will have to have some fairly good heuristics to gracefully handle 822
re-sent messages. Things get even more interesting if an 822-re-sent
message is then 2822-re-sent, because the header order of the original
re-sending has to be fixed.
Sender-ID effecively requires that this kind of submission server fix-up
must be implemented by MTAs and MDAs that do aliasing / redirecting /
forwarding.
While I'm at it: How's that supposed to work with RfC 2476bis
8.1 "MAY add Sender" ? Apparently 2476bis 8.1 is still based
on the old 822-concept of Resent-* (?)
It doesn't address Resent-* at all so one would have to work out for
oneself how a submission server should treat them. This is clearly a bug.
(Is it too late to fix submit-bis now it is in the RFC Editor queue?)
Specifying what to do with them is, however, tricky. Sender-ID lacks this
specification too.
Tony.
--
f.a.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.
-------
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