Hi, the following paragraphs in 2822upd-01 are incompatible with
RFC 4406:
Resent fields are used to identify a message as having been
reintroduced into the transport system by a user. The purpose of
using resent fields is to have the message appear to the final
recipient as if it were sent directly by the original sender, with
all of the original fields remaining the same. Each set of resent
fields correspond to a particular resending event. That is, if a
message is resent multiple times, each set of resent fields gives
identifying information for each individual time. Resent fields are
strictly informational. They MUST NOT be used in the normal
processing of replies or other such automatic actions on messages.
Note: Reintroducing a message into the transport system and using
resent fields is a different operation from "forwarding".
"Forwarding" has two meanings: One sense of forwarding is that a
mail reading program can be told by a user to forward a copy of a
message to another person, making the forwarded message the body
of the new message. A forwarded message in this sense does not
appear to have come from the original sender, but is an entirely
new message from the forwarder of the message. On the other hand,
forwarding is also used to mean when a mail transport program gets
a message and forwards it on to a different destination for final
delivery. Resent header fields are not intended for use with
either type of forwarding.
RFC 4406 uses Resent-* in "automatic actions on messages", both for
redistribution (mailing lists) and redirection (alias forwarding to 3rd
parties). RFC 4407 uses Resent-* not only for "strictly informational"
purposes, it evaluates Resent-* to determine the "PRA" (its "purported
responsible address"). RFC 4405 uses this "PRA" in an SMTP extension.
This incompatibility was approved in an appeal. For various technical
reasons I think that the "PRA" is an excessively poor emulation of the
Return-Path, and that it's stupid to introduce an entity like the "PRA"
at this point in time shortly after RFC 3834 closed the last loophole
where mailbots still sent auto-responses to other addresses: Almost
all auto-responses are now based on the Return-Path, NDRs, DSNs, MDNs,
it makes no sense to introduce a new "PRA" sometimes resulting in the
Sender-address which should never be used for auto-responses.
BUT. But while I hate the "PRA" it is not for the formal reason that
it is incompatible with 2822. In fact I think 2822upd should fix this
issue. For starters anything wishing to go to "draft standard" will
have to show in its "implementation and interoperability report" why
there is a weird construct like the Resent-Sender at all:
Who needs a Resent-Sender ? Who implements it ? Why is the complete
Resent-nightmare not supported in RFC 4409 8.1 "may add sender" ? Why
is there more than one Resent-* block incompatible with RFC 821, and
resulting in yet another incompatibility with RFC 4407 ? Why can't we
deprecate this rubbish in favour of the much clearer MIME forwarding ?
Frank