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.

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