Re: Resent- header fields

Douglas Otis <[email protected]> Tue, 31 May 2005 13:35:41 -0700
Newsgroups gmane.ietf.mxcomp
Message-ID <[email protected]>
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