[ On Wednesday, November 12, 2003 at 10:51:23 (+0000), Philip Hazel wrote: ]
> Subject: Re: [Exim] Resent- headers
>
> One doesn't usually expect to see anything nestled between Received:
> headers. The whole area is so ill-defined that different software does
> all kinds of different things. If I use Pine to "bounce" a message, for
> example, it renames all the Received: headers to X-Received: and puts
> the Resent- headers at the end of the header lines. I don't think this
> is erroneous, though RFC 2822 is unclear. It says
>
> "Each new set of resent fields is prepended to the message;
> that is, the most recent set of resent fields appear earlier in the
> message."
That's obviously bogus and misleading in the bigger picture.
The confusion w.r.t. the word "set" now in RFC 2822 and on this list may
derive from the way the original wording uses "set" to indicate either
the headers of the original message or the "resent-" prefixed headers of
the forwarded message:
Note: In general, the "Resent-" fields should be treated as con-
taining a set of information that is independent of the
set of original fields. Information for one set should
not automatically be taken from the other. The interpre-
tation of multiple "Resent-" fields, of the same type, is
undefined.
I.e. "set" in this context really has nothing whatsoever to do with
adding additional "resent-" headers to a message already containing
some, or trying to deal with the case where it might appear a message
has been resent by a semi-broken MUA that added new "resent-" headers to
a message already containing old "resent-" headers and without modifying
the latter, or anything like that.
The MTA has a very simple job when it comes to using headers to route a
message (i.e. when acting as "sendmail -t") and there should never be
any confusion here. If there are "resent-" headers then they are to be
used _exactly_ as if they were the non-prefixed "set" and the
non-prefixed "set" _must_ be ignored. I.e. if there are multiple
"resent-to:" headers then the message must be routed to all recipients
from all those headers just as it would be for multiple "to:" headers.
I.e. y'all have to get it out of your heads that two or more
"destination" headers has anything to do with different "sets" -- it
clearly does not. Order of destination headers is irrelevant and there
can only ever be two different "sets" of routing and identifying
headers, one with the prefix "resent-" and one without. If there are
multiple destination headers of the same name in the same set then the
only prudent and safe thing for "sendmail -t" to do is to treat them as
if they were combined.
I.e. there cannot be multiple "sets" of "resent-" prefixed headers any
mor than there can be multiple "sets" of normal headers. There are only
the normal headers and, optionally in a forwarded message, the "resent-"
prefixed headers -- one "set" of each.
Remember too that when a message is received by SMTP the internal
headers have no bearing on the routing or handling or identification of
the message and their content is totally irrelevant. The message
headers must be treated as part of the body -- i.e. totally ignored.
Note that an LDA should never add any missing destination or reciptient
headers unless it is almost certain that it has the correct values to
place in them. I.e. when a message is received via SMTP and is about to
be delivered locally but it has no recipient address then it is fair to
add a "to:" or "resent-to:" header as appropriate (if there are _any_
"resent-" prefixed headers then the latter), containing the address from
the SMTP envelope "RCPT TO:" command. Adding a missing "from:" or
"resent-from:" using the SMTP envelope "MAIL FROM:" address is quite a
bit more risky as it's far more likely to be incorrect. A missing
"message-id:" or "resent-message-id:" could be added by the LDA, but the
benefit of doing so is tiny and doing so may lead to confusing the
ultimate recipient.
The MUA's job w.r.t. forwarding is more interesting.
In the situation where a set of "resent-" prefixed headers already
exists then it seems logical to preserve them when resending the message
again. I.e. if the MUA is told to resend a message already containing a
"set" of "resent-" headers such as this:
Resent-From: "Greg A. Woods" <woods@???>
Resent-To: The Weird PostMaster <postmaster@???>
Resent-Date: Wed, 12 Nov 2003 13:52:29 +0500 (EST)
Resent-Message-ID: <20031112135229.BF9283@???>
In-Reply-To: <20031111102939.GA30064@???>
Message-ID: <Pine.SOL.4.58.0311121025020.15405@???>
References: <20031110184018.GA31635@???>
<Pine.SOL.4.58.0311110926030.29019@???> <20031111102939.GA30064@???>
Date: Wed, 12 Nov 2003 10:51:23 +0000 (GMT)
From: Philip Hazel <ph10@???>
Reply-To: exim-users@???
To: Phil Pennock <phil.pennock@???>
cc: Exim Users <exim-users@???>
Subject: Re: [Exim] Resent- headers
The the result it submits to the MTA (e.g. stdin of "sendmail -t") might
look like this:
Resent-From: The Weird PostMaster <postmaster@???>
Resent-To: The Planix PostMaster <postmaster@???>
Resent-Resent-Date: Wed, 12 Nov 2003 13:52:29 +0500 (EST)
Resent-Resent-Message-ID: <20031112135229.BF9283@???>
Resent-Resent-From: "Greg A. Woods" <woods@???>
Resent-Resent-To: The Weird PostMaster postmaster@???
In-Reply-To: <20031111102939.GA30064@???>
Message-ID: <Pine.SOL.4.58.0311121025020.15405@???>
References: <20031110184018.GA31635@???>
<Pine.SOL.4.58.0311110926030.29019@???> <20031111102939.GA30064@???>
Date: Wed, 12 Nov 2003 10:51:23 +0000 (GMT)
From: Philip Hazel <ph10@???>
Reply-To: exim-users@???
To: Phil Pennock <phil.pennock@???>
cc: Exim Users <exim-users@???>
Subject: Re: [Exim] Resent- headers
and the MTA (the "sendmail -t" the above headers are fed to in this
case) would be required to prepend new pair of "resent-message-id" and
"resent-date" headers in order to complete the new "set". The message
would then be routed to <postmaster@???> -- i.e. to the address
given in the "Resent-To:" header.
This concept of preserving the original "resent-" headers by prefixing
an additional "resent-" prefix should be very obvious given the original
definition of forwarding in RFC 822 section 4.2:
4.2. FORWARDING
Some systems permit mail recipients to forward a message,
retaining the original headers, by adding some new fields. This
standard supports such a service, through the "Resent-" prefix to
field names.
Whenever the string "Resent-" begins a field name, the field
has the same semantics as a field whose name does not have the
prefix. However, the message is assumed to have been forwarded
by an original recipient who attached the "Resent-" field. This
new field is treated as being more recent than the equivalent,
original field. For example, the "Resent-From", indicates the
person that forwarded the message, whereas the "From" field indi-
cates the original author.
I.e. it is only logical to prepend "resent-" to the existing "resent-"
prefixed fields that were used to route and identify the previous
message such that the new recipient will know that the forwarded message
was originally forwarded from someone other than the most immediate
forwarder. I.e. the "resent-resent-from" header indicates the person
who forwarded it to the person who forwarded it to the most recent
recipient, and the original "from" header still indicates the original
author.
The only sane alternative for the MUA is to delete all the original
"resent-" headers when forwarding a message.
As for "received:" headers, well the prudent thing for the MUA to do is
to preserve them all, in their original order, when forwarding a message.
--
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <woods@???>
Planix, Inc. <woods@???> Secrets of the Weird <woods@???>
