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