On Tue, 11 Nov 2003, Phil Pennock wrote:
> Indeed; but it does have "whilst processing -t", which is a good time to
> apply this sort of fix-up; as opposed to general operation.
Some changes were made in that area: this is from the 4.20 ChangeLog:
56. The behaviour of -t in the presence of Resent- headers has been changed,
for compability with Sendmail and other MTAs. Previously, Exim gave an
error, because it is not clear from RFC 2822 how this might be handled. It
turns out that MUAs don't seem to follow what RFC 2822 says, and any MUA
that uses -t with Resent- ensures that there is only one set of Resent-
header lines (usually by renaming others to X-Resent-xxx). So now Exim will
take recipients from all the Resent- header lines instead of the usual
ones.
> By my re-reading of the RFC2822 stuff yesterday, if there's a header
> line that isn't Resent-*: between Resent-*: then those are separate
> instances;
So what? There doesn't *have* to be such a separator. Consider:
Resent-From: ...
Resent-Date: ...
Resent-Cc: ...
Resent_To: ...
Resent-From: ...
Resent-Date: ...
Resent-Cc: ...
To which set does the Resent-To: belong?
> what we're seeing is a Resent bounce of a mail which was
> already Resent, but that earlier one had erroneously put the Resent
> lines at the end of the headers; Exim added lines to that earliest,
> lowest point, instead of to the current set, the first group nestled
> between Received: 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."
The second clause in that sentence doesn't seem to say the same thing as
the first clause. And we also have this paragraph:
"It is important to note that the header fields are not guaranteed to
be in a particular order. They may appear in any order, and they
have been known to be reordered occasionally when transported over
the Internet. However, for the purposes of this standard, header
fields SHOULD NOT be reordered when a message is transported or
transformed. More importantly, the trace header fields and resent
header fields MUST NOT be reordered, and SHOULD be kept in blocks
prepended to the message. See sections 3.6.6 and 3.6.7 for more
information."
That seems clearer about prepending, but note the "kept in blocks",
which suggests to me that interleaving with Received: is bad.
The examples in the RFC don't show Resent- and Received: in the same
example, unfortunately.
> The problem here is _caused_ by a mailing-list manager but Exim's
> actions are in effect adding incorrect information -- if it went to the
> _first_ set of Resent- headers, and only those, then it would be
> correct; the current behaviour isn't correct.
I have changed what Exim does with Resent- headers several times after
complaints, grumbling the while about imprecise specifications. Exim
doesn't try to identify different header sets; this seemed to me like a
mug's game. This is a comment from the code:
------------------------------------------------------------------
The presence of resent-headers in the message makes -t horribly ambiguous.
Experiments with sendmail showed that it uses recipients for all resent-
headers, totally ignoring the concept of "sets of resent- headers" as described
in RFC 2822 section 3.6.6. Sendmail also amalgamates them into a single set
with all the addresses in one instance of each header.
This seems to me not to be at all sensible. Before release 4.20, Exim 4 gave an
error for -t if there were resent- headers in the message. However, after a
discussion on the mailing list, I've learned that there are MUAs that use
resent- headers with -t, and also that the stuff about sets of resent- headers
and their ordering in RFC 2822 is generally ignored. An MUA that submits a
message with -t and resent- header lines makes sure that only *its* resent-
headers are present; previous ones are often renamed as X-resent- for example.
Consequently, Exim has been changed so that, if any resent- header lines are
present, the recipients are taken from all of the appropriate resent- lines,
and not from the ordinary To:, Cc:, etc.
------------------------------------------------------------------
So what exactly *is* Exim doing to your message? If you've posted that,
I'm afraid I've forgotten the details. Please remind me.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book: http://www.uit.co.uk/exim-book
