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.

OK, so the logic here is that if you're going to break the rules, you should as
your second option fall back to behavior that doesn't cause quite as much
breakage? I'm sorry, but I see little advantage to describing this approach,
esecially since it would drag 2822bis into dealing with issues having more to
do with SMTP envelopes than with message formats.

> 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.

At the point where the redirection is done there isn't a return-path, only
an envelope. 2822bis does not and should not discuss envelope issues - that's
for 2821bis.

It is *absolutely* the case that a return-path field should not be part of the
redirected message. The creation of the return-path is the job of the final
delivery agent.

>    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".

I'm sorry, but I see no point in discussing the setting of a field which at
best would be used by private arrangement to some sort of non-SMTP submission
agent.

> 3. I did NOT suggest that a "Resent-Return-Path" field might be in order...

THank goodness.

> 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.)

This I do agree with, although I'm not entirely clear what should be
said.

> 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...

I also have no problem with clarification of definitions, but specific
suggestions would be nice...

				Ned