Subject: [ietf-smtp] draft-crocker-email-deliveredto

From: George Michaelson <[email-masked]>
Date: Mon, 2 Aug 2021 09:01:26 +1000

Hi Dave. I like the draft. I would like the draft to go the distance
to publication.

It's kind-of obvious, but I sometimes think you can't be too obvious in an RFC.

The utility of having envelope available in canonical form for eg
procmailrc or delivermail processing is high. I know I'd want this and
have argued with operators of my MTA about it in the past.

-G

---

From: "John Levine" <[email-masked]>
Date: 1 Aug 2021 22:45:23 -0400

>have argued with operators of my MTA about it in the past.

This version of the draft is better but it it still says nothing about
the existing use of Delivered-To.

Postfix, Courier and qmail have added Delivered-To for a very long
time, more than 20 years for qmail. They use it for loop detection. If
a message already has the same Delivered-To it's about to add, they
bounce the message. Exim adds a similar header but calls it
Emvelope-To:. 

It turns out not to be useful for procmail. MTAs invariably have other
ways to tell procmail what the current delivery address is, via a command
line argument or environment variable, and it's up to the local
configuration whether to add the Delivered-To before the message is
passed to procmail.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Sun, 1 Aug 2021 20:01:44 -0700

> the existing use of Delivered-To.

John,

      1. "still' implies that there was a previous call for text about 
history of use. Sorry I don't recall that request and a quick scan of 
the archive didn't produce it.

      2. One reason for a discussion of prior use might be to explore 
variations in use or benefit.  The current document provides that as 
guidance rather than history.  Is there some specific benefit you have 
in mind that the draft does not already satisfy.

      3. Documenting prior use adds the challenges of getting the fact 
precise and correct in that history lesson.  Why is that needed here?

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: George Michaelson <[email-masked]>
Date: Mon, 2 Aug 2021 13:03:00 +1000

> bounce the message. Exim adds a similar header but calls it

Prior use is a problem, I agree.

> configuration whether to add the Delivered-To before the message is

I simply don't agree John. The lack of promotion of the envelope to
header means there is one, and one only point where you can "know" the
value which in your model is out of scope/standards, and doesn't work
all the time: Thats the basis of my argument with the MTA operator:
they don't tell me this in a single, consistent manner.

These "other ways" only work during initial delivery. They cannot be
re-applied because the ENV/CMDLINE information is lost. So, in an
MTA->MS model, the envelope data has been long shredded, if I run an
IMAP fetch to local processing.  I can't process the data because it
was lost, when the MTA handed off.

"up to local configuration" is handwaving for "not my problem" and
"turns out not to be useful" is highly conjectural, its your opinion.
I disagree. It's useful.

-G

---

From: "John R Levine" <[email-masked]>
Date: 1 Aug 2021 23:08:33 -0400

>     1. "still' implies that there was a previous call for text about history 
> of use. Sorry I don't recall that request and a quick scan of the archive 
> didn't produce it.

We've been through this before.  We have two decades of existing practice 
with Delivered-To.  An experiment that ignores that is a pretty strange 
experiment.

>     3. Documenting prior use adds the challenges of getting the fact precise 
> and correct in that history lesson.  Why is that needed here?

See above.  The draft describes loop breaking as though it's hypothetical, 
which it is not.

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

---

From: "John R Levine" <[email-masked]>
Date: 1 Aug 2021 23:10:56 -0400

> Prior use is a problem, I agree.

I don't see why it's a problem.  The reasonable thing for this draft to do 
is to describe the well established existing practice, since that practice 
is not going to change.

> I simply don't agree John.

Um, I'm not speaking hypothetically here.  I've been running mail through 
pracmail with this setup for 20 years.  A lot of other qmail and procmail 
and courier users do, too.

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Sun, 1 Aug 2021 20:21:34 -0700

On 8/1/2021 8:08 PM, John R Levine wrote:
> See above.  The draft describes loop breaking as though it's 
> hypothetical, which it is not.

'"One use can be for detecting a delivery sequence loop."

That's not the language of a hypothetical, John.  That's a description 
of a use.

If the sentence were intended to suggest a hypothetical use, it might 
cast the use of possibly worth considering or might say that it might be 
used this way.  Like the preceding sentence.(*)

d/

(*) 
https://www.thoughtco.com/how-to-discuss-hypothetical-situations-in-english-4177287

---

From: Dave Crocker <[email-masked]>
Date: Sun, 1 Aug 2021 20:24:33 -0700

On 8/1/2021 8:08 PM, John R Levine wrote:
> We've been through this before.  We have two decades of existing 
> practice with Delivered-To.  An experiment that ignores that is a pretty 
> strange experiment.

I note that you did not cite prior discussion of including history. 
This leaves your use of 'still' as still unanswered.

I note that you have also not answered the question of importance to the 
utility of the current specification, in reviewing the history.  This is 
not an academic paper; it's a document specifying a use.  The IETF 
doesn't use 'experiment' the way research does.

d/

---

From: George Michaelson <[email-masked]>
Date: Mon, 2 Aug 2021 13:24:58 +1000

> is to describe the well established existing practice, since that practice

It's a problem the draft has to address. I think we're agreeing.

> and courier users do, too.

Now re-process that mail honouring the original Envelope logic.

Or, move to a Mail provider who doesn't use the same mechanisms to
pass Envelope to you. Remember, you're a corner case, you are not an
average Mail user by any stretch. I think you're in the minority of
mail consumers, saying that because 1% can handle this, there's no
need for standards work.

I know you were not speaking hypothetically. I know people can do
things with cmdline and env.  And yes, I know use of this Delivered-To
mechanism will be not guaranteed either, although if it was adopted by
the big 4 mail providers, it would become significantly more
widespread.

cheers

G

---

From: "John R Levine" <[email-masked]>
Date: 2 Aug 2021 11:24:21 -0400

> It's a problem the draft has to address. I think we're agreeing.

On further thought, it's a fatal and incurable flaw in the draft.  See 
next message.

> Now re-process that mail honouring the original Envelope logic.

You can't.  When the MTA runs procmail or maildrop, it passes a lot of 
context beyond the envelope address.  For more details, see the 
documentation for any of the MTAs that have been delivering through 
procmail and its ilk for 30 years.

Regards,

---

From: "John Levine" <[email-masked]>
Date: 2 Aug 2021 14:22:46 -0400

On further thought, this experiment makes no sense.

We have two decades of experience with Delivered-To. It has multiple
compatible implementations that have have worked the same way for decades.

Since there is no chance that the implementations will change,
assuming we still care about interoperation, we can write a draft
describing how it actually works, based on the existing
implementations. That way, if other MTAs want to implement it, they
can interoperate. The obvious candidates to write it are people
familiar with the existing defacto spec, such as Viktor, Sam, and me.

If someone wants to run an experiment with some other delivery marker
with yet to be defined semantics, sure go ahead, but call it something
else like Delivery-Address to avoid confusion with the existing
well-defined Delivered-To.

R's,
John

PS: Isn't this how IETF standards used to work, write a couple of separate implementations,
see if they interoperate, and then write it up as a draft standard?

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 2 Aug 2021 14:43:12 -0400

> compatible implementations that have have worked the same way for decades.

One thing to keep in mind wrt. the existing implementations of
"Delivered-To:" (used purely for loop detection) is that the format of
the payload is an internal detail of the receiving LDA.

In particular, it is not unreasonable for the LDA to record an encoded
HMAC of the recipient address in the localpart, thereby making more
difficult abuse of "Delivered-To:" to elicit bounces of the message to
the purported envelope sender (because it is then harder for the
attacker to predict the magic "Delivered-To:" value).

For use-cases such as fetchmail demultiplexing multi-recipient upstream
mailboxes, other ad hoc headers (e.g. X-Original-To:, ...) have been used
by various sites.

    http://www.postfix.org/pipe.8.html
    http://www.postfix.org/local.8.html
    http://www.postfix.org/virtual.8.html

The Delivered-To and X-Original-To (and similar) headers address separate
concerns and should not be conflated.

-- 
    Viktor.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 2 Aug 2021 16:39:15 -0700

> compatible implementations that have have worked the same way for decades.

Sorry that I missed your previous commentary here, on the technical 
aspects of the draft that create a problem.

(Something must be misbehaving with either my mail system or the IETF's, 
since this is at least the second time I've seen a note from you 
offering a conclusion where I missed the foundation.)

Please point to the messages that have outlined what the details are 
that make it impossible for this draft to be viable.

> Since there is no chance that the implementations will change,

Your certitude is impressive.  Please document its basis.

> see if they interoperate, and then write it up as a draft standard?

Given your extensive IETF experience, it's surprising that you'd offer 
an historical summary this skewed, covering some of what has been done, 
while missing so much else of what has been done.  In other words, it 
used to be done, sometimes.  And it still is.  Sometimes.  And it wasn't 
done, sometimes.  And it still isn't.  Sometimes.

---

From: "John R Levine" <[email-masked]>
Date: 2 Aug 2021 20:12:07 -0400

Sorry, I'm not playing that game any more.

This message says what I mean.

On Mon, 2 Aug 2021, Dave Crocker wrote:

> Sorry that I missed your previous commentary here, on the technical aspects 
> of the draft that create a problem.
>
> since this is at least the second time I've seen a note from you offering a 
> conclusion where I missed the foundation.)
>
> Please point to the messages that have outlined what the details are that 
> make it impossible for this draft to be viable.
>
>
>
> Given your extensive IETF experience, it's surprising that you'd offer an 
> historical summary this skewed, covering some of what has been done, while 
> missing so much else of what has been done.  In other words, it used to be 
> done, sometimes.  And it still is.  Sometimes.  And it wasn't done, 
> sometimes.  And it still isn't.  Sometimes.
>
>
>

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Mon, 2 Aug 2021 17:50:59 -0700

> Sorry, I'm not playing that game any more.

Certainly your choice.  It's quite a burden, engaging seriously in 
discussion of substance, rather than simply tossing off grand 
pronouncements.

But thanks for acknowledging that you were playing a game.

d/

---

From: "John R Levine" <[email-masked]>
Date: 2 Aug 2021 21:03:57 -0400

> Certainly your choice.  It's quite a burden, engaging seriously in discussion 
> of substance, rather than simply tossing off grand pronouncements.

I think people are likely to be tired of bickering.

Let's see of other people think that a feature that has been in production 
use in hundreds of thousands of MTAs for 20 years is an experiment, or 
whether people who are familiar with it should document it so other people 
who might want to use it can interoperate.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Mon, 2 Aug 2021 18:13:32 -0700

On 8/2/2021 6:03 PM, John R Levine wrote:
> Let's see of other people think that a feature that has been in 
> production use in hundreds of thousands of MTAs for 20 years is an 
> experiment, or whether people who are familiar with it should document 
> it so other people who might want to use it can interoperate.

John,

You are inventing a controversy that requires pretending the document 
did not have significant, previous discussion, over the course of 
February, and extensive supporting commentary.

You appear to also be ignoring the fact that the document is targeting 
Experimental status through the Independent stream, not standards track 
or even IETF approval.

I'm sure the drama you've created has nothing to do with the pushback 
you received yesterday.  Still, the coincidence is unfortunate.

d/

---

From: "John Levine" <[email-masked]>
Date: 2 Aug 2021 21:34:20 -0400

>attacker to predict the magic "Delivered-To:" value).

Huh, interesting point.  Do you know of an LDAs that actually do that?  If so we should
add it to the description of the existing practice if we do a draft.

When I look at Postfix and qmail, they both appear to use the plaintext
locally rewritten recipient address, which may not make much sense to
software other than the MTA.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 2 Aug 2021 22:25:09 -0400

> On 2 Aug 2021, at 9:34 pm, John Levine <[email-masked]> wrote:
> 

Some abuse of Delivered-To to trigger bounces has been reported now and
then, and the idea of obfuscated Delivered-To: had been discussed, but
has not yet been implemented.  The freedom to do that some day remains.

https://mailing.postfix.users.narkive.com/RMb6WBxb/delivered-to-message-header

-- 
	Viktor.

---

From: Sam Varshavchik <[email-masked]>
Date: Tue, 03 Aug 2021 08:25:11 -0400

> https://mailing.postfix.users.narkive.com/RMb6WBxb/delivered-to-message- 

I don't see anything intrinsically wrong with this, by itself. It's better  
than nothing. But if the actual goal is to prevent proxy DDOSes, this should  
be addressed directly: no bounce should be sent via SMTP for mail that was  
accepted via SMTP.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 3 Aug 2021 05:42:23 -0700

On 8/2/2021 7:25 PM, Viktor Dukhovni wrote:
> then,

The thread you cited only describes the abuse as:

>>  If mail arrives for a recipient
>> that is already listed in a Delivered-To: header, the mes-
>> sage is bounced.

Viktor,

I'm not understanding.

Since Delivered-To is meant as an indication about the message
containing the Delivered-To, I'm not understanding what the 'already
listed' reference means.

It seems odd that a spammer would send a message designed to be 
rejected, other perhaps for generating problematic bounces.

To the extent the description is meant to refer to a broader set of 
mechanisms and activities, can you elaborate?

d/

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 3 Aug 2021 09:43:55 -0400

On Tue, Aug 03, 2021 at 05:42:23AM -0700, Dave Crocker wrote:

> >> If mail arrives for a recipient that is already listed in a
> >> Delivered-To: header, the mes- sage is bounced.
> 
> I'm not understanding.
> 

"Already listed" here means deliberately injected by spammer, even
though the message is fresh and had never previously been delivered to
the mailbox.

> rejected, other perhaps for generating problematic bounces.

Designed to be *bounced* (not rejected), at least in the case of Postfix
loop detection happens after the message is accepted, because mailbox
delivery is always asynchronous (from the queue).

So a miscreant abusing "Delivered-To" can cause the receiving system
to emit lots of bounces to a forged envelope sender address.

The "Delivered-To" address is an internal representation of the target
mailbox (for loop detection), and is not intended for consumption by
MUAs or tools like fetchmail.

-- 
    Viktor.

---

From: "John Levine" <[email-masked]>
Date: 3 Aug 2021 12:24:52 -0400

>MUAs or tools like fetchmail.

This is a key point.  The experiment draft doesn't match current practice,
and would at best lead to needlessly incompatible MTAs.

qmail's internal representation is different from Postfix's, but it also
is often not the same as any envelope address.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 3 Aug 2021 12:38:26 -0400

> be addressed directly: no bounce should be sent via SMTP for mail that was  

Getting rid of all after-queue bounces is too drastic a step.  It could
some day prove necessary, but I don't think it is warranted at this
time.  A more conservative change (already possible, but not enabled by
default in Postfix) is to always include only the headers in bounces
(text/rfc822-headers):

    https://datatracker.ietf.org/doc/html/rfc3462#section-2

That should have been the required format for bounces of EAI mail,
obviating the need for the message/global (transfer-encoding of
composite MIME parts) abomination.

-- 
    Viktor

---

From: Dave Crocker <[email-masked]>
Date: Tue, 3 Aug 2021 10:29:31 -0700

> MUAs or tools like fetchmail.

An abuser sends a single message that contains a Delivered-To and might 
then trigger a bounce back to the return address.  This is a one-for-one 
effect.  To be interesting, the attacker needs to send many of these 
addresses, to produce many of these bounces.  Yes?

d/

---

From: Dave Crocker <[email-masked]>
Date: Tue, 3 Aug 2021 10:34:25 -0700

> hypothetical, which it is not.

...

 > On further thought, this experiment makes no sense.

...

On 8/3/2021 9:24 AM, John Levine wrote:
> It appears that Viktor Dukhovni<[email-masked]>  said:
>> The "Delivered-To" address is an internal representation of the
>> target mailbox (for loop detection), and is not intended for
>> consumption by MUAs or tools like fetchmail.
> This is a key point.  The experiment draft doesn't match current
> practice, and would at best lead to needlessly incompatible MTAs.

Folks,

These summary assessments have, so far, not included the technical 
detail that can permit analysis and discussion by the rest of us.

John has declined to offer the detail that justifies his conclusions.

I'm hoping others can and will provide technical information that 
permits evaluating the draft further.

Viktor's reference to 'internal representation' sounds intriguing, but 
a) I don't know what it means specifically, and b) it doesn't indicate 
what might need changing in the current draft.

Comments?

d/

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 3 Aug 2021 14:36:19 -0400

> addresses, to produce many of these bounces.  Yes?

Even without any amplification, the risk is that the bounces can
leverage and harm the reputation of the server that returns the bounces.

The spammer gets to abuse an IP address from which he is not directly
able to originate email.

In any case, the intended consumer of Delivered-To is the MTA, not an
MUA.

-- 
    Viktor.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 3 Aug 2021 12:13:55 -0700

> leverage and harm the reputation of the server that returns the bounces.

Email abuse is a complex space, with a rich array of attacks and defenses.

That makes it dangerous to take a single theoretical example, like this, 
and project significant effects, and especially dangerous to then pursue 
common, pervasive protection mechanisms against it.

> The spammer gets to abuse an IP address from which he is not directly

Not exactly a new issue.

> In any case, the intended consumer of Delivered-To is the MTA, not an

Yes.  But I don't see how that affects this issue, here.

d/

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 3 Aug 2021 15:30:04 -0400

On Tue, Aug 03, 2021 at 12:13:55PM -0700, Dave Crocker wrote:

> > In any case, the intended consumer of Delivered-To is the MTA, not an MUA.
> 

It makes the localpart content of the "Delivered-To" header a private
matter for the MTA that adds the header.  It need not identify the
mailbox to anything other than the MTA.

For purposes of loop detection the order in which "Delivered-To" headers
are added is not material, so requiring it to be prepended, as though a
trace header, may not comport with some existing implementations.  FWIW,
in Postfix it is in fact prepended.

-- 
    Viktor.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 3 Aug 2021 12:41:45 -0700

Viktor,

1. How does that affect the technical specification?

2. When there is a sequence of Delivered-To header fields, for a mail 
that transits one or more intermediaries before 'final' delivery, how 
does this affect utility of the field?

d/

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 3 Aug 2021 15:57:52 -0400

> 1. How does that affect the technical specification?

    * The *requirement* to prepend (a la trace header) is not essential
      to the established use-case, so could be omitted.

    * The content of the localpart need not leak the raw address to
      which the message was delivered.  Various kinds of localpart
      obfuscation are allowed, and can be desirable.

> does this affect utility of the field?

The set of headers form a set, not an ordered list, a match indicates a
loop regardless of position in the list.

-- 
    Viktor.

---

From: Sam Varshavchik <[email-masked]>
Date: Tue, 03 Aug 2021 17:20:42 -0400

> composite MIME parts) abomination.

This still leaves plenty of room for bandwidth amplification:

EHLO
MAIL FROM:<[email-masked]>
RCPT TO:<[email-masked]>
DATA
Delivered-To: [email-masked]
.

This gets returned with comparable SMTP commands, with minimal net change,  
there. But then extra bandwidth in terms of the message envelope from the  
bouncing mail server, a brief introduction containing the complaint that the  
Delivered-To: header already exists, a copy of this sole header, and MIME  
scaffolding.

That's going to be several degrees of magnitude larger than this sole  
header, for certain.

---

From: Michael Peddemors <[email-masked]>
Date: Tue, 3 Aug 2021 14:55:15 -0700

On 2021-08-03 9:38 a.m., Viktor Dukhovni wrote:
> k

Besides, there is an industry practice that already deals with that, 
it's called 'backscatter', and usually gets you on an RBL ;)

But still see it from some 'too big to block' implementations..

eg. qq.com

-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

---

From: Michael Peddemors <[email-masked]>
Date: Tue, 3 Aug 2021 15:03:07 -0700

> in Postfix it is in fact prepended.

IMHO, and in practice.. Delivered-To is a trace header, however how the 
MTA chooses to record that trace header, should be up to the MTA, and 
designed for internal use..

Not that I know of an implementation that does this, it could be in 
theory..

It is the MTA that is recording this for it's own trace/logging, or 
whatever other purpose it needs that information available for..

IF the MTA 'chooses' to use that header for loop detection, that is only 
because it's own design trusts that header.. eg, internal looping.. but 
that is a separate utilization of the Delivered-To header.. not it's 
primary purpose IMHO, which is that of a trace header.

---

From: "John Levine" <[email-masked]>
Date: 3 Aug 2021 19:46:16 -0400

>primary purpose IMHO, which is that of a trace header.

As far as I know, every MTA that adds a Delivered-To: header records an internal
version of the address and uses it for loop detection.

If you know of MTAs that add the header but don't use it for loop detection, I'd be interested
to hear about it.

I know of MTAs such as Exim that add a different header with an envelope address, but not Delivered-To.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Tue, 3 Aug 2021 16:58:45 -0700

Here's the one that gmail put on, for a message it delivered to me:

> Delivered-To: [email-masked]

That looks surprisingly like the public version of my gmail email address.

While saying 'internal version of the address' sounds quite special, 
there is, as of yet, no example that has been provided, to show what 
makes it different from a regular email address, nor any technical 
detail provided that makes clear what needs to be supported, but is not, 
in the current draft.

Elaborations and, well, technical details, continue to be eagerly sought.

d/

---

From: "John Levine" <[email-masked]>
Date: 3 Aug 2021 22:19:57 -0400

>Elaborations and, well, technical details, continue to be eagerly sought.

Postfix and qmail are open source.  We've read the code.  You can, too.

If you're not willing or unable to read the code, that's OK, but in
that case I would appreciate it if you refrained from claiming that we
are lying.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Tue, 3 Aug 2021 19:41:09 -0700

> Postfix and qmail are open source.  We've read the code.  You can, too.

John, you've made an assertion of fact.  The obligation for doing the 
work to substantiate the assertion rests with the person making it.

Telling others to go do the research is a gaming ploy and I thought you 
said you weren't going to play the game any more.

With your extensive IETF experience, I'd think you know what constitutes 
constructive participation, but you are doing a heck of a job of 
pretending you don't.

> that case I would appreciate it if you refrained from claiming that we

Since I said and implied (and meant) nothing of the sort, and since you 
know I didn't, it means that you are, now.

Or else it means that you've taken statements that are nothing of the 
sort and actually believe they mean something they don't, in which case 
you've descended into hardcore paranoia.

d/

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 4 Aug 2021 01:10:14 -0400

> On 3 Aug 2021, at 7:58 pm, Dave Crocker <[email-masked]> wrote:
> 
> While saying 'internal version of the address' sounds quite special, there is, as of yet, no example that has been provided, to show what makes it different from a regular email address, nor any technical detail provided that makes clear what needs to be supported, but is not, in the current draft.

In Postfix, the address that is presently recorded is the result of any
internal rewriting such as mapping "[email-masked]" to some internal
"[email-masked]", that may not correspond to any public address
of the recipient.

But as I've said before, we reserve the right to make the localpart a base64
HMAC to curb abuse.  There is no expectation that that address is to be
understood by anything other than the responsible MTA (cluster?) in question.

-- 
	Viktor.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 4 Aug 2021 05:38:19 -0700

On 8/3/2021 10:10 PM, Viktor Dukhovni wrote:
> internal rewriting such as mapping"[email-masked]"  to some internal

 From the draft:

> The Delivered-To header field is added at the time of delivery, when
>    responsibility for a message transitions from the Message Handling
>    (Transport) Service (MHS) to an agent of the specified individual
>    recipient mailbox.  The header field contains the individual mailbox
>    used to determine the immediate location for that transition.

and:

> 
>    "Delivered-To:" FWS Mailbox CRLF
>                     ; Mailbox is from [SMTP]

I don't see anything in either that prohibits what you've described.

d/

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 4 Aug 2021 10:11:38 -0400

> On 4 Aug 2021, at 8:38 am, Dave Crocker <[email-masked]> wrote:
> 

The main thing that's implicit is that MUAs can't generally expect
to find a usable recipient address in the recorded "Delivered-To"
mailbox.  This may be true for some operators for some period of
time, but is not a requirement of the field semantics.

-- 
	Viktor.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 4 Aug 2021 07:39:13 -0700

> time, but is not a requirement of the field semantics.

I believe that concern is outside the scope of this draft.  And I don't 
think there is any text in the draft that is relevant to it; nor does it 
seem necessary to add any.

No?

d/

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 4 Aug 2021 12:05:33 -0400

> seem necessary to add any.

The abstract seems to me to suggest semantics other than an MTA-private
loop sentinel:

   The address to which email is delivered might be different than any
   of the addresses shown in any of the content header fields that were
   created by the email author.  The address used by the email transport
   service is provided separately, through an envelope SMTP "RCPT TO"
   command.  Before final delivery, handling can entail a sequence of
   submission/delivery events, using different destination addresses,
   that lead to the recipient.  It can be helpful for a message to have
   a common way to record each delivery in such a sequence, and to
                   -----------------------------------------------
   include each address used for that recipient.  This document defines
   ---------------------------------------------
   a header field for this information.

The sentinels used by MTAs in "Delivered-To" are used for loop
detection.  Use of the actual delivery address is merely the
simplest way to encode the requisite data.

It therefore seems that the goal of the draft is to *require* the field
to carry the actual delivery address, so that tools such as fetchmail
could then rely on its syntax and semantics.  If so, an MTA that wants
to preserve delivery address privacy, and still do loop detection, might
then need to switch to a suitable alternative header.

I might note that the delivery address for a recipient is an internal
matter between the MTA/LDA, that might change over time even for the
same underlying recipient.  So MUAs should not expect long-term
stability for such addresses.

Finally, the "Experimental" status is rather odd, given that the header
has been in use for over two decades...

-- 
    Viktor.

---

From: "John Levine" <[email-masked]>
Date: 4 Aug 2021 13:00:30 -0400

It appears that Dave Crocker  <[email-masked]> said:
>> of the recipient. ...

>>    "Delivered-To:" FWS Mailbox CRLF

The thing after the FWS is an opaque token. Sometimes it may look like
a mailbox, sometimes not. And even if it looks like a mailbox, it
often is *not* a mailbox. You can't use it for delayed running of
procmail or redelivery via fetchmail or anything else that expects a
mailbox.

As a concrete example, if you send mail to [email-masked], here's the Delivered-To

 Delivered-To: [email-masked]

That pseudo-address reflects the detailf of my mail set up, but if you or I
tried to send mail to it, it wouldn't work. 

It would make sense for us to do a survey of MTAs and describe how they actually use
Delivered-To and write it up, which is a report rather than an experiment.  Take a look
at RFC 7085 in which Paul Hoffman and I did a survey of TLD apex DNS records for what I mean.

R's,
John

---

From: Sam Varshavchik <[email-masked]>
Date: Wed, 04 Aug 2021 19:29:17 -0400

> I don't see anything in either that prohibits what you've described.

The sticking point is "Mailbox is from [SMTP]" is getting interpreted to  
mean "literally what's in the RCPT TO'.

This is not always the case. Example: mail received by a mailing list  
server, and then delivered to a local mailbox (that's subscribed to the  
mailing list), will have two Delivered-To: headers. The first one will be  
the mailing list's public SMTP address (or may be not, but it will be  
[email-masked] where "something" is how example.com's mail server  
knows the mailing list's mailbox by), the second one will be the recipient's  
address, which may or may not be a public SMTP address (for the same  
reasons).

Another live example, using my isolated network, but with a couple of  
servers that occasionally swap SMTP mail:

$ telnet localhost 25
Trying ::1...
Connected to localhost.
Escape character is '^]'.
220 monster.email-scan.com ESMTP
EHLO monster.email-scan.com
250-monster.email-scan.com Ok.
250-AUTH CRAM-SHA256 CRAM-SHA1 CRAM-MD5
250-STARTTLS
250-XVERP=Courier
250-XEXDATA
250-XSECURITY=NONE,STARTTLS
250-PIPELINING
250-8BITMIME
250-SMTPUTF8
250-SIZE
250 DSN
MAIL FROM:<[email-masked]>
250 Ok.
RCPT TO:<[email-masked]>
250 Ok.
DATA
354 Ok.
Subject: test
From: [email-masked]
To: [email-masked]
Subject: local mail

test
.
250 Ok. 00000000610B21CB.00014A01
QUIT
221 Bye.
Connection closed by foreign host.

Would anyone care how the headers would look like?

Subject: test
From: [email-masked]
To: [email-masked]
Subject: local mail

test

The Delivered-To: header has nothing to do with the SMTP recipient. This  
node owns @monster.email-scan.com, and it's up to this node to decide what  
goes in there.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 5 Aug 2021 09:42:50 -0700

On 8/4/2021 4:29 PM, Sam Varshavchik wrote:
> Delivered-To: [email-masked]
> Return-Path: <[email-masked]>
> Received: from monster.email-scan.com (localhost [::1])
>   by monster.email-scan.com with ESMTP
>   id 0000000000068359.00000000610B21CB.00014A01; Wed, 04 Aug 2021 
> 19:24:44 -0400
> Subject: test
> node owns @monster.email-scan.com, and it's up to this node to decide 
> what goes in there.

The revised draft's language tries to cover this.  Please review.

d/

---

From: Dave Crocker <[email-masked]>
Date: Thu, 5 Aug 2021 09:47:17 -0700

> has been in use for over two decades...

There are a number of possible reasons for seeking Experimental status 
to an RFC:

      1. The technology is defines is not yet understood well enough and 
there are concerns that its functionality, reliability, or the like 
might not behave as intended

      2. The proposed use of the technology might go beyond established 
practice and the expanded use might need vetting

      3. The technology might not scale adequately for Internet use

      4. The market might not be sufficiently interested in the 
technology to choose to use it

      5. The documentation of the technology might need wider review and 
comment

The current draft probably qualifies under more than one of these.

d/

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 5 Aug 2021 13:05:26 -0400

On Thu, Aug 05, 2021 at 09:47:17AM -0700, Dave Crocker wrote:

> [...]

I think "Informational" is a much better fit.  This would document the
long established practice of using "Delivered-To:" for loop detection.

-- 
    Viktor.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 5 Aug 2021 10:10:01 -0700

> long established practice of using "Delivered-To:" for loop detection.

It isn't.  As I suggested, the document qualifies under more than one of 
the reasons.

I left off a derivative point, which is that 'Experimental' is a signal 
to the wider technical and operations community that comments are 
sought.  As they are, in this case.

There seems to be an inordinate focus on the loop detection benefit, 
while ignoring the handling trace audit use that was, frankly, the 
original reason for developing the document.

d/

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 5 Aug 2021 13:46:17 -0400

> On 5 Aug 2021, at 1:10 pm, Dave Crocker <[email-masked]> wrote:
> 
> There seems to be an inordinate focus on the loop detection benefit, while ignoring the handling trace audit use that was, frankly, the original reason for developing the document.

Well, perhaps then a *new* experimental header should be defined for this
new purpose.  Though who exactly is the audience for this trace information?

The only use-case I see is one where I sometimes accidentally benefit from
a privacy leak when a message forwarded via a WHOIS privacy alias bounces
downstream of the privacy service revealing the actual domain owner's
address.

Though such privacy leaks are occasionally useful to me, I'm not sure they
merit standardisation.

Beyond loop detection, what is the intended audience of the draft's trace
headers?

-- 
	Viktor.

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 5 Aug 2021 13:46:50 -0400

I'm with Dave on the idea of being Experimental.

I know that Delivered-To has been around for a long time, but I always
thought having the email address and the time stamp on Delivered-To would
reading headers a bit easier for this person.

tim

On Thu, Aug 5, 2021 at 1:10 PM Dave Crocker <[email-masked]> wrote:

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

---

From: Dave Crocker <[email-masked]>
Date: Thu, 5 Aug 2021 11:02:30 -0700

On 8/5/2021 10:46 AM, Viktor Dukhovni wrote:
> Well, perhaps then a*new*  experimental header should be defined for this

That would serve to exclude existing practice.  In effect, it raises the 
barrier to adoption, since it moves from 'incremental benefit' to 
'starting over'.

So far, there has been no objective evidence produced that would prevent 
the use of the existing header field for both loop detection and 
delivery sequence auditing.

 From the Abstract:
>> It can be helpful for a message to
>>    have a common way to record each delivery in such a sequence, and to
>>    include each address used for that recipient.

This was, after all, the reason for starting the documentation effort.

d.

---

From: Sam Varshavchik <[email-masked]>
Date: Thu, 05 Aug 2021 20:53:40 -0400

Dave Crocker writes:

>>   id 0000000000068359.00000000610B21CB.00014A01; Wed, 04 Aug 2021 19:24:44  
>> -0400
>> Subject: test

I looked at the document diff. Wording in several places was revised along  
these lines:

Old: "The header field contains the individual mailbox.."

New: "The header field contains information about the individual mailbox.."

This kind of change was consistent in several place, but in one instance –  
which I noticed before – the old phrasing remained:

   "Delivered-To:"  FWS *phrase Mailbox *phrase CRLF
                    ; Mailbox is from [SMTP]

   Note:  The field records only a single mailbox, for one recipient.

It would be more consistent for this to also be updated to:

   Note:  The field records information about only a single mailbox, for
   one recipient.

---

From: Sam Varshavchik <[email-masked]>
Date: Thu, 05 Aug 2021 20:56:21 -0400

> reading headers a bit easier for this person.  

I don't recall ever seeing a timestamp in Delivered-To:, it was always just  
an address.

Received: headers have all the timestamps I ever need.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 5 Aug 2021 17:57:24 -0700

>    Note:  The field records information about only a single mailbox, for

good catch.  thanks!  done.

d/

---

From: Dave Crocker <[email-masked]>
Date: Thu, 5 Aug 2021 17:59:51 -0700

On 8/5/2021 5:56 PM, Sam Varshavchik wrote:
> I don't recall ever seeing a timestamp in Delivered-To:, it was always 
> just an address.
> 

You got there just ahead of me.  I had the same reaction.

Not that timestamp info doesn't seen like an interesting feature, but it 
hasn't been discussion and, so far, isn't in any of the existing 
examples we've seen.

Timestamps seem like such a strong benefit to make it worth considering 
how to add this capability to the spec.  Yes?

Or is the Received field sufficient?  Easy to believe it is.

d/

---

From: tjw ietf <[email-masked]>
Date: Thu, 5 Aug 2021 21:02:46 -0400

Yes the received field is sufficient. These were thoughts from decades ago when people paid me to crawl headers.  That isn’t the case these days.  

Tim

Sent from my iPhone

> On Aug 5, 2021, at 21:00, Dave Crocker <[email-masked]> wrote:
> 
>> I don't recall ever seeing a timestamp in Delivered-To:, it was always just an address.
> Not that timestamp info doesn't seen like an interesting feature, but it hasn't been discussion and, so far, isn't in any of the existing examples we've seen.
> 
> Timestamps seem like such a strong benefit to make it worth considering how to add this capability to the spec.  Yes?
>

---

From: Dave Crocker <[email-masked]>
Date: Thu, 5 Aug 2021 18:04:16 -0700

> Yes the received field is sufficient. These were thoughts from decades ago when people paid me to crawl headers.  That isn’t the case these days.

well, drat.

that's one less thing to make this more complicated...

d/

---

From: "John Levine" <[email-masked]>
Date: 5 Aug 2021 22:45:58 -0400

>that's one less thing to make this more complicated...

If we have a mail corpus it'd be interesting to see how many Received headers have "for" clauses
and if they match up at all with Delivered-To.

Probably not, the "for" clause was never very popular.

R's,
John

---

From: Jeremy Harris <[email-masked]>
Date: Fri, 6 Aug 2021 09:14:18 +0100

On 06/08/2021 03:45, John Levine wrote:
> the "for" clause was never very popular.

The default Exim configuration For Received: includes
a "for" clause for single-recipient messages.
-- 
Cheers,
   Jeremy

---

From: "Valdis Klētnieks" <[email-masked]>
Date: Fri, 06 Aug 2021 04:29:27 -0400

> Probably not, the "for" clause was never very popular.

Don't bet on that. :)

For the very old corpus, there were a total of 214,585 Received: lines, of which
65,273 had a ' for ' clause.

By comparison, out of some 31,000 emails I received during June of this year,
there are 270,893 Received: lines, of which 23,253 have a ' for ' clause.  A
quick eyeball indicates that Postfix, Exim, and Google all do it for
single-recipient deliveries (several representative examples):

Received: from mail.nanog.org (mail.nanog.org. [50.31.151.76]) by  mx.google.com with ESMTP id i17si14861524ioi.33.2021.05.31.22.31.45 for  <[email-masked]>; Mon, 31 May 2021 22:31:46 -0700 (PDT)

Received: from mail-io1-xd2a.google.com ([2607:f8b0:4864:20::d2a]) by  shelob.surriel.com with esmtps (TLS1.2) tls  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from  <[email-masked]>) id 1lnx2R-0000zE-LN for  [email-masked]; Tue, 01 Jun 2021 01:34:03 -0400

Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com  [IPv6:2a00:1450:4864:20::234]) by lindbergh.monkeyblade.net (Postfix) with  ESMTPS id 7AA67C061574 for <[email-masked]>; Mon, 31 May 2021  22:47:47 -0700 (PDT)

On the other hand, there were only 2,962 Delivered-To: headers, with only 22
different values that weren't final-delivery on my laptop.

---

From: Claus Assmann <[email-masked]>
Date: Fri, 6 Aug 2021 10:29:55 +0200

> a "for" clause for single-recipient messages.

Just like sendmail... for more than 20 years at least.

-- 
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: Fri, 6 Aug 2021 13:57:01 +0200

> time, but is not a requirement of the field semantics.

A MUA can use Delivered-To: to compare the address therein with the 
configured user addresses so that replies can have a From: field that 
matches the original recipient.  Some agents are even able to unwind 
various Received:/Delivered-To: pairs.  Obviously, internal codes or 
HMAC break such usage.  Fields reordering breaks it too.

Would it make sense to define, alternatively:

     "Delivered-To:" FWS Mailbox [CFWS] CRLF
                     ; Mailbox is from [SMTP]

where a comment may contain an opaque crypto token whereby an MTA can 
recognize itself and break mail loops only in that case?

Best
Ale
-- 

p.s. s/am email delivery/an email delivery/ in deliveredto-04

---

From: Sam Varshavchik <[email-masked]>
Date: Fri, 06 Aug 2021 08:38:25 -0400

Alessandro Vesely writes:

> matches the original recipient.  Some agents are even able to unwind various  
> Received:/Delivered-To: pairs.  Obviously, internal codes or HMAC break such  
> usage.  Fields reordering breaks it too.
>

An MTA that wants to use its own tailored mail loop logic is always free to  
insert some X header that it understands.

I think what we want to do here is just document how this header's been used  
for 20+ years, to avoid someone coming along and doing something different  
with it. Even in that case the chances of that creating a problem for  
others, I think, are very small.

Speaking very loosely and imprecisely:

Delivered-to: [email-masked]

An MTA that controls domain.com is entitled to add this header, and it's up  
to the MTA to decide what "something" is. It may correspond to the actual  
recipient, or it may not. This is the MTA's record of delivery, and it only  
means something to that MTA.

It MAY be inferred to indicate the recipient's actual e-mail address, but it  
only MAY do that.

The entire mail loop subject matter is just a derivative of this. Since the  
MTA own this header, it is certainly reasonable for the MTA to assume that  
noone else could put it there, so if it sees that the message already has  
it, it can reasonably conclude that the mail looped.

---

From: "John Levine" <[email-masked]>
Date: 6 Aug 2021 10:11:28 -0400

>     "Delivered-To:" FWS Mailbox [CFWS] CRLF

If you want a header that records the envelope address, Exim calls that Envelope-To:

I don't see any benefit to conflating that with a loop breaking token.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Fri, 6 Aug 2021 07:30:54 -0700

> I don't see any benefit to conflating that with a loop breaking token.

Indeed.

Why use one field that is sufficient when we can pretend two are needed?

d/

---

From: Dave Crocker <[email-masked]>
Date: Fri, 6 Aug 2021 09:32:34 -0700

On 8/4/2021 10:00 AM, John Levine wrote:
> often is*not*  a mailbox. You can't use it for delayed running of
> As a concrete example, if you send mail [email-masked], here's the Delivered-To
> 
>   Delivered-To:[email-masked]

Folks,

John just sent me a private note, seeking to use the above message, from 
the thread here, as 'proof' that current draft for Deliver-To does not 
suit, with his view that the delivery 'token' is different from the 
other use for handling tracing.

Unfortunately this mostly demonstrates that he hasn't bothered to read 
the current draft, since it was modified to cover this case (and some 
others that we have actually data for.)

One of these days, John might actually engage with the substance of this 
topic and deal with the available data, rather than simply gaslighting 
with his own assertions that, so far, lack supporting data.

d/

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 6 Aug 2021 14:28:20 -0400

> On 6 Aug 2021, at 10:30 am, Dave Crocker <[email-masked]> wrote:
> 

Well, Envelope-To: records the envelope address as received from upstream,
e.g. in the "RCPT TO" command.  While "Delivered-To:" is some internal
representation of the receiving mailbox for loop detection.

The former can be expected to match a usable email address as specified
in the incoming envelope.

So the two are in fact semantically distinct, even when they happen to
coincide in the absence of rewrites, hashing, ...

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 6 Aug 2021 14:32:34 -0400

> On 6 Aug 2021, at 4:29 am, Claus Assmann <[email-masked]> wrote:
> 

And likewise Postfix, since ~1997.  So "for" is typically
supported on the mainstream open-source MTAs.  Even Google
adds a "for" clause in at least some messages:

    Received: from mail-sor-f73.google.com (mail-sor-f73.google.com. [209.85.220.73])
        by mx.google.com with SMTPS id h15sor2642110ila.35.2021.06.25.08.35.32
        for <[email-masked]>
        (Google Transport Security);
        Fri, 25 Jun 2021 08:35:32 -0700 (PDT)

-- 
	Viktor.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 6 Aug 2021 11:37:59 -0700

> coincide in the absence of rewrites, hashing, ...

Please explain how the current deliveredto draft does not satisfy these 
uses with a single field.

d/

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 6 Aug 2021 14:45:40 -0400

> On 6 Aug 2021, at 2:37 pm, Dave Crocker <[email-masked]> wrote:
> 
> Please explain how the current delivered-to draft does not satisfy these uses with a single field.

If an MUA wants to learn the envelope recipient address to which the
message was sent (by the immediate upstream MUA or relay) then Delivered-To
is not the right header for that.  That's why Exim has Envelope-To, while
Postfix has "X-Original-To:", both of which are intended for consumption by
tools like fetchmail.

My response was to the question of why there are two headers when ostensibly
one would do.  I explained why in fact one is not sufficient, because they
serve different purposes and carry semantically different and often
distinct payloads.

The draft as written does not preclude the present use of Delivered-To, but
its "Experimental" status still makes no sense to me, and to the extent that
it indirectly implies any new semantics for this header (beyond internal
consumption by the generation MTA should the message come back around), then
such semantics cannot be relied on.

If no new semantic meaning is implied, what is the purpose of the "experiment"?

-- 
	Viktor.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 6 Aug 2021 11:56:50 -0700

> Postfix has "X-Original-To:", both of which are intended for consumption by

So you are saying that it is not possible for one Delivered-To to show 
the actual address it has been delivered to, followed by another 
Delivered-To that shows a local transformation to an internal delivery 
string?

Or are you saying that Delivered-To has nothing to do with delivery?

> its "Experimental" status still makes no sense to me,

1. That's irrelevant to the current issue.

2. It's been explained.  Please refer to my earlier note that provides 
quite a bit of detail for that explanation.

d/

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 6 Aug 2021 15:32:58 -0400

> Delivered-To that shows a local transformation to an internal delivery 

Well, since "Delivered-To:" is for MTA-private use (loop detection) and
(by default) records the internal envelope recipient passed to the LDA,
rather than the input envelope recipient from the sending agent, it was
deemed appropriate to conflate these into a single header.

> Or are you saying that Delivered-To has nothing to do with delivery?

I am saying that "Delivered-To" is used for detecting loops in case the
LDA reinjects the message back into the mail handling stream and as a
result it unfortunately arrives to again be delivered to the same
recipient.  The the simplest way to fingerprint the prior delivery was
to record the envelope recipient as conveyed to the LDA, but other
fingerprints are possible, and may be used in the future.

If the goal of the experiment is to repurpose "Delivered-To" as a
standard replacement for "Envelope-To", "X-Original-To", and have
that header now record the input (as received) envelope recipient,
rather than the current output (as passed to the LDA) envelope
recipient, that should be more explicit in the draft, and there
should be a compelling case for Qmail, Exim, Postfix, ... to
make that change.

-- 
    Viktor.

---

From: Gene Hightower <[email-masked]>
Date: Fri, 6 Aug 2021 12:36:21 -0700

> Well, Envelope-To: records the envelope address as received from upstream,

How does this relate to the mandatory Return-Path: trace header?

From RFC-5321:

   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.  This use of return-path is required; mail systems MUST support
   it.  The return-path line preserves the information in the <reverse-
   path> from the MAIL command.  Here, final delivery means the message
   has left the SMTP environment.  Normally, this would mean it had been
   delivered to the destination user or an associated mail drop, but in
   some cases it may be further processed and transmitted by another
   mail system.

(I'm confused)

---

From: Dave Crocker <[email-masked]>
Date: Fri, 6 Aug 2021 12:38:24 -0700

> Well, since "Delivered-To:" is for MTA-private use (loop detection) and

Sorry.  I missed hearing about the documented rule that restricts it use 
this way.

> deemed appropriate to conflate these into a single header.

It's not conflating.  It is, arguably, exactly the same use.

Note that gmail, for example, merely puts the .... delivery address... 
into the field.

The claim that this field gets some sort of mystical, obscure token has 
yet to be document.  So far, all that has been shown, beyond a simple 
email address, is some descriptive text.  Before a string in the form of 
an email address, which might well be the delivery address.

> I am saying that "Delivered-To" is used for detecting loops in case the

That's nice, but it doesn't answer my question.

d/

---

From: Dave Crocker <[email-masked]>
Date: Fri, 6 Aug 2021 12:39:57 -0700

> How does this relate to the mandatory Return-Path: trace header?

Just a wild guess:

One is for the address being... delivered... 'to'.

The other is the address to which handling report messages are sent.

d/

---

From: Claus Assmann <[email-masked]>
Date: Fri, 6 Aug 2021 21:42:46 +0200

> > Well, Envelope-To: records the envelope address as received from upstream,

RCPT

>    path> from the MAIL command.  Here, final delivery means the message
                    ^^^^

> (I'm confused)

Welcome to the list - it seems like a most confusing discussion
where people don't even know "What is the problem you are trying
to solve"?

---

From: Gene Hightower <[email-masked]>
Date: Fri, 6 Aug 2021 12:46:07 -0700

> One is for the address being... delivered... 'to'.

Oh yeah, to, from, got it.

---

From: Gene Hightower <[email-masked]>
Date: Fri, 6 Aug 2021 12:47:24 -0700

Yeah, that's what goes into the "for" part of the Received: header -- I
dig. That part is standardized, no?

---

From: Dave Crocker <[email-masked]>
Date: Fri, 6 Aug 2021 13:01:41 -0700

> where people don't even know "What is the problem you are trying

The draft seeks to be clear on this.  To the extent it is not 
sufficiently clear (or reasonable) to you, please comment, so we can 
look for ways to improve it.

I certainly agree that clarity of purpose is essential for a specification.

d/

---

From: Dave Crocker <[email-masked]>
Date: Fri, 6 Aug 2021 13:02:35 -0700

> Oh yeah, to, from, got it.

these are new concepts.  they didn't exist, before that guy in 1978 (or 
80, or maybe 82) invented them.  right?

d/

ps.  sorry, not sorry.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 6 Aug 2021 13:03:35 -0700

> dig. That part is standardized, no?

It is, but isn't quite specified or used in a way that provides 
sufficiently -- or sufficiently reliable -- information.

d/

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 6 Aug 2021 16:43:35 -0400

> Sorry.  I missed hearing about the documented rule that restricts it use 

Today, the "Delivered-To" header introduced by Qmail, and adopted in
Postfix and Exim records an internal non-public mailbox address used in
MTA-to-LDA communication, that only happens to coincide with the
incoming public envelope address with some frequency.  It is used for
loop detection by the MTA.

> > [not] deemed appropriate to conflate these into a single header.
> 

I

> Note that gmail, for example, merely puts the .... delivery address... 

Gmail does not appear to rewrite the input recipient address in transit
from MTA to LDA.  That's a choice they're free to make.

> yet to be document[ed].

I am communicating its use in Qmail, Postfix an Exim now, for the nth
[and last] time.  In these MTAs it is a loop detection token, and not an
address that is expected to be recognised by downstream user agents or
MTAs.  The only intended audience is the same MTA (or MTA cluster),
should the message come back around...

Perhaps this information is not welcome, or not sufficiently
authoritative.  I can't do anything about that.

What I can say is that I see no compelling case to participate in some
new experimental use of this header.  Postfix has:

    - X-Original-To: for the inbound external envelope recipient, for
      use by fetchmail, ...

    - Delivered-To: for recording the MTA-to-LDA handoff envelope, used
      to detect loops when LDAs reinject the message downstream.

I guess the maintainers of Qmail, Postfix and Exim are fools, who've
failed to realise that they should be using the same header for both
purposes.

[ With both address forms recorded, fetchmail would have to figure out
whether that's what happened, and which of the two topmost Delivered-To
addresses to use to demultiplex multi-drop mailboxes, after we announce
a suitable flagday when the relevant MTAs join the experiment. ]

I have nothing further to add...

-- 
    Viktor.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 6 Aug 2021 13:49:44 -0700

> loop detection by the MTA.

This description has been repeated quite a bit.

It would be good for loop detection to be applied, so that when people 
post statements intended for the current topic, they don't just repeat 
things that have already been covered.  Repeatedly.

> from MTA to LDA.  That's a choice they're free to make.

Indeed they are.  But it establishes use of the same field, in ways that 
might be taken to be slightly different than the use that is constantly 
being repeated.

And the current draft covers both of those uses.

> should the message come back around...

Since you are promising not to repeat yourself, does that mean you might 
finally respond to the current question about adequacy of the current 
draft.  Ideally that would include details about concerns with the text. 
  Extra points for suggesting specific improvements.

d/

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 6 Aug 2021 19:31:21 -0400

> Extra points for suggesting specific improvements.

The draft suggests an "experiment" which was conducted and concluded
two-plus decades ago.  The "Delivered-To" header has been in wide use
since it was introduced IIRC by Dan Bernstein in Qmail.

I don't understand what "experiment" can be conducted or justified at
this point.  If the draft is suggesting repurposing or extending the
existing uses of the header, what justifies such repurposing or extended
use?  If it is proposing no changes, how is it an experiment?

Who benefits from the experiment?  Does the benefit exceed the cost?

-- 
    VIktor.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 6 Aug 2021 16:37:32 -0700

> since it was introduced IIRC by Dan Bernstein in Qmail.

sigh.  the label is an RFC-related term.  This has been explained in an 
earlier posting.

The label does not affect the adequacy or problems with the substance of 
the document.

> Who benefits from the experiment?  Does the benefit exceed the cost?

So, you haven't actually read the document's discussion of these issues?

d/

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 6 Aug 2021 19:47:07 -0400

> So, you haven't actually read the document's discussion of these issues?

I did not find any answers to the above question in the document, only
variations on the question in section 7, but why did you bother writing
the draft?  To what new purpose do you expect to see this existing
header employed and why?  If all you have is questions, I think the
draft is best abandoned.

-- 
    Viktor.

---

From: Sam Varshavchik <[email-masked]>
Date: Fri, 06 Aug 2021 19:49:58 -0400

Viktor Dukhovni writes:

> The "Delivered-To" header has been in wide use

Yup. I aped it in Courier, somewhere in the mid to late 1990s. It also found  
its way to others, pretty much as advertised.

---

From: Francesco Gennai <[email-masked]>
Date: Sat, 7 Aug 2021 09:50:07 +0200

Following the discussion, I see that the delivery-to is currently used
(in many cases) to loop detection.
In such cases it could contain an email address, a token, etc..
I suspect that at the top of the problems discussed here there is a
conflict in the header name (deliverd-to:), between the current use
and the draft.
I would say that "delivered-to:" is not the best name for the current
use (loop detection), but... it is there.

Francesco

---

From: Sam Varshavchik <[email-masked]>
Date: Sat, 07 Aug 2021 06:35:23 -0400

> use (loop detection), but... it is there.

Loop detection is not the purpose of this header, but loop detection makes  
use of it, this is a nuanced distinction.

---

From: Ned Freed <[email-masked]>
Date: Sat, 07 Aug 2021 06:51:10 -0700 (PDT)

> use (loop detection), but... it is there.

And surprisingly difficult to change. Although this type of loop detection is
inherently a local MTA matter, large deployments routinely have lots of
separate MTAs operating in parallel providing a particular service.

Even if you assume that the all the MTAs use the same software - and there
situations where that's not the case - you can't upgrade large numbers of MTAs
simultaneously.

Of course you can argue that this is a minor feature and it won't matter if
it's broken for the duration of an upgrade. But IME the folks whose approval
you need tend not to be very sympathetic to such arguments - understandable
given the costs of failed upgrades and rollbacks.

What this means is that implementations will have to support both
names for a considerable period of time. That's considerably
more expensive than switching the value of a single constant.

				Ned

---

From: "John R Levine" <[email-masked]>
Date: 7 Aug 2021 11:05:08 -0400

> Why use one field that is sufficient when we can pretend two are needed?

This is the sort of thing we can describe in the survey of existing usage, 
for the benefit of people less familiar with the way mail systems work.

When mail systems do internal forwards using things like .forward or 
/etc/alias, each forward adds a Delivered-To, which breaks a->b->c->a 
loops.  Since there's no SMTP involved, there's usually no Received and 
never an Envelope-To.  Also, as Sam, Viktor, and I have explained, the 
internal forwards are not necessarily to or from anything that has an 
externally valid envelope address.

Regards,

---

From: Ned Freed <[email-masked]>
Date: Sat, 07 Aug 2021 08:44:49 -0700 (PDT)

> externally valid envelope address.

What happens when there are multiple recipients? Message splitting?

				Ned

---

From: "John R Levine" <[email-masked]>
Date: 7 Aug 2021 11:58:07 -0400

> What happens when there are multiple recipients? Message splitting?

For Delivered-To loop breaking it doesn't matter since it's just a token 
to show that the message has already been wherever it is.

I believe that Exim does one delivery at a time so its Envelope-To only 
has one address.  I can ask Jeremy what happens with multiple recipient 
messages.

Regards,

---

From: Ned Freed <[email-masked]>
Date: Sat, 07 Aug 2021 09:22:04 -0700 (PDT)

> to show that the message has already been wherever it is.

Not quite getting it.

A single token describes all of the recipients? Or do you simply generate more
than one Delivered-to: in the same message?

Let's make this concrete. We have these aliases:

alias1: local-recipient-1, local-recipient-2

alias2: remote-recipient-1, remote-recipient-2

How many message copies do these generate, and what fields are added?

And while we're at it, what does

alias3: alias3, extra-recipient-1

do?

> has one address.  I can ask Jeremy what happens with multiple recipient

Yes, please do.

				Ned

---

From: "John R Levine" <[email-masked]>
Date: 7 Aug 2021 12:40:41 -0400

> A single token describes all of the recipients? Or do you simply generate 
> more than one Delivered-to: in the same message?

Whenever a message goes through a delivery step the MTA adds a 
Delivered-To.  If the same Delivered-To is already there, it's a loop so 
it stops.

> How many message copies do these generate, and what fields are added?

Depends on the MTA, same as always.  I expect some will combine recipients 
that take the same path, some won't.

Regards,

---

From: Jeremy Harris <[email-masked]>
Date: Sat, 7 Aug 2021 18:12:48 +0100

On 07/08/2021 16:58, John R Levine wrote:
> For Delivered-To loop breaking it doesn't matter since it's just a token to show that the message has already been wherever it is.
> 
> I believe that Exim does one delivery at a time so its Envelope-To only has one address.  I can ask Jeremy what happens with multiple recipient messages.

Some Exim transports (the module that does delivery) can handle
multiple addresses, some only one.

The docs say:
"If this option is true, an Envelope-to: header is added to the message.
This gives the original address(es) in the incoming envelope that caused
this delivery to happen. More than one address may be present if the
transport is configured to handle several addresses at once, or if more
than one original address was redirected to the same final address."

The controlling option is false as default.  I don't know what distros
configure, though.

I think that means that a transport restricted (*) to one-address handling
would only add one address in an Envelope-To, but that isn't always
the case.
-- 
Cheers,
   Jeremy

*) "rcpt_max" for an smtp transport controls, defaults to >1.
    "batch_max" for appendfile, lmtp or pipe transport controls,
    defaults to 1.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 7 Aug 2021 13:29:26 -0400

> What happens when there are multiple recipients? Message splitting?

Yes, a single recipient delivery is required for Delivered-To: (and/or
X-Original-To) to be prepended to the message.

The Postfix local(8) delivery agent always delivers to one *input*
recipient (MTA-to-LDA handoff) at a time.   The envelope is not split
internally when expanding an alias with an "owner-" alias, or with an
RHS of ":include:/some/file", and in both cases a new message is
injected into the queue with the resulting expansion, which might then
variously split and perhaps produce new local recipients...

Furthermore, the Postfix MTA is by default (and this is rarely and
should not be changed) configured to hand off one recipient at a time to
local(8).

The lmtp(8), pipe(8) and smtp(8) delivery agents can be configured in
particular master.cf(5) transport definitions to expect single-recipient
envelopes (and qmgr(8) should then be configured for single-recipient
delivery-agent handoff to such a transport).

Bottom line, the Delivered-To: header is added by transports configured
to add it, when such transports are correctly configured for
single-recipient delivery.

-- 
    Viktor.

---

From: Michael Peddemors <[email-masked]>
Date: Sat, 7 Aug 2021 11:53:36 -0700

Wow this thread goes long...

Unlimited Delivered-To: can be added as trace headers, and SOME systems 
will consider if a Delivered-To: token that already exists, is in a 
loop, a 'convenience' of having that trace header in place.  (Other 
systems may use alternative methods of loop tracing, using their own 
methods, and possibly other headers)

Delivered-To: once again, is SIMPLY a trace header, when a MTA hands off 
the message to a system that 'should' know how to handle the message for 
final handling/distribution.

So, RFC's should simply note that it is a trace header, should be added 
to the top of trace headers,period.

.. with a 'side note' that many existing systems assume the token in a 
single Delivered-To: will be unique during the processing of a message, 
and MAY consider an existing Delivered-To: + token as representing a loop.

---

From: Richard Clayton <[email-masked]>
Date: Sat, 7 Aug 2021 19:51:09 +0100

In message <[email-masked]>, Dave
Crocker <[email-masked]> writes

> Ideally that would include details about concerns with the text. 

I have read -05

It suggests a header which will added, perhaps many times, to a message
which shows how it has traversed various delivery systems.

The document provides only one justification for this

        One use can be for detecting a delivery sequence loop.
        Delivering the same message more than once to the same address
        is almost certainly not an intended activity.

The first sentence makes sense to me.

The second sentence is poorly drafted, I often get two copies of a
message to the same address and welcome it because it shows two rather
distinct paths through some complex mail systems are both working. They
aren't strictly the same message (lots of header fields differ). So the
second sentence might usefully say something more generic such as
without loop detection messages may be in transit indefinitely or appear
at the final destination more than once.

Since loop detection is an explicit aim then mentioning other loop
detection mechanisms (such as counting Received header fields) might be
useful -- if only to indicate how these go wrong, or do not kick in fast
enough (or indeed once the message is no longer using SMTP may not be
generated at all).

I did a lot of work 20 years ago developing software to detect loops
(mail systems have all sorts of exotic ways of preventing standard
mechanisms from kicking in) ... and for an ISP user base of 200K or so
would find one or two a day. I have no newer data than that -- I expect
that far more people now use proper MTA software than back then, so the
incidence will be much lower.

However, for loop detection an opaque value would do just as well and
would avoid a lot of discussion about privacy. We know how to produce
"globally unique" values (because we do it for MIME separators) and this
may avoid issues when two systems think that mailboxes are fred@local.

Because of the privacy issues I think the document needs to explicitly
set out other uses of the header if human readable values are to be used

Finally, there seems little value (and much unnecessary annoyance) in
overloading an existing header that is in fairly widespread use...
perhaps using "Been-There" (so that the this mailing list can retire an
X-Header) would be sensible.

- -- 
richard                                                   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

---

From: "John Levine" <[email-masked]>
Date: 7 Aug 2021 15:35:31 -0400

>more expensive than switching the value of a single constant.

Quite right.

I also note, once again, that if you want to record an envelope recipient
address, there is quite a lot of existing practice with Envelope-To and X- variants.
We could easily document both that use and the loop breaking Delivered-To and
put them in the header registry.  That seems like a simple informational draft.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 7 Aug 2021 15:39:08 -0400

>than one original address was redirected to the same final address."

If there is more than one address, how are they listed?  Space separated, commas?

If we're going to describe this we might as well make the details match existing practice.

R's,
John

---

From: Jeremy Harris <[email-masked]>
Date: Sat, 7 Aug 2021 20:44:55 +0100

> If we're going to describe this we might as well make the details match existing practice.

Separated by the sequence comma, newline, space.
-- 
Cheers,
   Jeremy

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 7 Aug 2021 16:09:06 -0400

> than one Delivered-to: in the same message?

No.  Only one "Delivered-To:" per delivery of a given message to a
target recipient.

> alias2: remote-recipient-1, remote-recipient-2

In Postfix, when a message is sent to "alias1", the copy delivered to
"local-recipient-1" will have (with @domain suffixes as appropriate).

    Delivered-To: local-recipient-1

and the copy delivered to "local-recipient-2" will have:

    Delivered-To: local-recipient-2

When a message is sent to "alias2", there will be single 

    Delivered-To: alias2

prepended to a single message with two remote envelope recipients,
namely: remote-recipient-1 and remote-recipient-2.

> How many message copies do these generate, and what fields are added?

Remote deliveries are combined and get "Delivered-To" set to the input
alias, local deliveries are one at a time, and get a "Delivered-To" of
underlying mailbox address for that recipient.

But that said, this only applies to alias expansion in local delivery,
Postfix also supports (virtual) aliasing of recipients when relaying,
and there are no "Delivered-To:" headers added when relaying also
involves envelope recipient rewriting.  Thus a border MTA relaying
to an internal mailhub via SMTP and doing (e.g. LDAP based) rewriting
from the public domain to an internal domain does not treat such
rewriting as "delivery", it is merely rewrite-based relaying.

> alias3: alias3, extra-recipient-1

One copy is delivered to the user "alias3" (presumed to exist), and
another to "extra-recipient-1".  Both copies have the same
"Delivered-To" of "alias3".

-- 
    Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 7 Aug 2021 17:45:33 -0400

> Separated by the sequence comma, newline, space.

Disclosing the addresses of (potentially Bcc'd) recipients to each other
feels rather like a bug that would need fixing.

A transport that delivers a single message copy to multiple recipients
should not be adding "Delivered-To:" headers.

-- 
    Viktor.

---

From: Jeremy Harris <[email-masked]>
Date: Sat, 7 Aug 2021 23:51:57 +0100

> feels rather like a bug that would need fixing.

Exim takes a toolkit approach. You're allowed to shoot yourself
in the foot.  You're not forced to.
-- 
Cheers,
   Jeremy

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 7 Aug 2021 19:36:57 -0400

> in the foot.  You're not forced to.

Perhaps so long as Exim administrators are duly warned in the relevant
docs, and multi-recipient Delivered-To is not enabled by default, and
the collective experience of the Exim user community is that this is
not in practice a problem, then so be it...

In Postfix, the philosophy is safety first, so you'll find guard rails
such as:

    https://github.com/vdukhovni/postfix/blob/master/postfix/src/pipe/pipe.c#L1146-L1170

which softfail multi-recipient deliveries to a transport that is
configured to add "Delivered-To:" and/or "X-Original-To" headers.

-- 
    Viktor.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 16 Aug 2021 23:03:44 -0700

> The current draft probably qualifies under more than one of these.

I suggest considering BCP 9, which defines "Experimental" thus:

   The "Experimental" designation typically denotes a specification that
   is part of some research or development effort.  Such a specification
   is published for the general information of the Internet technical
   community and as an archival record of the work, subject only to
   editorial considerations and to verification that there has been
   adequate coordination with the standards process [...]

(Then again, BCP 9 has been updated over a dozen times, and I may have
missed an extended definition in one of those.)

I can see why people might find it odd to claim that something dating back
to the 1990s, as this draft says, is being categorized as an R&D effort
today.

Perhaps the Introduction might be amended to explain this perceived
discrepancy?

-MSK

---

From: John C Klensin <[email-masked]>
Date: Tue, 17 Aug 2021 10:10:25 -0400

--On Monday, August 16, 2021 23:03 -0700 "Murray S. Kucherawy"
<[email-masked]> wrote:

>> There are a number of possible reasons for seeking
>> Experimental status to an RFC:
>> 
>>       1. The technology is defines is not yet understood well
>>       enough and there are concerns that its functionality,
>> reliability, or the like might not behave as intended
>> 
>>       2. The proposed use of the technology might go beyond
>>       established practice and the expanded use might need
>> vetting
>> 
>>       4. The market might not be sufficiently interested in
>>       the technology to choose to use it
>> 
>>       5. The documentation of the technology might need wider
>>       review and comment
>> 
>    The "Experimental" designation typically denotes a
> specification that    is part of some research or development
> effort.  Such a specification    is published for the general
> information of the Internet technical    community and as an
> archival record of the work, subject only to    editorial
> considerations and to verification that there has been
> (Then again, BCP 9 has been updated over a dozen times, and I
> may have missed an extended definition in one of those.)
> 
> I can see why people might find it odd to claim that something
> dating back to the 1990s, as this draft says, is being
> categorized as an R&D effort today.
> 
> Perhaps the Introduction might be amended to explain this
> perceived discrepancy?

Murray,

A slightly different point of view.  While something called
"Delivered-to:" has been widely deployed, it appears from the
discussions of the last months that there is less than complete
agreement about semantics, intended purpose, and perhaps (I'm
not sure) even the syntax of the header field.  The draft
acknowledges those differences and has become more clear and
specific as we have moved along (thanks, Dave).  However, making
the definition and statement of intent has inevitably moved it
much closer to some implementations and conceptual models and
further from others.  

With one qualification, it seems to me that it would be a
legitimate experiment, well within the intent of BCP 9, to
create a definition this, or more, precise and then see whether
existing implementations that use this field or ones that appear
(at least superficially) similar to it evolve to conform.  That
seems consistent with several of the bullet points in Section 8
of the document as well.    The qualification is that, while it
would be interesting to find out if this were the exception, we
have considerable experience that, if a feature is implemented
and used by implementations with particular syntax and
semantics, the odds of those implementations making changes that
might disrupt existing uses and operations and introduce
confusion as to whether the "old" or "new" definitions were in
use is vanishingly small.   Nonetheless, it would be a real
experiment and it is not clear to me whether the document needs
additional work to explain that.

Another experimental bit is indirectly called out in the
document.  The "for" clause of the Received: header field goes
back to 821/822 or further.  In recent years, its use has been
discouraged, even though not formally deprecated, for reasons
very similar to those covered by the Security Considerations
section of the current document.   The description in Section 2
("However the clause is not used reliably") seem quite accurate.
But, to at least some extent, that means anther part of the
experiment is "why will this succeed when 'for' has fallen into
disuse or failed?" and/or "given that the objection to 'for' was
precisely the disclosures and address transformations discussed
in Section 6, how is 'Delivered-to:' better?".

The document mentions those issues, even if sometimes obliquely.
While my perspective may be a bit different, I don't think I am
saying anything new.  However, it seems much more clear now than
it was early in the year --from both the evolution of the
document and list discussions-- that the document is not
completely consistent with existing practices, no matter how
undocumented and informal.  With apologies for the lateness of
this suggestion (it did not occur to me until quite recently),
that suggests to me that, if this is an experiment, it would be
better to come up with a new name for the header field rather
than reusing one that is already in use.  That would make it
easier for existing implementations to be brought into
conformance because if would raise no issues about which
definition is in use (issues that would affect both contemporary
receivers and loop-detectors) and would make the experimental
issues much more clear.  

best,
   john

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 17 Aug 2021 10:52:19 -0400

On Tue, Aug 17, 2021 at 10:10:25AM -0400, John C Klensin wrote:

> not sure) even the syntax of the header field.

The field is known to be implemented since the 90's in three widely used
MTAs: Qmail, Postfix and Courier.  All three use it for loop detection,
it is private data for use by the MDA that adds the header field, should
the message circle back for repeated delivery.

In that light, edge-cases with a variant syntax are also a private
matter for the MDA that uses such syntax.  So long as the header field
value does not collide with a value used in any other ADMD, there's no
problem.

> The draft acknowledges those differences and has become more clear and
> specific as we have moved along (thanks, Dave).  However, making the
> definition and statement of intent has inevitably moved it much closer
> to some implementations and conceptual models and further from others.  

The draft doggedly refuses to specify the *semantics* of the field as
private data for use by the MDA.  No motivating use-case is provided
that justifies any imputed new semantics.

Thus instead of clarifying the field's use, the draft muddies the water
by (perhaps implicitly) suggesting that a conforiming MDA is bound to
record an address that is proper input for divining the message
by a downstream MUA.  For that use-case, the long-standing deliberate
practice is to use alternative headers and NOT "Delivered-To:".

> With one qualification, it seems to me that it would be a legitimate
> experiment, well within the intent of BCP 9, to create a definition
> this, or more, precise and then see whether existing implementations
> that use this field or ones that appear (at least superficially)
> similar to it evolve to conform.

The experiment is dead on arrival.  While Postfix (the largest
deployment of "Delivered-To" by number of MTAs, though perhaps not by
user count when compared with Gmail) conforms to the syntax described in
the draft, we disavow any external interpretation of the payload, and
will not participate in any experiment that reinterprets the field value
as public data.  For that we have "X-Original-To", but if someone wants
to standardise "Envelope-To" or some other similar field, we'd be open
to using a more widely interoperable header.

> The qualification is that, while it would be interesting to find out
> if this were the exception, we have considerable experience that, if a
> feature is implemented and used by implementations with particular
> syntax and semantics, the odds of those implementations making changes
> that might disrupt existing uses and operations and introduce
> confusion as to whether the "old" or "new" definitions were in use is
> vanishingly small.

No changes to accommodate any new semantics will happen in Postfix.  If
the entire scope of the "experiment" is to see whether a common syntax
would be widely adopted, the "experiment" is already over, the common
syntax proposed is already widely adopted.

If the "experiment" aims to see whether MDAs will conform to semantics
that enable downstream determination of the recipient by MUAs, then
the "experiment" is also already over, at least as far as Postfix is
concerned.  No change in the semantics making the value non-private
data will implemented.

> Nonetheless, it would be a real experiment and it is not clear to me
> whether the document needs additional work to explain that.

The document skirts the key question of why it is needed at this time.
If the field payload is MDA-private, it hardly needs a specification,
what is the purpose of a specification at this time, especially one
that refuses to specify the key semantic property (private use).

An informational document specifying how the field is actually used
(to avoid any confusion) would make considerably more sense.

-- 
    Viktor.

---

From: John C Klensin <[email-masked]>
Date: Tue, 17 Aug 2021 11:03:50 -0400

--On Friday, August 6, 2021 04:29 -0400 Valdis Klētnieks
<[email-masked]> wrote:

>> If we have a mail corpus it'd be interesting to see how many
>> Received headers have "for" clauses and if they match up at
>> all with Delivered-To.
>> 
> For the very old corpus, there were a total of 214,585
> Received: lines, of which 65,273 had a ' for ' clause.
> 
> By comparison, out of some 31,000 emails I received during
> June of this year, there are 270,893 Received: lines, of which
> 23,253 have a ' for ' clause.  A quick eyeball indicates that
> Postfix, Exim, and Google all do it for single-recipient
> deliveries (several representative examples):
>...

Let me try to generalize a little bit from experience, although
I think the data given are consistent with what I'm about to
suggest.  What follows is mostly historical; those who don't
care can safely stop reading or skip to the last paragraph about
the footnotes.

Once upon a time, "for" was very heavily used, not just in
single-recipient messages but to trace address transformations.
Especially in the days before "List-*" header fields, knowing
whether a message that was received originated from a mailing
list and which one (and is) was very useful.  Often the
traditional "To:" or "Cc:" header fields provided that
information but not always (and not always reliably)[0].  That
information is related to the presumed target address close to
the injection of a message into the system and hence very
different from "Delivered-to:" but, if "for" is relevant to this
discussion, we cannot dismiss it.   And, especially for
debugging and tracing, it was also important in situations where
messages moved between transport environments with possible
destination address translation at the boundaries [1].

It was, however, never very popular for multi-recipient
messages.  I believe that was partially because the specs were
never clear about what was supposed to be done with them [2].

That was mostly at a time when we didn't pay much attention to
privacy of envelope information and, more generally, the
question of which parties were sending or receiving mail as long
as content could be protected [3].  As sensitivity to privacy of
that information increased, the use of "for" decreased.  The
reduced percentage of "Received:" lines in Valdis's data seem
consistent with that [4].

Coming back to the document after that long digression, if we
think that confusion between the intended use of "for" and the
intended use of "Delivered-to:" is important, it might be useful
to include somewhat more text than is now present to explain the
difference between the intent and application of the two.  I'll
leave to others whether that is worth the trouble in a
to-be-Experimental text that has been kicking around this long.

best,
   john

[0] Consider the position of a recipient looking at a message in
which their address does not appear in either field although one
or more individual recipients to and, perhaps, so do two or more
addresses of mailing lists.  Now, was the message transferred
through one of those list?  The other? or is a a "blind" (sic)
copy?  The answer can usually be deduced by working through all
of the "Received:" fields and other available information, but
doing so involved heuristics well beyond the skills of typical
email users.

[1] If anyone has far too much time on their hands, it would be
interesting to 
try to reconstruct the reasons why MIXER (RFC 2156) does not
mention "for".

[2] We probably should have spotted that during the discussions
leading to RFC 1123 or during the DRUMS effort and said
something in 1123 or 2821.  We didn't. At least partially mea
culpa.  Sorry.

[3] Analogies to the postal system and, at least in the US and
the environments in which I was working, "pen registers" in the
PSTN are obvious and were frequently cited.

[4] A caution: my general impression, one that is, I think,
important to the believe that SMTP over TLS (or equivalent) are
Good Things, is that we are doing far less relaying than was the
case decades ago.  Unless the increased number of Received lines
is simply due to significantly increased message load something
is adding a lot of those lines rather than seeing them reduced.

---

From: John C Klensin <[email-masked]>
Date: Tue, 17 Aug 2021 11:47:07 -0400

--On Tuesday, August 17, 2021 10:52 -0400 Viktor Dukhovni
<[email-masked]> wrote:

>> discussions of the last months that there is less than
>> complete agreement about semantics, intended purpose, and
>> perhaps (I'm not sure) even the syntax of the header field.
> 
> The field is known to be implemented since the 90's in three
> widely used MTAs: Qmail, Postfix and Courier.  All three use
> it for loop detection, it is private data for use by the MDA
> that adds the header field, should the message circle back for
> repeated delivery.
> 
> In that light, edge-cases with a variant syntax are also a
> private matter for the MDA that uses such syntax.  So long as
> the header field value does not collide with a value used in
> any other ADMD, there's no problem.

I think this is a reasonable position.  However, it then
suggests, as I think you have earlier as well as below, that
this is not an Experiment but a description of existing
_private_ practices, which would make it Informational.  If we
are defining syntax (and I note your argument elsewhere), it
also suggests that MDAs identify themselves somehow in the field
so that one private use can be distinguished from another [1].
Of course, if all or part of the field were encoded in a way
that only one MDA could understand -- i.e., that an attempt to
decode it into someone usable would fail if the MDA doing the
decoding were different from the one that put it there -- it
would accomplish that purpose (see Ned's comment on the 13th
[2]).

>> The draft acknowledges those differences and has become more
>> clear and specific as we have moved along (thanks, Dave).
>> However, making the definition and statement of intent has
>> inevitably moved it much closer to some implementations and
>> conceptual models and further from others.  
> 
> The draft doggedly refuses to specify the *semantics* of the
> field as private data for use by the MDA.  No motivating
> use-case is provided that justifies any imputed new semantics.
> 
> Thus instead of clarifying the field's use, the draft muddies
> the water by (perhaps implicitly) suggesting that a
> conforiming MDA is bound to record an address that is proper
> input for divining the message by a downstream MUA.  For that
> use-case, the long-standing deliberate practice is to use
> alternative headers and NOT "Delivered-To:".

I am not completely sure, but I think we agree on that subject.

>> create a definition this, or more, precise and then see
>> whether existing implementations that use this field or ones
>> that appear (at least superficially) similar to it evolve to
>> conform.
> 
> deployment of "Delivered-To" by number of MTAs, though perhaps
> not by user count when compared with Gmail) conforms to the
> syntax described in the draft, we disavow any external
> interpretation of the payload, and will not participate in any
> experiment that reinterprets the field value as public data.
> For that we have "X-Original-To", but if someone wants to
> standardise "Envelope-To" or some other similar field, we'd be
> open to using a more widely interoperable header.
> 
>> The qualification is that, while it would be interesting to
>> find out if this were the exception, we have considerable
>> experience that, if a feature is implemented and used by
>> implementations with particular syntax and semantics, the
>> odds of those implementations making changes that might
>> disrupt existing uses and operations and introduce confusion
>> as to whether the "old" or "new" definitions were in use is
>> vanishingly small.
> 
> No changes to accommodate any new semantics will happen in
> Postfix.  If the entire scope of the "experiment" is to see
> whether a common syntax would be widely adopted, the
> "experiment" is already over, the common syntax proposed is
> already widely adopted.

> If the "experiment" aims to see whether MDAs will conform to
> semantics that enable downstream determination of the
> recipient by MUAs, then the "experiment" is also already over,
> at least as far as Postfix is concerned.  No change in the
> semantics making the value non-private data will implemented.

With the understanding that my "vanishingly small" is probably
the same in practice as your "over", that just reinforces my
point so, again, I think we agree.

>> Nonetheless, it would be a real experiment and it is not
>> clear to me whether the document needs additional work to
>> explain that.
> 
> The document skirts the key question of why it is needed at
> this time. If the field payload is MDA-private, it hardly
> needs a specification, what is the purpose of a specification
> at this time, especially one that refuses to specify the key
> semantic property (private use).
> 
> An informational document specifying how the field is actually
> used (to avoid any confusion) would make considerably more
> sense.

I'm becoming increasingly convinced of that.  I think that, if
there is to be an Experiment, it needs to start with a new
header field name and then either define both syntax and
semantics in a way that would make interoperability possible
-or- define a private-use field in which there was a clear and
interoperable way for one private instance to distinguish itself
from others.

best,
  john

[1] I am deliberately not making a distinction between "MDA" as
a particular implementation (like Postfix) or a particular
operational instance and configuration.  I don't think it makes
a difference to this discussion but it would obviously need to
be clear in any specification.

[2]
https://mailarchive.ietf.org/arch/msg/ietf-smtp/InmwN2cNEpTDPAn6cHfHmmwcwM8

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 17 Aug 2021 11:48:59 -0400

> single-recipient messages but to trace address transformations.

The issue disappears once we correctly define single-recipient.
Provided single-recipient means single *input* envelope address, (e.g.
single "RCPT TO" in SMTP or SUBMIT), no extant MTA I'm aware of adds a
"for" clause recording one of many or multiple envelope recipients of
the same message (envelope) that then ends up disclosing "Bcc"
recipients to other recipients, ...

Of course the "single" recipient might subsequently expand to multiple
recipients that all receive copies of the original "single-recipient"
message, that's fine and expected.

Do you have any evidence of extant MTAs recording "for" clauses that
violate the above?  If you find misguided use of "for" in a vintage MTA
snapshot from the 1980s, I might not be surprised...

> It was, however, never very popular for multi-recipient

The "for" clause should never appear for messages with multiple envelope
recipients, unless "for" is added on delivery (after the envelope
splits) rather than on input (prior to envelope split).  It should never
record any recipient address that wasn't the address that caused the
message to be routed to the receiving user.

> privacy of envelope information

Discloure of unrelated Bcc addresses that did not lead to the recipient
reading the mesage is not a privacy issue, it violates the expected
semantics of the message, and is a bug in any MTA that does it.

> As sensitivity to privacy of that information increased, the use of
> "for" decreased.

Perhaps because Microsoft never implemented it in Exchange, rather than
any privacy concern.

> to-be-Experimental text that has been kicking around this long.

If "for" should be clarified, let's do it in a document that is separate
from "Delivered-To".  This feels like proper scope for 5321bis, and not
a document specifying the "Delivered-To" field.

-- 
    Viktor.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 17 Aug 2021 09:32:42 -0700

> additional work to explain that.

Fair enough.  I don't necessarily object to the use of Experimental, but I
think it appropriate to explain its curious use in the context of a
technique that has existed in some form for quite a while now.   I take the
BCP 9 definition to mean "let's try this" more so than "let's write down
this thing we've been 'trying' in some form or another since the '90s".
Anyone reviewing this later (the ISE, the IESG during its conflict review,
anyone the ISE asks to look at it, etc.) is also liable to trip over this,
so a sentence or two explaining the dissonance would probably help to
smooth its handling.

-MSK

---

From: John C Klensin <[email-masked]>
Date: Tue, 17 Aug 2021 13:19:16 -0400

--On Tuesday, August 17, 2021 09:32 -0700 "Murray S. Kucherawy"
<[email-masked]> wrote:

>> conform.  That seems consistent with several of the bullet
>> points in Section 8 of the document as well.    The
>> qualification is that, while it would be interesting to find
>> out if this were the exception, we have considerable
>> vanishingly small.   Nonetheless, it would be a real
>> experiment and it is not clear to me whether the document
>> needs additional work to explain that.
>> [...]
>> 
> 
> Fair enough.  I don't necessarily object to the use of
> Experimental, but I think it appropriate to explain its
> curious use in the context of a technique that has existed in
> some form for quite a while now.   I take the BCP 9 definition
> to mean "let's try this" more so than "let's write down this
> thing we've been 'trying' in some form or another since the
> '90s". Anyone reviewing this later (the ISE, the IESG during
> its conflict review, anyone the ISE asks to look at it, etc.)
> is also liable to trip over this, so a sentence or two
> explaining the dissonance would probably help to smooth its
> handling.

Murray,

I certainly agree that there is some apparent dissonance, that
the use is curious, and that more explanation would be desirable
and possibly a requirement.  
 
However, after thinking more about the comments from Victor
today and reviewing more of the comments on list, I think there
is another serious obstacle (or maybe just a choice).  IMO
(now), if it is an Experiment, it must either:

* carefully explain its relationship to existing implementations
that probably won't change, address the question of semantics
that Victor and others have raised (either what they are or why
they are unimportant), and make what it would mean to be
interoperable clear.  Probably that includes some hints about
how a particular MDA or other user of the field can distinguish
the new/Experimental version and definition from the historical
ones. The interoperability issue is no less important if
"private" is part of the story than if it is not although the
"private" description would probably be much shorter.

   --or--

* treat this a something new, with a new header field name, and
proceed to describe that new thing.  Presumably that should
include a discussion of why it is different and implementations
should provide it instead or in in addition to Delivered-to,
Envelope-to, Received...for, and anything else that is
considered particularly relevant, but we have traditionally cut
Experimental documents some slack and it would be, IMO, entirely
plausible for an Experimental description of a header field with
a new name to carefully describe figuring that out as part of
the experiment.  A new field name would bring a bonus: we could
consider whether a registered token at the beginning of the
field that identified the relevant MDA (or whatever) would be
helpful in efficiently eliminating any possible "is this really
mine" confusion.

Otherwise, it seems likely to me (and I gather certain to
Victor) that an "Experiment" would be generally ignored (in
which case, what would the point be) or that it would introduce
confusion with existing practice (in which case there should be
far stronger reasons to not publish than procedural definitions).

Where Victor (and others) and I may disagree is whether the
first of those options is even possible.  I think it probably
is, but I am not strongly convinced (and "probably possible"
does not translated to "necessarily a good idea").

best,
   john

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 17 Aug 2021 14:37:10 -0700

On Tue, Aug 17, 2021 at 10:19 AM John C Klensin <[email-masked]> wrote:

> considered particularly relevant, [...]

I would like to take this opportunity, given the number of implementers in
the room (guten tag, Claus!), to ask:

Hypothetically, if this work were to take the path of declaring a new code
point for this purpose, what's the likelihood of adoption?

Please note "instead of or in addition to" in the sentiment above.

-MSK

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 17 Aug 2021 17:46:57 -0400

> On 17 Aug 2021, at 5:37 pm, Murray S. Kucherawy <[email-masked]> wrote:
> 
> I would like to take this opportunity, given the number of implementers in the room (guten tag, Claus!), to ask:
> 
> Hypothetically, if this work were to take the path of declaring a new code point for this purpose, what's the likelihood of adoption?
> 

Perhaps, but first it'd have to be clear what "this purpose" means.

  - Standardise "Envelope-To"/"X-Original-To" that records the public input address
    that led to the recipient, thus unifying a common feature of Exim/Postfix/...

  - Standardise a variant of "Delivered-To" for consumption by downstream MUAs that
    is not MTA-private for loop detection, but rather a commitment to record the
    actual delivery address and not "some opaque token" (that often happens to be
    the delivery address)?  If so, what's the use-case?  Who needs this, and what
    are they going to do with it that would motivate implementation?

  - Something else?  For what audience, and why?

-- 
	Viktor.

---

From: John C Klensin <[email-masked]>
Date: Tue, 17 Aug 2021 18:47:34 -0400

--On Tuesday, August 17, 2021 14:37 -0700 "Murray S. Kucherawy"
<[email-masked]> wrote:

>> * treat this a something new, with a new header field name,
>> and proceed to describe that new thing.  Presumably that
>> should include a discussion of why it is different and
>> implementations should provide it instead or in in addition
>> to Delivered-to, Envelope-to, Received...for, and anything
>> else that is considered particularly relevant, [...]
> 
> 
> I would like to take this opportunity, given the number of
> implementers in the room (guten tag, Claus!), to ask:
> 
> Hypothetically, if this work were to take the path of
> declaring a new code point for this purpose, what's the
> likelihood of adoption?
> 

Murray, two clarifying questions, both orthogonal to Viktor's
comments/questions:

(1) By "new code point", you mean "new header field and header
field name", right?

(2) Would a useful supplemental question be 'if you already have
something roughly equivalent to "Delivered-to:" (however you
define that), would you be more likely to make changes to adopt
a new field or to adapt your field to a new, Experimental,
"Delivered-to:" spec descended from
draft-crocker-email-deliveredto-09 if the details in that spec
were nailed down sufficiently that changes might be needed?'.

The second question is predicated by the assumption (which might
be incorrect) that, if the "Delivered-to:" spec is purely
descriptive of existing implementations up to some point and
ignores or hand-waves around any differences among those
implementations, we would (or should) be talking about an
informational spec, not an Experimental one ... unless the core
experiment is to determine whether the document is accurate, and
that, IMO, would fail the BCP 9 criteria you were asking about.

best,
   john

---

From: John C Klensin <[email-masked]>
Date: Tue, 17 Aug 2021 20:07:51 -0400

Viktor,

This sort of got lost in the other discussion... sorry.  I'm
adjusting the subject line.

--On Tuesday, August 17, 2021 11:48 -0400 Viktor Dukhovni
<[email-masked]> wrote:

> Provided single-recipient means single *input* envelope
> address, (e.g. single "RCPT TO" in SMTP or SUBMIT), no extant
> MTA I'm aware of adds a "for" clause recording one of many or
> multiple envelope recipients of the same message (envelope)
> that then ends up disclosing "Bcc" recipients to other
> recipients, ...
> 
> Of course the "single" recipient might subsequently expand to
> multiple recipients that all receive copies of the original
> "single-recipient" message, that's fine and expected.
> 
> Do you have any evidence of extant MTAs recording "for"
> clauses that violate the above?  If you find misguided use of
> "for" in a vintage MTA snapshot from the 1980s, I might not be
> surprised...

My (vague) recollection involved some systems trying to put in
multiple addresses (when there were multiple RCPT commands a
very long time ago.  But I would be more than mildly astonished
if any extant MTA was doing it, especially because the extant
embedded, pre RFC 1425 and 2721, that are using dedicated MTAs
(maybe Submission Servers in today's language and still speaking
821) are definitely single-address.  As far as anything I know
of that is contemporary, my understanding and your analysis
agree.

> The "for" clause should never appear for messages with
> multiple envelope recipients, unless "for" is added on
> delivery (after the envelope splits) rather than on input
> (prior to envelope split).  It should never record any
> recipient address that wasn't the address that caused the

While I agree, the specs are not nearly that specific.  See
below.

> Discloure of unrelated Bcc addresses that did not lead to the
> recipient reading the mesage is not a privacy issue, it
> violates the expected semantics of the message, and is a bug
> in any MTA that does it.

That is really a separate question.  Remembering that something
with the functionality of a submission server is likely to know
the difference between "To:", "Cc:" and "Bcc:" recipients (even
if an NTA receiving RCPT commands does not), _if there were no
other issues_ a "for" clause that showed more than one (or
all)of the "To:" and "Cc:" would be perfectly reasonable from
the standpoint of information disclosure to the recipients,
which is what I think you are talking about.

>> As sensitivity to privacy of that information increased, the
>> use of "for" decreased.
> 
> Perhaps because Microsoft never implemented it in Exchange,
> rather than any privacy concern.

Perhaps.  But if every email feature that was not implemented,
or implemented incorrectly, in Exchange had dropped out of
contemporary usage, the world would probably look a lot
different.

>> intended use of "Delivered-to:" is important, it might be
>> useful to include somewhat more text than is now present to
>> explain the difference between the intent and application of
>> the two.  I'll leave to others whether that is worth the
>> trouble in a to-be-Experimental text that has been kicking
>> around this long.
> 
> If "for" should be clarified, let's do it in a document that
> is separate from "Delivered-To".  This feels like proper scope
> for 5321bis, and not a document specifying the "Delivered-To"
> field.

Agree completely.  My working hypothesis is that 5321bis/5322bis
are ok but that a variations of your explanation above might be
useful in the A/S.  If you (or anyone else) think something is
needed, please go to EMAILCORE and open a ticket.  I brought
"for" up in my note only because it is an element of the "what
is an additional header field needed for and what are the
semantics of its content" question.

   john

---

From: Ned Freed <[email-masked]>
Date: Wed, 18 Aug 2021 07:57:01 -0700 (PDT)

> >> single-recipient messages but to trace address

Our MTA still generates it by default, but it's easily disabled.

> > that then ends up disclosing "Bcc" recipients to other

Assuming what you put in the for clause is in fact the initial RCPT TO (more on
that below), it's a bit more complex than this. For a given output message
copy, there are four cases:

(0) The message copy is associated with a single recipient, which
    originated from a single RCPT TO.

(1) The message copy is associated with multiple recipients, but they
    originated from a single RCPT TO.

(2) The message copy is associated with a single recipient, which
    originated from multiple RCPT TOs.

(3) The message copy is associated with multiple recipients from
    multiple RCPT TOs.

(3) is clearly the do not generate case, (0) and (1) are OK to generate.

The odd case is (3). Treating it as a do not generate case seems reaonable to
me, but OTOH aside from possible confusion I'm not seeing a strong reason not
to generate.

> > "single-recipient" message, that's fine and expected.

Case (1) above. However, this again assumes what's being logged in
the for clause is the original RCPT TO. Neither RFC 5321 nor its
predecessors actually require this, and it's not what we do: Since
we defer Received: field generation to the point at which the message
copy is created, we use a "nearly" final version of the address, which
can be completely different from the RCPT TO.

> > "for" in a vintage MTA snapshot from the 1980s, I might not be

I've seen syntactically invalid stuff, but not, AFAICR, multiple
addresses.

> > (prior to envelope split).

That's one of the reasons why we wait - we want to take full advantage
of any splits that occur. And there are lots of things that can
trigger a split.

> > It should never record any

> While I agree, the specs are not nearly that specific.  See

Unfortunate but true. The text implies that what's recorded has
something to do with RCPT TO fields, but that's as far as it goes.

We probably should fix this in 5321bis.

> > violates the expected semantics of the message, and is a bug

Email addresses are commonly classified as Personally Identifiable Information
(PII). Improper disclosure of PII is most definitely a privacy issue, although
whether or not this dictates email system behavior in general or 
this case in particular is unclear.

There's another security issue lurking in all this: If the  system inserts a
"for" clause when there's only one recipient, and doesn't when there are more
than one, the absence of the field is itself an indication that there's another
recipient, which may allow someone to infer a Bcc: is involved.

Note that this last consideration applies to any field whose generation
is conditional on there being only one recipient,

> > rather than any privacy concern.

Good point.

> semantics of its content" question.

I think a statement to the effect that the value of the for clause must contain
one of the addresses that caused the message to be routed to the recipient of
this message copy. Discussion of which value to use - if we want to go there -
is an AS matter.

And while the security issue I pointed out may be a bit obscure - although I
have used it myself on several occasions - I thkn it needs to be
mentioned.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Wed, 18 Aug 2021 15:20:09 -0400

Ned,

Thanks.  Comment on an otherwise-trimmed message with which I
completely agree although the additional information was
interesting and, IMO, helpful:

--On Wednesday, August 18, 2021 07:57 -0700 Ned Freed
<[email-masked]> wrote:

>...
> There's another security issue lurking in all this: If the
> system inserts a "for" clause when there's only one recipient,
> and doesn't when there are more than one, the absence of the
> field is itself an indication that there's another recipient,
> which may allow someone to infer a Bcc: is involved.

Yes.  That had not occurred to me and it may be yet another
argument for MUAs simply generating two (or more) message copies
where BCCs are involved.    Doing that would take the transport
system out of the business of needing any of these heuristics,
at least to protect information about BCCs or their existence.
 
> Note that this last consideration applies to any field whose
> generation is conditional on there being only one recipient,

Yep.

>> > is separate from "Delivered-To".  This feels like proper
>> > scope for 5321bis, and not a document specifying the
>> > "Delivered-To" field.
> 
>> Agree completely.  My working hypothesis is that
>> 5321bis/5322bis are ok but that a variations of your
>> explanation above might be useful in the A/S.  If you (or
>> anyone else) think something is needed, please go to
>> EMAILCORE and open a ticket.  I brought "for" up in my note
>> only because it is an element of the "what is an additional
>> header field needed for and what are the semantics of its
>> content" question.
 
> I think a statement to the effect that the value of the for
> clause must contain one of the addresses that caused the
> message to be routed to the recipient of this message copy.
> Discussion of which value to use - if we want to go there - is
> an AS matter.

Sounds about right.

> And while the security issue I pointed out may be a bit
> obscure - although I have used it myself on several occasions
> - I thkn it needs to be mentioned.

Wfm.

See note just posted to the emailcore list.

best,
    john

---

From: Jeremy Harris <[email-masked]>
Date: Wed, 18 Aug 2021 22:57:55 +0100

> Please note "instead of or in addition to" in the sentiment above.

 From an Exim implementor's POV, I'd want to know "what's the purpose?"
before answering.  Lacking a compelling one, I see no incentive.
-- 
Cheers,
   Jeremy

---

From: "John Levine" <[email-masked]>
Date: 18 Aug 2021 18:54:59 -0400

>point for this purpose, what's the likelihood of adoption?

I'm reasonably plugged into the qmail developer community and see no interest.

We have our existing delivered-to which does what it does.  People who use 
fetchmail have some long-established kludges to sort their mail and again
I have never seen anyone ask for anything beyond what they have.

R's,
John

---

From: Claus Assmann <[email-masked]>
Date: Thu, 19 Aug 2021 13:03:03 +0200

> point for this purpose, what's the likelihood of adoption?

We haven't gotten any requests for something like this (not even
"Delivered-To:") - hence there is no plan to add it to sendmail.
Moreover, the rulesets in sendmail allow to add/check headers,
so someone might have added it for themselves.
As long as there is no "problem to solve", why waste time on this?