In
<Pine(_dot_)SOL(_dot_)4(_dot_)58(_dot_)0406202003040(_dot_)28614(_at_)orange(_dot_)csi(_dot_)cam(_dot_)ac(_dot_)uk>
Tony Finch <dot(_at_)dotat(_dot_)at> writes:
On Sun, 20 Jun 2004, Greg Connor wrote:
Excluded? why? RFC2822 forbids us from adding headers to a message? I
don't believe that is really true.
It says that the Resent- headers are for MUA resending, not for MUA
encapsulated-message forwarding and not for /etc/aliases or .forward
forwarding. Read the paragraph starting "Note:" in section 3.6.6 of RFC
2822.
In one of the IETF jabber sessions, I raised this very point. See the
the 15:58:43 entry of:
http://www.xmpp.org/ietf-logs/marid(_at_)ietf(_dot_)xmpp(_dot_)org/2004-04-19.html
(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.
-wayne
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
reality.
[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-*.