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