Subject: RE: TECH-ERROR (-core): misuse of Resent- fields

From: "Harry Katz" <[email-masked]>
Date: Tue, 7 Sep 2004 10:33:02 -0700

On Tuesday, September 07, 2004 2:31 AM, Tony Finch wrote:

> Secttion 7.2 recommends a use of the Resent-From: header 
> field in direct contradiction to RFC 2822, which describes 
> how those fields are currently used.
> 
> Tony.

This was discussed way back in April.  See my post of 4/20/2004 at
http://www.imc.org/ietf-mxcomp/mail-archive/msg00950.html.  I've
extracted the relevent portion below:

[snip]
Unfortunately, the RFC is by no means clear on this point.  In fact it's
quite ambiguous.  

First the RFC states that Resent- headers SHOULD be added whenever a
user "reintroduces" a message into the transport system, without clearly
defining what "reintroduces" means or how it occurs.  Now presumably
under circumstances of some description, having seen a message delivered
into my inbox I can press a hypothetical 'reintroduce' button (if not,
then what are the headers for?). Having just received the message (so
the original recipient has seen final delivery), the reintroduction must
be headed for some other location; it must be a "forward" by *some*
definition of the word.

The RFC also talks about the "user" reintroducing the message without
specifying which piece of software is acting on the user's behalf.  The
key point is this: if it's OK (indeed recommended) to add these headers
when a human "reintroduces" a message into the transport stream, surely
it's OK for an automated agent to do that on a user's behalf.  

It boils down to the fact that the language quoted is not consistent: it
says use the headers, but not with "forwarding" (without defining the
term) yet clearly their only utility  is in conjunction with forwarding
by any reasonable definition of the word.

Lastly, the RFC states that Resent- headers are not "intended" for use
in some types of forwarding, but *does not* prescribe that they MUST NOT
be used in this way.  

Thus, we believe our proposed use of Resent- headers is indeed
permissible.  I would further suggest, given the threat posed to email
by the spam crisis, that this would be an "opportune moment" to broaden
the "intended" use of these fields.

---

From: Tony Finch <[email-masked]>
Date: Tue, 7 Sep 2004 18:47:17 +0100

> Unfortunately, the RFC is by no means clear on this point.  In fact it's

I disagree.

> Now presumably under circumstances of some description, having seen a
> message delivered into my inbox I can press a hypothetical 'reintroduce'
> button (if not, then what are the headers for?).

It's not hypothetical: Pine has such a function (which it confusingly
calls "bounce"). We use it quite frequently to resend a message to the
address it should have been sent to in the first place (e.g. from the
webmaster team to the postmaster team).

> by any reasonable definition of the word.

It has a whole paragraph dedicated to defining the two usual meanings of
forwarding, viz. encapsulation forwarding (using the MIME type
message/rfc822 or non-MIME encapsulation in the body of the new message)
and alias forwarding (as implemented by the Sieve redirect command and the
Unix .forward and /etc/aliases files). "Reintroduction" is explicitly
defined to be neither of these actions, whether or not you think it is a
kind of forwarding.

It is unfortunate that most of the terminology in this area is ambiguous,
and this is not helped by willful misinterpretation of a document that is
trying to be clear about which meaning is intended.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
WHITBY TO THE WASH: NORTHEAST VEERING EAST 4 OR 5. FAIR. GOOD. SLIGHT OR
MODERATE.

---

From: "Carl S. Gutekunst" <[email-masked]>
Date: Tue, 07 Sep 2004 12:44:55 -0700

>webmaster team to the postmaster team).
FWIW, Apple's OS X client has the same feature, called "Redirect." It 
sets Resent-Date, -From, -To, and -Message-ID correctly.

I thought it was alreadly widely understood that Sender-ID violates the 
RFC2822 defined semantics for Resent-From ?

<csg>

---

From: Mark Lentczner <[email-masked]>
Date: Tue, 7 Sep 2004 14:30:30 -0700

> sets Resent-Date, -From, -To, and -Message-ID correctly.

FWIW^2, Apple's OS X client also displays these fields for received 
messages that have them!  The From: field is shown in the message list 
in the From column.  But, when you open the message to read it, the 
headers at the top have Resent-From and Resent-To right above the 
corresponding From and To lines.  Neat!

	- Mark

---

From: David Woodhouse <[email-masked]>
Date: Wed, 08 Sep 2004 17:15:05 +0100

> the "intended" use of these fields. 

Why reuse existing fields which mean something different, instead of
adding new fields or perhaps adding to the Received: header?

It seems strange to hijack the Resent-* fields instead of just doing
something new. 

Since we're discussing RFC2822 -- your mail software fails to follow the
recommendation of §3.6.4 that reply messages SHOULD have "In-Reply-To:"
and "References:" fields. Please could you ensure that this gets fixed.
It is impolite to participate in public fora while breaking the
threading information.

-- 
dwmw2