Tony Finch <dot(_at_)dotat(_dot_)at> writes:
On Thu, 24 Jun 2004, Roy Badami wrote:
Any MTA not supporting the Responsible Submitter extension that
redirects a message from the address listed in the RFC 2821 RCPT TO
command is nonetheless encouraged to modify the message according
to (a) and (b) above.
This is clearly what we want, and what we expect (prior to flag day).
(b) conflicts with the semantics of the Resent- headers specified by
RFC 2822. This should be made more clear.
The subject of whether forwarders are supposed to add Resent-* headers
came up on the SPF list also. Here is the response I posted there.
In one of the IETF jabber sessions, I raised this very point. See the
the 15:58:43 entry of:
(I've included a copy of this part of the log at the end of this post)
After the jabber session I asked Pete Resnick, the editor of RFC2822
to clarify the issue. He said that when RFC2822 was written, the
language about forwarders was intended to be about .forward files.
Further, he said, now that the spam discussion has been raised, some
consider forwarding services, such as pobox.com, to be gateways rather
than forwarders. That is, the email is coming out of the transport
system and being re-introduced, just like a mailing list.
Now, at the time, I really didn't press Pete on the issue, mostly
because Pete didn't seem to be very interested in talking about it.
After that one very quick exchange, I let the issue drop.
It wasn't very long before I realized that his explantion didn't make
much sense. RFC2822 was written in 2001, *long* after both the spam
issue and forwarding services like pobox.com had been around. The
caller-id PRA algorithm requires unix .forward files to add these
headers, so even if you exclude things like pobox.com, even the
"original intension" of the RFC2822 language would have to be changed.
Also note that the newest version of the Caller-ID PRA algorithm
depends on undocumented, non-standard and depreciated headers, such as
X-Envelope-To:. Go figure.
But, anyway, it is going to be hard to argue against the
"interpretation" of RFC2822 by its editor. More over, the AD isn't
asking any pointed questions about whether one RFC can standardize
stuff that other RFCs seem to frown on. I guess if the IESG doesn't
complain, we don't need to worry about it.
The jabber log is:
[15:58:53] <wrs1864> does RFC2822 allow an email forwarder to
modify/add the Resent-* and Sender:headers
[15:59:09] <wrs1864> Also, you can just use the domain name part of
the SRS address<eot>
[15:59:39] <Harry> Resent- headers are trace records, they get added
to the top of the headers just as Received headers do.
[16:00:08] <Harry> I'm not sure about Sender headers. I think there's
only supposed to be one per message, but I've seen examples
that have > 1. <eot>
[16:00:10] <resnick> <rts> On what 2822 allows
[16:00:30] <mrose> pete, <cts>
[16:00:47] <resnick> What 2822 "allows" (more to the point, intends as
meanings of the fields) is:
[16:01:15] <resnick> Resent-*: Trace fields added by the
resender. Matches proposed use.
[16:02:01] <resnick> Sender: Added by the original sender if that
differs from the author. But that would invalidate current
list use, so it's questionable whether that matches
[16:02:03] <resnick> <eot>
[16:02:05] <wrs1864> <rts> RFC2822 and email forwarder
[16:02:18] <mrose> wrs,<cts>
[16:02:35] <wrs1864> My reading of RFC2822 explicitly says that email
forwarders are not supposed to use Resent-*
[16:02:37] <wrs1864> <eot>
[16:02:42] <resnick> <rts>
[16:03:44] <mrose> all - i'd like to wrap things up as we're coming to
the end of the window...
[16:03:47] <mrose> resnick, cts
[16:04:37] <resnick> Shortening what I was going to say: It could be
argued that .forward type forwarding is or is not
reasonable to use Resent-*.