Re: [2822upd] Resent-* MUSTard

On 2007-05-01, Pete Resnick wrote:

> ...or creating address book entries or filtering based on author of 
> the text or sorting by date or..... Hey, since there's so many things 
> that MUAs might automatedly do on messages in which they should look 
> at From/Date/etc. instead of Resent-From/Resent-Date/etc., why don't 
> we say "replying and things like that." Oh.....

It appears from recent discussions that some clarification may well be
desirable w.r.t. what is or isn't desired, and perhaps we need some
discussion about desirability issues.

To take an example, consider a case where A sends a message to B, and B
resends to C, who happens to be on vacation.  Now a vacation autoresponder
SHOULD use the Return-Path field for notification (3834 sect. 4), but:
1. Many autoresponders use the From field. In this case, A might not
   know who C is, hasn't sent the message to C, and may well be confused
   if he gets an auto-response referring to a message that it is claimed
   he sent to C.  In this case using the From field yields worse results
   than using Resent-From (or Resent-Sender vs. Sender); B probably knows
   C, and might conceivably be interested to know that the meesage that
   he resent to C might not be read for a while.
2. Which Return-Path (2821 issue resurfaces); 2822 says "No other fields
   in the message are changed when resent fields are added", and taken at
   face value, that includes Return-Path.  What the recipient gets depends
   on whether SMTP (2821) is involved (if C is local to B, some non-SMTP
   local delivery might be used, in which case Return-Path might still be
   present, still pointing to A, and leading to the same sort of confusion
   as above).  Even if SMTP is used, the issues of whether or not to elide
   Return-Path when adding a new one, and which Return-Path field should
   be used if there is more than one such field determine what may happen.
   2822 is also unclear on this; see above re. "No other fields [...]",
   vs. the ABNF (and text "an optional") specification of at most one
   Return-Path field vs. "Except for destination address fields [...] the
   interpretation of multiple occurrences of fields is unspecified".
3. I did NOT suggest that a "Resent-Return-Path" field might be in order...
4. Security Considerations should mention the possibilities for abuse (e.g.
   using the rules re. non-use of Resent- fields by "automated actions"
   to disguise the source of spam, etc.)

Clear definitions may help greatly. E.g. 2822 is pretty clear that the
author is specified by the From field; therefore Resent-From specifies
something other than the author.  One area that needs clarification is the
definition of "user", which should be consistent among the documents
discussing applications of the message format.  2822 says w.r.t. Resent-
fields "Resent fields are used to identify a message as having been
reintroduced into the transport system by a user"; I know of at least one
document that states that a mailing list exploder is a "user", which is
probably inconsistent with 2822's intent regarding Resent- fields...