Subject: Resent- header fields

From: "william(at)elan.net" <[email-masked]>
Date: Sun, 29 May 2005 07:31:06 -0700 (PDT)

You probably all know that I have a problem with how SID drafts says
Resent header fields are to be used...

Well, just out of curiosity I wanted to know how they are they really 
used in the real world and lucky me I use one of those mail clients
that actually supports it (though I've never tried this feature before
and kind of came upon it by accident).

Anyway, I'm going to demonstrate (and also test it with mail list) in
a moment as I forward copy of this post back here with resent headers.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: "william(at)elan.net" <[email-masked]>
Date: Sun, 29 May 2005 08:55:20 -0700 (PDT)

On Sun, 29 May 2005, william(at)elan.net wrote:

> You probably all know that I have a problem with how SID drafts say

Ok, the demonstration with mail lists did not worked quite as I would have
liked - mxcomp list-processor stripped off the Resent- header fields and 
spf-discuss did not let the mail through at all (probably is doing 
checking on return-path and saw it was not the one I signed up with,
even though From and everything else is correct). Anyway, here is what
mail header looks like when I resent the message:

-------------------------------------------------------------------------

Date: Sun, 29 May 2005 07:31:06 -0700 (PDT)
From: "william(at)elan.net" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: [spf-discuss] Resent- header fields
Sender: [email-masked]
Reply-To: [email-masked]

<http://v2.listbox.com/doc/help_sub?list_name=[email-masked]
List-Subscribe: <mailto:[email-masked]>,
     <http://v2.listbox.com/subscribe/?listname=[email-masked]>
List-Unsubscribe: <mailto:[email-masked]>,

<http://v2.listbox.com/member/unsubscribe/?listname=[email-masked]
     ox.com>
Errors-To: [email-masked]
ReSent-Date: Sun, 29 May 2005 07:39:31 -0700 (PDT)
Resent-From: "william(at)elan.net" <[email-masked]>
Resent-To: [email-masked]
ReSent-Subject: [spf-discuss] Resent- header fields
ReSent-Message-ID: <[email-masked]>
--------------------------------------------------------------------------

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.

---
William Leibzon, Elan Networks:
  mailto: [email-masked]
Anti-Spam and Email Security Research Worksite:
  http://www.elan.net/~william/emailsecurity/

---

From: Douglas Otis <[email-masked]>
Date: Tue, 31 May 2005 13:35:41 -0700

> 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