Re: [2822upd] Resent-* MUSTard

> On Tuesday 01 May 2007 20:12:47 [email protected] 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