On Sun January 16 2005 18:45, william(at)elan.net wrote:
At the same time for majority of other headers (except Resent and Received)
adding additional header line with same name is not allowed.
That is not quite correct; the maximum number of instances of
a particular header field in a message or MIME-part header
varies according to the field. RFC 2822 contains a detailed
table for the basic fields; several RFCs introducing extension
fields likewise indicate the maximum number of instances per
header (some however, fail to do so, and that is an ambiguity
in the specification).
The common
practice has been to simply replace original header line with new one.
The accepted practice is that an SMTP server "receives mail
from an SMTP client and transmits it, without modification to
the message data other than adding trace information" (RFC 2821
section 2.3.8). N.B. "without modification". Also STD 3 (Host
Requirements) section 5.2.6: "An Internet host that is
forwarding a message but is not a gateway to a different mail
environment (i.e., it falls under (1) or (2)) SHOULD NOT alter
any existing header fields, although the host will add an
appropriate Received: line as required in Section 5.2.8.".
Altering message header fields during transport invariably
leads to problems; the classic example is the originator-
supplied Reply-To field, which is sometimes inappropriately
altered by mailing list expanders, causing a variety of
problems. Such a reprehensible practice is the equivalent
of a postal service opening letters and altering the
content.
But
its really good for debugging of email routing problems to have seen what
the value has been
It's never supposed to be altered (with specific exceptions
for MSAs under specific conditions, and for gateways)! And
specific standards for specific types of gateways (e.g. RFC 2156)
may make provision for retaining content in a manner which
preserves it for debugging.
If the problem that you're trying to solve is that some non-
gateway systems are irresponsibly altering message content,
than an appropriate solution is to convince the (ir)responsible
parties not to make alterations. Please don't screw things
up for everybody by encouraging such unnecessary modification
of message content!
[...] Original- header lines are more like email trace header fields (and
similarly multiple of same named ones can be in the message) and have same
purpose to help track changes to email message, they should not be viewed
as replacement for real headers or used directly by MUA.
Gack, NO! There are already well-defined
Original-Encoded-Information-Types, Original-Envelope-ID,
Original-Message-ID, and Original-Recipient fields. Mindlessly
prefixing "Original-" to fields will result in the inability
to distinguish an Original-Message-ID field from a Message-ID
field that has been so altered.
Now as has been mentioned, I plan to document these Original- headers in the
Internet draft so if you like to provide some feedback
Please don't. It's the worst idea I've heard in a long time.
Accidentally I can't find any good way to register with IANA a group of
headers
like Original- (as common prefix) as RFC3864 specifies only how to do it for
one particular header field. Please suggest what to do about it.
You can't find it because field names don't work that way. There
simply are no generic prefixes. Each field is separately
defined (see, for example, RFC 2822's definitions for Resent-To,
Resent-From, Resent-Cc, Resent-Date, Resent-Message-ID, Resent-Sender,
Resent-Bcc, and the deprecated Resent-Reply-To fields (N.B. there are
no other Resent- fields!)).