Subject: Re: [Emailcore] Delivered-To issues

From: Dave Crocker <[email-masked]>
Date: Fri, 1 Jan 2021 08:24:29 -0800

On 12/31/2020 1:09 PM, Dave Crocker wrote:
> 3. ?

Drat.  Just started to throw some basic text into a draft and I've 
already run into an issue that might or might not creates some challenges.

Rather than pursue this in terms of fine-grained details, I'll ask you 
all to first consider what information we would like a recipient's MUA 
to have access to.  Then we can worry about how to engineer the details.

In the simple case, the RCPT TO contains an address and, indeed, the 
recipient's MUA resides at that address.  The message has gone through a 
single SMTP posting/delivering sequence.

Mailing lists (including Aliases) and other post-processing facilities, 
make things more interesting.  They create multiple posting/delivery 
sequences.  The final recipient address is not what the author generated 
in the initial RCPT TO field.

      Should the recipient's MUA have access to the /sequence/ of RCPT TO
      addresses used to get to them?

      Should they have only the final one?

      Should they have only the original one?

      Should they...?

Thoughts?

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "John Levine" <[email-masked]>
Date: 1 Jan 2021 17:17:23 -0500

>      addresses used to get to them?

If we're documenting existing practice, which I think would be a good idea, yes.

R's,
John

---

From: "John R Levine" <[email-masked]>
Date: 1 Jan 2021 17:23:41 -0500

> If we're documenting existing practice, which I think would be a good idea, yes.

Also remember that it's used to detect mail loops, and if you have a loop 
like A->B->C->A you need the history to see that you're looping.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: John C Klensin <[email-masked]>
Date: Fri, 01 Jan 2021 17:38:15 -0500

--On Friday, January 1, 2021 08:24 -0800 Dave Crocker
<[email-masked]> wrote:

> Drat.  Just started to throw some basic text into a draft and
> I've already run into an issue that might or might not creates
> some challenges.
> 
> Rather than pursue this in terms of fine-grained details, I'll
> ask you all to first consider what information we would like a
> recipient's MUA to have access to.  Then we can worry about
> how to engineer the details.
> 
> In the simple case, the RCPT TO contains an address and,
> indeed, the recipient's MUA resides at that address.  The
> message has gone through a single SMTP posting/delivering
> sequence.
> 
> Mailing lists (including Aliases) and other post-processing
> facilities, make things more interesting.  They create
> multiple posting/delivery sequences.  The final recipient
> address is not what the author generated in the initial RCPT
> TO field.
> 

Dave,

Despite your comment about semantics of the "for" clause (with
which I agree - see note about navigating 5321bis), I think two
parts of the above are fairly clear for another reason: if the
message passes through an MTA and is either passed along or
altered an any way, the general expectation is that it will put
in a Received: header field.  And stripping or altering prior
Received: headers or header fields is generally considered bad
practice [1].   If either of those things are not clear enough
in 5321bis, I encourage you to post a specific comment about
that and encourage either Alexex to open a ticket and/or me to
make Appendix G longer [2].

First, one Received: header field, at most one FOR clause and,
if FOR is present, its value is one (see the syntax for FOR)
Mailbox (or, in principle, a PATH, but source routes are rather
strongly deprecated (see Section 3.3 and Appendix C).  So, if
one wanted to have multiple destination addresses, there would
be no place to put them. In addition, while 5321 does not appear
to make the issue explicit, the discussion in Section 3.3 about
exposure of addresses can be read as discouraging use of FOR
clauses in trace information entirely.

Beyond that, while, as you have pointed out, there is no
specification of semantic in 5321 (or 821 or anything in
between), there are common-sense limitations on what can go
there.  For unextended SMTP MTA in mail transport (not
submission server) use, the only places a Mailbox can cone from
are a MAIL command (makes no sense), RCPT command(s), and prior
"Received:" header fields (which it is prohibited from
inspecting).  A submission server (or other MTA communicating
directly with an originating MUA if there is such a thing) might
have additional or alternate information that could, in
principle, be put into the FOR clause, but that is it.  So, if
something is going to be copied into a Received-type trace
field, it has to come out of the RCPT commands to the SMTP
server inserting the trace field (again, possibly excepting the
first hop).

That doesn't answer any of your questions above, but it imposes
rather severe constraints on the information that might be
available.

best,
   john

[1] See the paragraph starting "As discussed in Section 6.4..."
in Section 3.6.3.   I now wonder whether that section should be
retitled or reorganized because it contains significant text
that is not limited to Message Submission at all.  Watch for a
separate message on parts of those two sections.

[2] Except for order and unless one of us gets it wrong, those
options are essentially equivalent.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 2 Jan 2021 05:48:03 -0800

>       addresses used to get to them?

If the recipient MUA is to have access to the sequence of RCPT TO 
addresses, there are two ways to record this:

    1) A single Deliver-To: header field, showing the (full) sequence

    2) A sequence of Deliver-To: header fields, with each one showing 
one RCPT TO address.

The second would echo the approach taken for Received: header fields, of 
course.  It seems the easier choice.

Any site performing the delivery transition of responsibility, from the 
MHS to the addressee's control, slaps a Deliver-To: header field, with 
that one address on it.

The MUA can construct the sequence by scanning for these header fields, 
from botton to top of the header.

Thoughts?

Also, I think I've seen some expression of concern about *privacy* 
sensitivities, in showing previous Delive-To addresses.  I'm not finding 
myself understanding that well enough to write anything about it.  Can 
we get some discussion of it?

d/

ps. There often is confusion about what 'delivery' means.  This was a 
point of very focused discussion, during the development of RFC 5598, 
with a few folk driving home the rather unusual realization that it does 
not take place during a communication exchange, but takes place /within/ 
the MDA:

> 4.3.3.  Mail Delivery Agent (MDA)
> 
>    A transfer of responsibility from the MHS to a Recipient's
>    environment (mailbox) is called "delivery".  In the architecture, as
>    depicted in Figure 5, delivery takes place within a Mail Delivery
>    Agent (MDA) and is shown as the (D) transition from the MHS-oriented
>    MDA component (hMDA) to the Recipient-oriented MDA component (rMDA).

---

From: Jeremy Harris <[email-masked]>
Date: Sat, 2 Jan 2021 14:37:09 +0000

On 02/01/2021 13:48, Dave Crocker wrote:
> Any site performing the delivery transition of responsibility, from the MHS to the addressee's control, slaps a Deliver-To: header field, with that one address on it.

> delivery ... takes place /within/ the MDA

I think this implies that the address is site-meaningful and not
necessarily externally-meaningful nor qualified.  For example,
a message received with an envlope RCPT of "[email-masked]"
is locally aliased to "fred", has "Deliver-To: fred" prepended
and then added to fred's mailbox.
-- 
Cheers,
   Jeremy

---

From: "John Levine" <[email-masked]>
Date: 2 Jan 2021 13:48:42 -0500

In article <[email-masked]> you write:
>    1) A single Delivered-To: header field, showing the (full) sequence
>
>    2) A sequence of Delivered-To: header fields, with each one showing 
>one RCPT TO address.

The latter is existing practice, and I'm pretty sure nobody plans to change,
so please write it up that way.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Sat, 02 Jan 2021 16:09:49 -0500

--On Saturday, January 2, 2021 14:37 +0000 Jeremy Harris
<[email-masked]> wrote:

>> Any site performing the delivery transition of
>> responsibility, from the MHS to the addressee's control,
>> slaps a Deliver-To: header field, with
>> that one address on it.
> 

Thinking about the above comment and several others in this
thread, if "Envelope-to" actually has the semantics of "relevant
RCPT to associated with the current delivery" (Jeremy, I think
that is the case in exim, but please confirm), then it and
"Deliver-to" have different semantics and are processed at
different points in the delivery process -- the former by the
final MTA and the latter by the MDA.

Should we be defining both, making it clear that they are
different, and then making whatever recommendations seem
appropriate about which one (or both) should be provided?

    john

---

From: Jeremy Harris <[email-masked]>
Date: Sat, 2 Jan 2021 21:56:49 +0000

On 02/01/2021 21:09, John C Klensin wrote:
>  if "Envelope-to" actually has the semantics of "relevant
> that is the case in exim, but please confirm)

Yes.

Though it can be a list of such RCPTs, given aliasing that
results in a single message delivered from a single SMTP
session (after deduplication during delivery).

> appropriate about which one (or both) should be provided?

I agree that Envelope-To: and Delivered-To: are different.

I'm not convinced that this document is the right place
for either.  I guess there's a benefit in writing down the
definitions somewhere; the cost is "only" cruft that
obscures the minimum requirements for implementing an MTA.
-- 
Cheers,
   Jeremy

---

From: Dave Crocker <[email-masked]>
Date: Sat, 2 Jan 2021 14:15:26 -0800

On 1/2/2021 6:37 AM, Jeremy Harris wrote:
>> Any site performing the delivery transition of responsibility, from 
>> the MHS to the addressee's control, slaps a Deliver-To: header field, 
>> with that one address on it.
> 

It's possible that one or another address -- notably the last one -- 
might only be site-meaningful, I suppose.

I'd be inclined to have the spec mitigate against that, though, by 
requiring it list the address in a way that is globally useful.  That 
is, after all, what the right-hand-side domain name is for.

(Note that the left-hand side is only ever site-meaningful, for Internet 
mail.  There is never a global interpretation of the LHS.)

Also note that 'delivery' is a transition out of the handling system. 
Just prior to that moment, the address being used is a classic Internet 
mail address, which is globally meaningful.  And it is to that address 
that the mail is being delivered.

Discussions have tended to imply or assert that delivery occurs at 
various other places or that things that occurr afterwards are, 
nonetheless, inside the MHS.

If a message reaches the RCPT TO address, anything that happens 
afterwards, such as being sent on to a new address, happens after 
delivery and involves a new submission.

d/

---

From: "John Levine" <[email-masked]>
Date: 2 Jan 2021 17:26:58 -0500

>I agree that Envelope-To: and Delivered-To: are different.

Agreed.  What's the difference between Envelope-To and the
FOR clause in a Received header?

>obscures the minimum requirements for implementing an MTA.

I think we have general agreement that if this goes anywhere it's
a different draft, not 5321bis.

R's,
John

---

From: Jeremy Harris <[email-masked]>
Date: Sat, 2 Jan 2021 22:41:50 +0000

> FOR clause in a Received header?

Exim ducks, and only includes a "for" clause in the Received:
for single-RCPT messages.

On the other hand, a message which is (locally) aliased to
more than one destination name, which are then further aliased
to a single final name - will (assuming env-to was configured)
get an Envelope-To: with multiple copies of the RCPT.
-- 
Cheers,
   Jeremy

---

From: John C Klensin <[email-masked]>
Date: Sat, 02 Jan 2021 19:37:48 -0500

> obscures the minimum requirements for implementing an MTA.

My understand was that we had gotten to "separate document", or
at least "not in 5321bis" some day ago.  I hope that is the case
and that the perceived agreement holds.

best,
   john

---

From: "John R. Levine" <[email-masked]>
Date: 2 Jan 2021 22:56:55 -0500

> get an Envelope-To: with multiple copies of the RCPT.

I'm confused.  Does it add an env-to each time a message gets aliased to a 
new address?

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: Jeremy Harris <[email-masked]>
Date: Sun, 3 Jan 2021 09:46:57 +0000

On 03/01/2021 03:56, John R. Levine wrote:
> I'm confused.  Does it add an env-to each time a message gets aliased to a new address?

No, it's a one-time job adding one header but with multiple
addresses, being the sources for the multiple aliasing paths
that produced the message being delivered.
-- 
Cheers,
    Jeremy

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 5 Jan 2021 20:22:22 +0100

On Sun 03/Jan/2021 01:37:48 +0100 John C Klensin wrote:
> --On Saturday, January 2, 2021 21:56 +0000 Jeremy Harris wrote:
> 

This discussion brought up another defect of RFC 5321, methinks.  It does not 
define a straight line between an MTA and an MDA.  Section 4.4 says:

    When the delivery SMTP server makes the "final delivery" of a
    message, it inserts a return-path line at the beginning of the mail
    data.

Although the reasons for doing so are well explained, and are part of SMTP 
because of the reliability implications, inserting Return-Path: really looks 
like an MDA's job, not MTA's.  Perhaps, the text should say something like:

     When an SMTP server accepts a message for local delivery, it invokes a
     delivery agent passing to it the content and relevant parts of the
     envelope.  In particular, it MUST pass the <reverse-path>, which is used by
     the delivery agent to insert a return-path line at the beginning of the
     mail data.

In that case, mentioning that an MTA also passes the relevant <forward-path>, 
would not require to fulfill the steps (i)-(iv) of a previous message[*], 
because neither the MTA/MDA interface nor (all) the duties of MDAs are part of 
the specification.  Yet, it allows the I-D to mention non-normatively the names 
of Delivered-To:, Envelope-To:, and X-Original-To:.

jm2c
Ale
-- 

[*] https://mailarchive.ietf.org/arch/msg/emailcore/Vt1AboaP8j8rxnccedGvaLoPLyU

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 5 Jan 2021 20:26:25 +0100

On Fri 01/Jan/2021 23:23:41 +0100 John R Levine wrote:
> Also remember that it's used to detect mail loops, and if you have a loop like 
> A->B->C->A you need the history to see that you're looping.

Another use of Delivered-To:, by MUAs, is to fill the From: field in compose 
windows with the correct value, for users receiving multiple aliases.

Best
Ale
--

---

From: Dave Crocker <[email-masked]>
Date: Tue, 5 Jan 2021 11:30:51 -0800

On 1/5/2021 11:26 AM, Alessandro Vesely wrote:
> Another use of Delivered-To:, by MUAs, is to fill the From: field in 
> compose windows with the correct value, for users receiving multiple 
> aliases.

I assume you mean filling in the rfc 5322.From field of a /reply/ 
message is the utility you have in mind?

And yes, that seems a plausible use, to me.

d/

---

From: "John Levine" <[email-masked]>
Date: 5 Jan 2021 15:56:20 -0500

In article <[email-masked]> you write:
>like an MDA's job, not MTA's. ...

Having written a lot of code that does this, I can say that it is
often, maybe mostly, the MTA that drops the message into the mailbox.

Unless someone believes that the current text is confusing people or
causing interoperability problems, please leave it alone. We already
have plenty to do.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 5 Jan 2021 13:20:30 -0800

> causing interoperability problems, please leave it alone. We already

If it 'drops the messag into the mailbox' then i is acting in the role 
of an MDA.  By definition.

This exemplifies the different between abstract networking architecture 
-- which is what the MDA role is -- from specific software implementation.

d/

---

From: "John R Levine" <[email-masked]>
Date: 5 Jan 2021 16:53:31 -0500

On Tue, 5 Jan 2021, Dave Crocker wrote:

> If it 'drops the messag into the mailbox' then i is acting in the role of an 
> MDA.  By definition.

Indeed, but ...

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Tue, 5 Jan 2021 13:59:18 -0800

>>> causing interoperability problems, please leave it alone. We already

Your latter point is quite separate from the former.

The former should at least moderate how we talk about these issues. 
Hence my response about saying it is an MTA function.  It isn't.

Your latter point goes the question of whether to make changes, now, to 
the specification.  This is a highly constrained effort.  Your "Unless" 
is apt, of course.

d/

---

From: Claus Assmann <[email-masked]>
Date: Wed, 6 Jan 2021 05:53:34 +0100

> like an MDA's job, not MTA's.  Perhaps, the text should say something like:

sendmail has an option for this:

   5.4.  M -- Define Mailer
...
      P  This mailer wants a "Return-Path:" line.

i.e., the MTA can provide that line for/to the MDA.

Hence: please do not change the text.

-- 
Address is valid for this mailing list only, please do not reply
to it direcly, but to the list.

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 6 Jan 2021 12:23:36 +0100

On Tue 05/Jan/2021 22:53:31 +0100 John R Levine wrote:
>> If it 'drops the message into the mailbox' then it is acting in the role of an 
>> MDA.  By definition.
> 
> Indeed, but ...
> 

The only confusing point, IMHO, is the sneaky definition of a "delivery SMTP 
server".  That is not an MDA, since it serves SMTP, yet conflicts with Dave's 
definition, since it does delivery.

Best
Ale
--

---

From: "John Levine" <[email-masked]>
Date: 6 Jan 2021 12:07:17 -0500

In article <[email-masked]> you write:
>define a straight line between an MTA and an MDA. ...

I think the problem is worse than that. What we're calling an MDA
combines two separate things.  RFC 5598 calls them the hMDA and rMDA.

The hMDA is more or less the thing that takes an incoming message and
disposes of it, by storing it in a file or otherwise. Most MTAs have a
few simple default hMDA and ways to call out to more complex ones
like procmail, maildrop, and Sieve.

I don't see any point in trying to rewrite 5321 to try to separate out
an hMDA that might be in the MTA and might not.

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 7 Jan 2021 10:16:15 +0100

> an hMDA that might be in the MTA and might not.

Some points can be made without splitting hairs.  Defining the concept of MDA 
only serves to clearly state what is part of SMTP and what is beyond.

Best
Ale
--

---

From: Dave Crocker <[email-masked]>
Date: Thu, 7 Jan 2021 08:50:26 -0800

On 1/1/2021 2:38 PM, John C Klensin wrote:
> That doesn't answer any of your questions above,

No, it doesn't.

> but it imposes rather severe constraints on the information that
> might be available.

 From your note about Received: header fields, I have no idea what
constraints it imposes on Delivered-To.

d/

---

From: Dave Crocker <[email-masked]>
Date: Thu, 7 Jan 2021 08:56:34 -0800

> an hMDA that might be in the MTA and might not.

For the purposes of 5321bis, the hMDA/rMDA distinction is almost 
certainly overly precise.  It distinguishes between two components 
within a functional unit.

What's needed for the bis document is merely to slightly modify the 
current language to add MDA language and citation, rather than to do any 
substantial rewriting.

d/

---

From: John C Klensin <[email-masked]>
Date: Thu, 07 Jan 2021 16:09:04 -0500

--On Thursday, January 7, 2021 08:50 -0800 Dave Crocker
<[email-masked]> wrote:

>> but it imposes rather severe constraints on the information
>> that might be available.
> 
> 

Without seeing a more precise description of the actions and
semantics proposed for Delivered-To, preferably in the form of
an I-D, I don't know if it imposes any constraints or not.  

More generally, I got involved in this thread for two reasons:

(1) It was proposed that Delivered-to: be specified as part of
5321bis, an idea that I think has been rather thoroughly
rejected (IIR, thanks, in part, to your input).

(2) It was suggested at one point that Delivered-to: and
Envelope-to: were synonyms for the same function, field syntax,
and semantics.  I wanted to clarify whether that was correct; it
seems rather clear at this point that it was not.

Given those two issues, I question where further discussion of
Delivered-to: (or, for that matter, Envelope-to:) are
appropriate for this list.  Certainly they are out of scope for
the WG at present.  I assume they might come back into scope if
there are one or more published specifications and the WG starts
discussing the A/S, but we don't seem to be getting to that
point very quickly and I, at least, would like to see
discussions on this mailing list focused on 5321bis and 5322bis
with a minimum of other distractions.  

That is, of course, just a personal preference and YMMD.

    john

---

From: John C Klensin <[email-masked]>
Date: Thu, 07 Jan 2021 16:20:19 -0500

(note subject line change and see "p.s." at end)

--On Thursday, January 7, 2021 10:16 +0100 Alessandro Vesely
<[email-masked]> wrote:

>>> This discussion brought up another defect of RFC 5321,
>>> methinks.  It does not  define a straight line between an
>>> MTA and an MDA. ...
>> 
>> I think the problem is worse than that. What we're calling an
>> MDA combines two separate things.  RFC 5598 calls them the
>> hMDA and rMDA.
>> 
>> The hMDA is more or less the thing that takes an incoming
>> message and disposes of it, by storing it in a file or
>> otherwise. Most MTAs have a few simple default hMDA and ways
>> to call out to more complex ones like procmail, maildrop, and
>> Sieve.
>> 
>> I don't see any point in trying to rewrite 5321 to try to
>> separate out an hMDA that might be in the MTA and might not.
> 
> 
> Some points can be made without splitting hairs.  Defining the
> concept of MDA only serves to clearly state what is part of
> SMTP and what is beyond.

But, AFAICT, that brings things full circle to John L's point.
If there are some flavors of MDA that are really part of the MTA
function and some flavors that are not, then a crisp definition
of MDA that would fit well into 5321bis may not be possible
without splitting exactly those hairs.

I'd be happy to be wrong about this.  However, the only way I
can think of to would figure what can practically be done within
the text of 5321bis and constraints on it would be to see
proposed text, one that, as needed, references other standards
track documents for definitions.   I await such text.

best,
    john

p.s. I have changed the subject line because this is really
about MDAs, their definition, and their relationship to 5321bis.
Certainly it would be desirable for a description of
Delivered-To: (or Envelope-To:) in some other spec to reference
such text if it appeared in 5321bis but, as I suggested in a
note posted a few minutes ago, I believe that those (or other)
new headers are out of scope for 5321bis and the WG and do not
intend to spend more time reading that thread unless the WG
Co-chairs direct otherwise.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 7 Jan 2021 13:33:25 -0800

> If there are some flavors of MDA that are really part of the MTA

the expresses a conditional that is a non-sequitor.  MTAs are not MDAs. 
MDAs are not MTAs.  There are no architectural 'flavors' to this 
distinction.

> without splitting exactly those hairs.

Why do you want to create redundant -- or, worse, divergent -- text, 
given that the IETF spent 5 years formulating an architecture document 

...

If you have specific concerns about the consensus-based text in the 
document, please state them.

d/

---

From: "John R Levine" <[email-masked]>
Date: 7 Jan 2021 16:36:53 -0500

> without splitting exactly those hairs.

I took another look and I don't see anything to to change.  It says to add 
Return-Path at final delivery when "the message has left the SMTP 
environment."

The details of when that happens are quite specific to different 
implementations.  For example, on some systems, when one address is 
aliased to another it just substitutes the envelope address within the 
MTA, in others (mine for example) it's delivered to a stub that reinjects 
the message, adding and then stripping the Return-Path.  I am not aware of 
the current language causing any trouble for implementers so I really 
think we should leave it alone.

> such text if it appeared in 5321bis but, ...

It is my impression that we agree that if it goes anywhere it'll be a 
separate draft.

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Thu, 7 Jan 2021 13:53:30 -0800

On 1/7/2021 1:36 PM, John R Levine wrote:
> For example, on some systems, when one address is aliased to another it 
> just substitutes the envelope address within the MTA,

Except that that is not 'within' the MTA.  It's within the MDA, in 
architectural terms.

Changing a destination address specified by the author takes the message 
outside of message transport because it is a recipient-based action, not 
an author-based one.  And it isn't merely a 'routing' matter, which is 
the kind of redirection the the MHS does.

The import of treating aliasing as an MTA function is that any MTA can 
choose to do it.  Aliasing is then defined as a standard MTA function.

Aliasing is a streamlined version of mailing list behavior.  It is 
commonly implemented in MTA-related code because that's simpler than 
running a separate mailing list server.  That's an implementation point, 
not an architectural one.

d/

---

From: John C Klensin <[email-masked]>
Date: Thu, 07 Jan 2021 17:34:30 -0500

--On Thursday, January 7, 2021 16:36 -0500 John R Levine
<[email-masked]> wrote:

>> If there are some flavors of MDA that are really part of the
>> MTA function and some flavors that are not, then a crisp
>> definition of MDA that would fit well into 5321bis may not be
>> possible without splitting exactly those hairs.
> 
> I took another look and I don't see anything to to change.  It
> says to add Return-Path at final delivery when "the message
> has left the SMTP environment."
> 
> The details of when that happens are quite specific to
> different implementations.  For example, on some systems, when
> one address is aliased to another it just substitutes the
> envelope address within the MTA, in others (mine for example)
> it's delivered to a stub that reinjects the message, adding
> and then stripping the Return-Path.  I am not aware of the
> current language causing any trouble for implementers so I
> really think we should leave it alone.

Exactly.
   john

---

From: Ned Freed <[email-masked]>
Date: Thu, 07 Jan 2021 15:31:28 -0800 (PST)

> Return-Path at final delivery when "the message has left the SMTP

Sounds correct to me.

> think we should leave it alone.

That may be true for return-path, but what about success DSNs? You may be able
to undo the insertion of a return-path, but I doubt very much that anyone
implements NOTARY support using a "undo the DSN you just sent" mechanism to do
it.

There's also the relatied issue that AKAIK aliases operations don't reenter the
MTA through a submission operation. 

And this gets to my issues with intertwining aliasing with delivery, and the
suggestion that we can just drop the discussion of aliases versus mailing
lists.

If we do this then delivery becomes a meaningless abstraction with no
substance. And while I agree with Dave that we must not let implementation 
details define our model, I get very nervous when there's nothing whatsoever in
my implementation - or any of several other implementations I'm familiar with -
that corresponds to a major delineation in the model.

> It is my impression that we agree that if it goes anywhere it'll be a

Yep. And while I don't really mind discussing it on this list, if it's getting
confused with the revision or delaying it the delivered-to discussion needs to
be moved elsewhere.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Thu, 7 Jan 2021 19:00:58 -0800

On 1/7/2021 3:31 PM, Ned Freed wrote:
> If we do this then delivery becomes a meaningless abstraction with
> no substance. And while I agree with Dave that we must not let 
> implementation details define our model, I get very nervous when
> there's nothing whatsoever in my implementation - or any of several
> other implementations I'm familiar with - that corresponds to a major
> delineation in the model.

Consider:

2.3.11.  Mailbox and Address
...
    standard mailbox naming convention is defined to be
    "local-part@domain"; contemporary usage permits a much broader set of
    applications than simple "user names".  Consequently, and due to a
    long history of problems when intermediate hosts have attempted to
    optimize transport by modifying them, the local-part MUST be
    interpreted and assigned semantics only by the host specified in the
    domain part of the address.

Interpretation of Local-part is inappropriate for an MTA. Having the 
Local-part be globally opaque is an important feature of Internet Mail. 
  (It has enabled quite a bit of easy extensibility of the decades.)

That makes interpretation of local-part an MDA function.

While, yes, aliasing typically goes through completely different code 
paths than normal 'delivery' and 'submission', we should focus, instead, 
on scope and responsibility, rather than code.

Either aliasing is in (or after) MDA functionality, or we need to define 
aliasing as an integrated part of MTA functionality, which means 
local-part is /not/ opaque.

Or we need to define multiple types of MTAs.  But I thought that was the 
point behind defining MSA and MDA architectural components.

> Yep. And while I don't really mind discussing it on this list, if
> it's getting confused with the revision or delaying it the
> delivered-to discussion needs to be moved elsewhere.
Where should it be discussed?  I understand the charter issue, but 
really, this is the currently-active venue for email focus in the IETF. 
  (And with my typical naivety, or at least optimism, I'm hoping that 
dealing with Deliver-To goes quickly.  I expect to circulate an I-D next 
week.  Maybe this weekend.)

---

From: Ned Freed <[email-masked]>
Date: Fri, 08 Jan 2021 07:30:35 -0800 (PST)

>     domain part of the address.

There's just one problem with this text: This isn't true. It has never been
true, and no amount of repetition, compliance language, or anything else will
make it true.

The obvious example, which I have pointed out many times, is when mailing lists
have to decide whether or not a subscribe/unsubscribe request is a match to an
address on the list. This means choosing whether or not other people's
local-parts are case-sensitive. (There's also the issue of things like
unnecessary quoting, which in the interests of my own sanity I'm going to
ignore.)

The decision is almost always that they aren't case-sensitive, because if you
assume they are, the doofus who keeps losing track of his subscriptions and
likes writing his or her name in various combinations of mixed caps starts
complaining about getting multiple copies. But either way this is absolutely a
case where the list is interpreting the local-part.

Similar tests for address equality are made by filtering systems for various
reasons. These tests may go so far as to assume specific formats for
subaddressing.

UTF-8 local-parts make this even messier. Right now I expect that
i;ascii-casemap is being used, but if UTF-8 local-parts ever do see significant
deployment worldwide, this may change, because I expect that people aren't any
more consistent about the case of the accented characters they use than they
are with the unaccented ones.

Another example: Secondary MXes may use forward-caching schemes. In some cases
they make educated guesses about the validity of local-parts of the domains
they forward to. Sometimes they do this with knowledge about the actual host.
And sometimes they just do it.

More generally, delegation of authority to interpret the local-part of address
happens pretty regularly. Customer requests to implement partial authority over
local-parts bother me, but... the customer is always yada yada yada.

And then there's SRS, which if you do the full bit involves interpreting the
first four characters of a local-part specially if they happen to be "SRS0" or
"SRS1".

Of course it's tempting to yell, "Bad Puppy!" and get out the rolled-up
newspaper to deal with some of these, but when Office 365 implements SRS...
good luck.

>   (It has enabled quite a bit of easy extensibility of the decades.)

The actual requirement that has been successful in practice is "interpret only
when absolutely necessary, and only with consent". (Joining a mailing list
means consenting to that list's rules as to how it interprets your address.)
And yes, this has worked very well. But it's not the hard-and-fast rule we've
documented.

> That makes interpretation of local-part an MDA function.

Well, if you want to define the function of an MDA and thus "delivery" as
"interpret the local part and nothing else", and leave "final delivery" for
adding return-path, generating DSNs, etc., that's close to being workable. You
still have the problem that there needs to be a path from the MDA back to the
MTA that doesn't involve the MSA or message submission, but that's doable.

I don't think that's how most people interpret the word "delivery" though.

> on scope and responsibility, rather than code.

FWIW it doesn't, at least not in our server.

And while it's coding thing, I think some mention needs to be made of milter,
if only in passing since I don't think there's anything we can do about it.

Most MTAs have a well defined and well structured way of determine address
locality, one that matches up to the email architecture. And since this tends
to either be fully hardcoded or implemented in a base configuration that's
rarely changed, it's a significant contributer to why email hasn't had that
many problems with people messing around with addresses when they shouldn't.

Milter changes this. Since it operates at the MTA level, and includes add and
delete recipient that don't respect address ownership, it lets any yahoo who is
capable of filling in the blanks in a generic milter server template do really
bad things.

Again, I don't think there's anything we can do about it other than to continue
to hold the line on not mangling other people's addresses. But whether this and
other threats justifies ignoring the complex cases in favor of delivering a
simple message (sic) is the part of the decision we need to make here.

> local-part is /not/ opaque.

Translucent, maybe?

> point behind defining MSA and MDA architectural components.

I see the main point behind the MDA and MSA as being the places where final
delivery and submission occur. This approach is also far from perfect: Among
other things it makes a mess of the placement of sieve, since the sieve
specification is clear that sieve can happen anywhere from right after the
determination an address is local to long after final delivery. (And subsequent
specifications have extended sieve to operate on message motions inside the
mesage store, including messages which may never have touched the transport 
infrastructure, which while useful is something of an architectural disaster.)

But we already have to accept that the block diagrams don't align with
implementations; we may also have to accept that they oversimplify actual flows
between components. (We have multiple customers who use MTAs queues to
implement a backup facility for their message store. I wish I was making this
up, but I'm not.)

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Fri, 8 Jan 2021 10:21:05 -0800

On 1/8/2021 7:30 AM, Ned Freed wrote:
> address on the list.

Except that a mailing list operates /after/ delivery.  (And before 
re-posting.)

I specify the address [email-masked].  My message travels to an 
ietf.org email server and it resolves emailcore, handing the message 
over to the mailing list system.(*)

The message has been delivered to the address I specified.

What the MLM does after that is secondary, for the purposes of this thread.

d/

(*) And the 'resolves' and 'handing over' activities are by an MDA.

---

From: Ned Freed <[email-masked]>
Date: Fri, 08 Jan 2021 11:56:16 -0800 (PST)

> Except that a mailing list operates /after/ delivery.  (And before

First of all, I was not talking about the list itself, but rather the tools
that maintain it.

There's also the case where the list does similar comparisons in order to
implement restrictions like "you have to be on the list to post" - and these
often implement some understanding of subaddress semantics - and yes, those do
operate after delivery, but this is all beside the point. The fact is that
mailing lists and mailing list managers routinely violate the rule against
interpretation and application of semantics only by "the host specified in the
domain part of the address".

> What the MLM does after that is secondary, for the purposes of this thread.

That might have been reasonable had you not justified the rule by making the
point that "Having the Local-part be globally opaque is an important feature of
Internet Mail." But you did.

And that is in fact what justifies having the rule, not the far lesser claim
that the pure transport infrastructure alone should not interrpet local parts.
That rule by itself is almost worthless, since then all I need to do to justify 
whatever mangling I want to do of other people's address is say, "But I'm an
MDA!"

				Ned

---

From: John C Klensin <[email-masked]>
Date: Fri, 08 Jan 2021 16:12:35 -0500

--On Friday, January 8, 2021 07:30 -0800 Ned Freed
<[email-masked]> wrote:

>>     "local-part@domain"; contemporary usage permits a much
>>     broader set of applications than simple "user names".
>>     Consequently, and due to a long history of problems when
>>     intermediate hosts have attempted to optimize transport
>>     by modifying them, the local-part MUST be interpreted and
>>     assigned semantics only by the host specified in the
> There's just one problem with this text: This isn't true. It
> has never been true, and no amount of repetition, compliance
> language, or anything else will make it true.
 
> The obvious example, which I have pointed out many times, is
> when mailing lists have to decide whether or not a
> subscribe/unsubscribe request is a match to an address on the
> list. This means choosing whether or not other people's
> local-parts are case-sensitive. (There's also the issue of
> things like unnecessary quoting, which in the interests of my
> own sanity I'm going to ignore.)
>...

Ned, this may be another fork in the conversation, but...

I agree with you about the "not true and has never been true"
part, even though it was in 2821 and I can't remember where it
come from before that.  I suspect we were trying to make a
strong point about relays not fussing with addresses in the hope
of improving things because they thought they understood what
was going on and getting it wrong.  Examples involving "%" or
"!" in the local-part come to mind immediately even though they
are much less relevant today than they were twenty years ago.
And, with the best of intentions, we (or I) didn't get it quite
right (or, from the standpoint of this particular discussion,
even nearly right).

So, speaking both as editor and as an individual participant,  I
would welcome a proposal as to how to fix it, especially if we
are not the only ones who believe that, as written, it isn't
true/correct.

As far as unnecessary quoting is concerned, see G.9 of
draft-ietf-emailcore-rfc5321bis-01, Ticket #21 and maybe #35.
I would certainly be happy to clean that up if we can at this
stage.  If we cannot do the cleanup in 5321bis (and part of it
in 5322bis), I'd favor putting "don't do that unless you really
need to because bad thing happen" language into the A/S.

    john

---

From: Dave Crocker <[email-masked]>
Date: Fri, 8 Jan 2021 13:26:14 -0800

On 1/8/2021 1:12 PM, John C Klensin wrote:
> Examples involving "%" or
> "!" in the local-part come to mind immediately

Addressing conventions like those pertain to other email services, not 
Internet Mail.  Processing those is done by a gateway, not an MTA.

d/

---

From: Dave Crocker <[email-masked]>
Date: Sat, 9 Jan 2021 14:47:49 -0800

Ned,

> First of all, I was not talking about the list itself, but rather the
> tools that maintain it.

For reference, I still do not see how mailing lists are relevant to a 
discussion about transport rules.  But see my next comment.

> There's also the case where the list does similar comparisons in
> order to implement restrictions like "you have to be on the list to
> post" - and these often implement some understanding of subaddress
> semantics - and yes, those do operate after delivery, but this is all
> beside the point. The fact is that mailing lists and mailing list
> managers routinely violate the rule against interpretation and
> application of semantics only by "the host specified in the domain
> part of the address".

We have a fundamental disconnect, here, which well might mean we do NOT 
have a fundamental disagreement.  (And the end of your note seems to 
have anticipated or discerned the former, if not the latter.)

It might be that I needed to be clearer:  My focus, about the opacity of 
the left-hand side, pertains only to classic, MHS-level -- MTA -- 
behavior.  NOT with possible, idiosyncratic behaviors at the MUA level, 
which would include MLMs.

I can imagine a view that it should also include MUA level, as well as a 
view that it should not.  But I'll suggest that it is an entirely 
unrelated discussion, which isn't needed for the current work.  (Neither 
5321bis nor Deliver-To:)

>> I specify the address [email-masked].  My message travels to
>> an ietf.org email server and it resolves emailcore, handing the
>> message over to the mailing list system.(*)
> 
> That might have been reasonable had you not justified the rule by
> making the point that "Having the Local-part be globally opaque is an
> important feature of Internet Mail." But you did.

Would "opaque to the Mail Handling Service" be acceptable, since that's 
the scope I'd intended?

> And that is in fact what justifies having the rule, not the far
> lesser claim that the pure transport infrastructure alone should not
> interrpet local parts. That rule by itself is almost worthless, since
> then all I need to do to justify whatever mangling I want to do of
> other people's address is say, "But I'm an MDA!"

I've read the above a few times, and I'm probably missing the point. 
Saying that the transport service treats the LHS as opaque, until 
reaching a place under the administrative control for the RHS, doesn't 
seem worthless to me.  Lesser, yes, but far from worthless.

As for the local domain's LHS namespace, it doesn't strike me as taking 
a liberty or all that odd to say it can interpret strings for its own 
namespace however it wants.  As in: of course.

As for declaring the MDA role whimsically, it seems to me not a small 
thing to note that that declaration means the message is no longer in 
the MHS and has moved into user-space.

What am I misunderstanding?

d/

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 10 Jan 2021 19:29:06 +0000

Hi all,

> On 8 Jan 2021, at 21:12, John C Klensin <[email-masked]> wrote:
> 

Yes, please. Let’s change subject and create a new ticket, if needed.

Best Regards,
Alexey, as co-chair

---

From: Brandon Long <[email-masked]>
Date: Tue, 12 Jan 2021 12:18:03 -0800

> we get some discussion of it?

We previously had some multiple recipients listed in headers, and removed
that for
privacy reasons.

Having multiple Delivered-To indicating multiple RCPT TO in the same
transaction will
share to each recipient the other recipients that got it, which is a
violation of say the BCC
expectations at the least.  Our use case was attempting multiple recipients
in the Received
FOR clause, but the issue is the same regardless of whether it is the
client or server in the
MTA transaction.

Having multiple Delivered-To because the message is forwarded is not the
same type of privacy
violation, as it is sequential, it's how the message reached them.  Some
examples were given in
the similar usage of our per-recipient BCC header, where if you BCC "
[email-masked]"
is then exposed to the recipients on that list.  Overall, we didn't think
that was a likely violation, especially since
the potential for leaking by the list expansion itself was likely high.

>From the rest of this discussion, it seems this is likely more an issue
with Envelope-To than with Delivered-To, as
"delivery" would imply a single destination.  For that, I would recommend
being similar to the discussion of BCC header
where you can bifurcate the messages per-recipient so each recipient only
sees their path.

Brandon

> Emailcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emailcore
>