On Tuesday 01 May 2007 20:12:47 ned+ietf-822(_at_)mrochek(_dot_)com wrote:
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?
No. First, RFC 3834's SHOULD is more of a suggestion than a rule; "MUST"
would be about as close as any RFC gets to specifying a rule.
I'll try again, in small steps:
1. There exist autoresponders that use the From (or Sender) field.
2. There may exist autoresponders that use Resent- versions (I
haven't looked for them, and I don't generally resend messages);
at least for the specific example given, these produce less
astonishment than the above.
3. Therefore, rather than a blanket "automatic processing should always
use From/Date/etc. rather than Resent- versions", it would be prudent
to carefully consider and document specific cases where
a) use of Resent- versions is preferable to non Resent- versions
b) vice-versa
c) neither should be used
d) depends on what the user wants
4. Ideally, the Resent- fields would be described in sufficient detail to
clarify these issues; 2822 is fairly good w.r.t. quantity, placement, and
syntax; semantics are described fairly well; who/what should produce,
modify, or consume the fields is lacking (see RFC 4249 for a list of the
types of things that implementers may find useful, resulting from a
discussion on this list a few years ago).
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.
That seems to be based on a rather parochial assumption about message
delivery architecture; in many cases, mail arrives in a POP/IMAP/whatever
mailbox at an ISP's server, where some agent has made "final" delivery,
whereupon a user can access the message (complete with Return-Path
field), and in so doing can redirect/retransmit to one or more mailboxes
beyond the "final" delivery (hence the quotation marks).
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.
"Lasciate ogne speranza"? :-/
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...
The specific document alluded to uses "user" to include gateways and list
expansion. I suspect that's not what is meant by the 2822 text above, but I
cannot find a definition in 2822 of precisely what is meant there by "user".
I would prefer to reserve "user" to refer to an end-point producer or recipient
of messages, which may be a human, or might be some autonomous system.
"User agent" would be an entity (typically software) operating on behalf of
a user (q.v.) and possibly in interaction with same; such operations might
include managing address books, ensuring proper syntax of generated
messages, presentation of content (N.B. presentation might include
text-to-speech), properly generating/extracting attachments, etc.
Beyond those, we could define "gateway", possibly including distinctions
among various types of gateways, and other terms as needed. Evidently
a better definition of resending seems to be needed...