Subject: [Emailcore] Ticket #4: Exploders seem to be prohibited from adding List-* header fields

From: Alexey Melnikov <[email-masked]>
Date: Sun, 29 Nov 2020 18:27:03 +0000

Dear collegues,

After some discussion of this ticket during IETF 109 and on the mailing 
list it became clear that there was no consensus for my earlier strawman 
proposal. I would like to make a new strawman proposal:

3.9. Mailing Lists and Aliases

     [...] When a message is
     delivered or forwarded to each address of an expanded list form, the
     return address in the envelope ("MAIL FROM:") MUST be changed to be
     the address of a person or other entity who administers the list.
     However, in this case, the message header section (RFC 5322 [11])
     MUST be left unchanged; in particular, the "From" field of the header
     section is unaffected.

As John Klensin pointed out, the last MUST is still correct for aliases. 
So my new strawman proposal is as follows:

In Section 3.9:

REMOVE:

     However, in this case, the message header section (RFC 5322 [11])
     MUST be left unchanged; in particular, the "From" field of the header
     section is unaffected.

The current Section 3.9.1 reads:

> 3.9.1.  Alias
>
>    To expand an alias, the recipient mailer simply replaces the pseudo-
>    mailbox address in the envelope with each of the expanded addresses
>    in turn; the rest of the envelope and the message body are left
>    unchanged.  The message is then delivered or forwarded to each
>    expanded address.

ADD after it the following text:

     Aliases MUST leave the message header section (RFC 5322 [11])
     unchanged; in particular, the "From" field of the header
     section is unaffected.

(Section 3.9.2 talks about mailing lists and already has text that 
contradicts this MUST in section 3.9. So removing text from 3.9 will 
address that contradiction).

Best Regards,

Alexey, as a co-chair

---

From: Dave Crocker <[email-masked]>
Date: Sun, 29 Nov 2020 11:12:46 -0800

On 11/29/2020 10:27 AM, Alexey Melnikov wrote:
> I would like to make a new strawman proposal:

I will, instead, suggest first having a clear, focused discussion that 
produces architectural consensus on why the specification for the 
Internet mail transfer protocol needs to have text about the treatment 
of mail after delivery, concerning re-posting.

An author specifies a recipient address.  The mail reaches that address. 
  The receiving site has a mechanism that is under the control of the 
specified addressee, not the author or the originator, which then 
submits the message for further processing.

The fact that one version of this mechanism is implemented in software 
that also performs MTA functions does not make it an MTA function.  At 
best, it's an MDA function.

That is, it is entirely outside the scope of SMTP.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "John Levine" <[email-masked]>
Date: 29 Nov 2020 20:26:21 -0000

In article <[email-masked]>,

>submits the message for further processing.

I'm not sure that's the right answer but I think we agree that sec 3.9
no longer describes the way that mail systems work today.

I'd take out everything about mailing lists in 3.9.2 other than the
observation that they act as full MUAs. There is certainly still a lot
of alias style forwarding happening and the question is whether
there's anything useful to say about it. The implicit advice not to
change the envelope bounce address seems likely to cause as many
problems as it solves. ("Why am I getting bounces from [email-masked]
when I sent mail to [email-masked]?") The advice not to change the
other headers seems more like local policy than interoperability.

R's,
John

-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 30 Nov 2020 09:38:34 +0100

>>of mail after delivery, concerning re-posting.

The spec must clarify the semantic meaning of a Mailbox.  Putting forth the 
concept of forwarding and exemplifying a couple of its instantiations delivers 
an important aspect of that.  For example, a lawmaker wishing to regulate 
responsibilities for sending and accepting SMTP messages has to be well aware 
of this point.  (Yes, I fantasize that lawmakers read technical specs.)

> no longer describes the way that mail systems work today.

+1

> observation that they act as full MUAs.

Section 3.9.2 uses the term MUA.  I don't think it's correct, as the "U" for 
"user" suggests human interaction.  Could we use MLM, as in RFC 6377?

> There is certainly still a lot of alias style forwarding happening and the
> question is whether there's anything useful to say about it. The implicit
> advice not to change the envelope bounce address seems likely to cause as
> many problems as it solves. ("Why am I getting bounces from [email-masked] 
> when I sent mail to [email-masked]?")

Also "Aha, mail sent to [email-masked] bounces from [email-masked]".

> The advice not to change the other headers seems more like local policy than
> interoperability.

Limiting to trace fields could be set as an MTA peculiarity.  That is, SMTP 
manages the envelope, not the content, except for trace fields.

Best
Ale
--

---

From: Dave Crocker <[email-masked]>
Date: Mon, 30 Nov 2020 05:38:47 -0800

On 11/30/2020 12:38 AM, Alessandro Vesely wrote:
>>> I will, instead, suggest first having a clear, focused discussion 
>>> that produces architectural consensus on why the specification for 
>>> the Internet mail transfer protocol needs to have text about the 
>>> treatment of mail after delivery, concerning re-posting.
> 
> 
> The spec must clarify the semantic meaning of a Mailbox.  Putting forth 

It is a bad idea to have multiple specifications defining the same thing:

RFC 5598, 3.1 Mailbox:

>       "A mailbox receives mail.  It is a conceptual entity that does not
>       necessarily pertain to file storage."  [RFC5322]
> 
>    A mailbox is specified as an Internet Mail address <addr-spec>.

> the concept of forwarding and exemplifying a couple of its 
> instantiations delivers an important aspect of that.  

Already done in RFC 5598.

So...

> 2.2.2.  Relay
...
>    In other words, email scenarios can involve three distinct
>    architectural layers, each providing its own type of data of store-
>    and-forward service:
> 
>       *  User Mediators
> 
>       *  MHS Relays
> 
>       *  Packet Switches

and

> 3.4.1.  Message-ID
...
>    o  If a message is forwarded by a Recipient, what is forwarded is a
>       new message.

and

> 5.  Mediators
...
> Basic message transfer from Author to Recipients is accomplished by
>    using an asynchronous store-and-forward communication infrastructure
>    in a sequence of independent transmissions through some number of
>    MTAs.  A very different task is a sequence of postings and deliveries
>    through Mediators.  A Mediator forwards a message through a
>    re-posting process.

and

> 5.1.  Alias
> 
>    One function of an MDA is to determine the internal location of a
>    mailbox in order to perform delivery.  An Alias is a simple
>    re-addressing facility that provides one or more new Internet Mail
>    addresses, rather than a single, internal one; the message continues
>    through the transfer service, for delivery to one or more alternate
>    addresses.  Although typically implemented as part of an MDA, this
>    facility is a Recipient function.  It resubmits the message, although
>    all handling information except the envelope Recipient
>    (rfc5321.RcptTo) address is retained.  In particular, the Return
>    Address (rfc5321.MailFrom) is unchanged.
> 
>    What is distinctive about this forwarding mechanism is how closely it
>    resembles normal MTA store-and-forward relaying.

(please take special note of those last two lines. /d)

> Section 3.9.2 uses the term MUA.  I don't think it's correct, as the "U" 
> for "user" suggests human interaction.  Could we use MLM, as in RFC 6377?

The UA/MTA distinction has been used since roughly 1980.  Its use does 
not automatically mean direct user interaction but, rather, acting on 
behalf of the user.  Hence, 'agent'.

Again...

RFC 5598, Section 4.2.1 Message User Agent (MUA)

>  A Message User Agent (MUA) works on behalf of User Actors and User
>    applications.  It is their representative within the email service.

The IETF spent 5 years developing RFC 5598.  It should use it.

d/