On Sun, 2005-05-29 at 08:55 -0700, william(at)elan.net wrote:
On Sun, 29 May 2005, william(at)elan.net wrote:
To be fair, I don't quite agree with how Pine did it as it put Resent-
below the reset of the message header and not above it. I looked at
RFC2822 and it says there:
"All of the resent fields corresponding to a particular resending of the
message SHOULD be together. 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."
I have a feeling its the word "prepended" that caused problem as some
may understand as something being added before (below) the rest of the
header data, but its use in RFC2822 seems consistent with how Received
fields are added on top of the rest of the header data and example with
Resent- is also such that they are added on top.
Besides that Pine also quite interestingly changed the data and replaced
all trace fields with "X-" (but did not touch any other fields then
Received or Return-Path). In any case this all very clearly demonstrates
that its new message and not the original when the message is resent.
So the use of this for standard non-MUA forwarding is not correct at
all and would be in conflict with current systems that currently do
use the fields (even if not quite right according to RFC2822, which BTW
I intend to report as bug to Pine developers). Yes I know this all does
not matter to Microsoft - none of their MUAs like outlook support Resent -
but it does not mean others dont and protecting those other systems that
follow standards should be more important.
The use of the RFC822 standard does not mandate the ordering of headers.
RFC822 is to be supplanted by a proposed standard, which is about to
become less relevant itself, with yet another proposed standard. Due to
a long legacy of use, email compliance should expect an ability to
handle standard formats, in addition to accommodating changes being made
in proposed standard formats.
-Doug