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.
SHOULDs are only supposed to be violated if there's a compelling reason to do
so. Whatever that reason is would presumably also determine what alternative
strategy makes sense and whether or not resent- fields should be honored.
I'll try again, in small steps:
1. There exist autoresponders that use the From (or Sender) field.
Yes, but this doesn't answer the question of whether they're doing it for
legitimate reasons or because they are broken. If they are broken they should
be fixed, if they are doing it for legitimate purposes I don't think we should
be trying to second guess their behavior unless we can come up with some
fairly clear generalizations of how all this works I for one have never seen
before.
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.
Maybe, maybe not. It all depends on what the goal is.
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
Guidelines for when to use resent-from versus from would first have to consider
when it is appropriate not to use the return-path. I am very skeptical that
reasonable guidelines for this can be constructed.
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).
The "parochial" assumption you refer to is one which when violated routinely
causes a wide variety of problems operationally. You'll have to forgive me for
not wanting to engage in tacti endorsement of problematic practices, parochial
though that viewpoint may be.
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"? :-/
As Pete has already pointed out "voi ch'intrate" includes a lot of legitimate
uses.
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...
That may be but after all the discussion of this in DRUMS I'm dubious as to
what can be done.
Ned