Subject: [Emailcore] Delivered-To header

From: "John R Levine" <[email-masked]>
Date: 31 Dec 2020 10:55:31 -0500

RFC5321 says that when a message is delivered the envelope MAIL FROM 
address goes into a Return-Path header, but says nothing about the RCPT TO 
address.  Many MTAs put that in a Delivered-To header and have done so for 
a long time.  I know that Postfix and qmail do.  It shows up in examples 
in RFCs 5293 and 7681.

I think this is sufficiently established that we can add it to 5321bis. 
We could say that the delivery SMTP server SHOULD insert a Delivered-To 
line when it inserts a Return-Path line, and SHOULD NOT remove existing 
Delivered-To lines.

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

---

From: Michael Peddemors <[email-masked]>
Date: Thu, 31 Dec 2020 08:03:29 -0800

On 2020-12-31 7:55 a.m., John R Levine wrote:
> address goes into a Return-Path header, but says nothing about the RCPT 
> TO address.  Many MTAs put that in a Delivered-To header and have done 
> so for a long time.  I know that Postfix and qmail do.  It shows up in 
> examples in RFCs 5293 and 7681.
> 

This one may not be a simple as that. Delivered-To gets populated 
sometimes enroute to it's final distination, eg when local forwarding 
rules or email processors operate on the message before it's final 
destination.  You could have multiple Delivered To in those cases.

The business rules and logic on WHEN a MAIL FROM gets put into a 
Return-Path is/could be different than the logic for placing a Delivered-To

...

Speaking of which, more emphasis should be placed on servers NOT 
forwarding emails with a Return-Path in place, it was only meant to be 
placed at the final destination.. or at least, if you are going to make 
the decision late that you are not the final destination, remember to 
strip the Return-Path that your systems added before redirecting..

-- 
"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: Jeremy Harris <[email-masked]>
Date: Thu, 31 Dec 2020 16:08:58 +0000

On 31/12/2020 15:55, John R Levine wrote:
> RFC5321 says that when a message is delivered the envelope MAIL FROM address goes into a Return-Path header, but says nothing about the RCPT TO address.  Many MTAs put that in a Delivered-To header and have done so for a long time.  I know that Postfix and qmail do.  It shows up in examples in RFCs 5293 and 7681.
> 
> I think this is sufficiently established that we can add it to 5321bis. We could say that the delivery SMTP server SHOULD insert a Delivered-To line

Just because some (and not all) MTAs do?
Better justification needed, I think.
-- 
Cheers,
   Jeremy

---

From: Phil Pennock <[email-masked]>
Date: Thu, 31 Dec 2020 11:12:58 -0500

On 2020-12-31 at 10:55 -0500, John R Levine wrote:
> RFC5321 says that when a message is delivered the envelope MAIL FROM address
> goes into a Return-Path header, but says nothing about the RCPT TO address.
> Many MTAs put that in a Delivered-To header and have done so for a long
> time.  I know that Postfix and qmail do.  It shows up in examples in RFCs
> 5293 and 7681.
> 
> I think this is sufficiently established that we can add it to 5321bis. We
> could say that the delivery SMTP server SHOULD insert a Delivered-To line
> when it inserts a Return-Path line, and SHOULD NOT remove existing
> Delivered-To lines.

Exim spells this "Envelope-to:" and it's not enabled by default in the
code but the sample configurations set it by default for delivery to
files.  By contrast, the `envelope_to_remove` option defaults to true,
so that if this header is seen then folks can have confidence it's
local.

My initial gut reaction (therefore wrong) is that how mail is stored
locally is out-of-scope for the specification of SMTP and how mail is
transferred between systems.

Against that, a common pattern of what behavior folks can count on would
make sense for ensuring data can gateway _back_ to SMTP cleanly.  Yet
with some mailbox formats perhaps better suited to this flow, this is
persisted outside of the main headers and restored cleanly without
header parsing.

What's the rationale for leaving alone the existing Delivered-To:
headers?  Is this a Trace header which must always be prepended, so
folks should always use the first one seen scanning from the top?

-Phil

---

From: "Alexey Melnikov" <[email-masked]>
Date: Thu, 31 Dec 2020 16:14:38 +0000

> line when it inserts a Return-Path line, and SHOULD NOT remove existing 

https://trac.ietf.org/trac/emailcore/ticket/44

---

From: "Alexey Melnikov" <[email-masked]>
Date: Thu, 31 Dec 2020 16:16:44 +0000

> Better justification needed, I think.

Speaking as a participant: I think SHOULD allows implementations not to add it, so the proposed text seems to be fine as is.

---

From: John C Klensin <[email-masked]>
Date: Thu, 31 Dec 2020 11:19:07 -0500

--On Thursday, December 31, 2020 10:55 -0500 John R Levine
<[email-masked]> wrote:

> RFC5321 says that when a message is delivered the envelope
> MAIL FROM address goes into a Return-Path header, but says
> nothing about the RCPT TO address.  Many MTAs put that in a
> Delivered-To header and have done so for a long time.  I know
> that Postfix and qmail do.  It shows up in examples in RFCs
> 5293 and 7681.
> 
> I think this is sufficiently established that we can add it to
> 5321bis. We could say that the delivery SMTP server SHOULD
> insert a Delivered-To line when it inserts a Return-Path line,
> and SHOULD NOT remove existing Delivered-To lines.

If we take the rules seriously, the moment you do that, existing
implementations that don't do that become nonconforming and
rfc5321bis goes to Proposed.

Alternate suggestion: Make sure it the header field is
registered in the appropriate registry (I'm fairly sure it is
but don't have time to go check today).   Then make this a
strong recommendation in the A/S.

   john

---

From: John C Klensin <[email-masked]>
Date: Thu, 31 Dec 2020 11:33:22 -0500

--On Thursday, December 31, 2020 16:16 +0000 Alexey Melnikov
<[email-masked]> wrote:

>> > nothing about the RCPT TO address.  Many MTAs put that in
>> > a Delivered-To header and have done so for a long time.  I
>> > know that Postfix and qmail do.  It shows up in examples
>> > in RFCs 5293 and 7681.
>> > 
>> > I think this is sufficiently established that we can add it
>> > to 5321bis. We could say that the delivery SMTP server
>> > SHOULD insert a Delivered-To line
>> 
> Speaking as a participant: I think SHOULD allows
> implementations not to add it, so the proposed text seems to
> be fine as is.

Please reread 2119.  SHOULD implies that an implementation needs
a reason to not add it (and to not spell it that way) and that
the reason should be better than "didn't feel like it" or "have
been doing something similar for decades and my users don't like
changes to fields to which they have become accustomed".  If
adding it were discretionary with the implementation, that is
spelled "MAY" followed by some encouragement.  

Unless there is a strong, substantive, reason for doing this, as
Jeremy put it, "Just because some (and not all) MTAs do" is not
sufficient justification for adding a new requirement to
5321bis, especially since there is no way to guarantee that no
one will object to moving the resulting document to Internet
Standard because it _is_ a new requirement and convince enough
of the IESG to tie this effort in knots.

IMO, the only justifications for new requirements in 5321bis or
5322bis (and taking that risk) are to recognize something that
_substantially all_ implementations are doing already and doing
in the same way or to specify the (already extensively tested)
remedy for major security or other issue that has shown up in
many places in the wild and demonstrated to have been a
significant problems.

     john

---

From: "Alexey Melnikov" <[email-masked]>
Date: Thu, 31 Dec 2020 16:44:18 +0000

Hi John,

> spelled "MAY" followed by some encouragement.  

Yes, you are right. I was being a bit of devil's advocate without being explicit about that.

I think I would like to see some quick discussion about:

How widespread adding Delivered-To is?

Are there any reasons (security or otherwise) for adding or not adding Delivered-To.

---

From: Michael Peddemors <[email-masked]>
Date: Thu, 31 Dec 2020 08:56:58 -0800

> Are there any reasons (security or otherwise) for adding or not adding Delivered-To.

Wide spread enough ;)  All our platforms use it, and it is critically 
used for various aspects of email delivery.

I also believe it is still in use in all Qmail based email platforms, 
among others..

Delivered-To is a trace header, it couple have multiple records, 
depending on how the email is processed internally at destination.

And from a security aspect, only those headers that are inserted by a 
receiving mail system would be trusted.  Normally, for instance those 
entries in the header above the last trusted Received line.

There COULD be other ramifications.. you always get some people who 
throw up the 'privacy' ramifications, (the final recipient gets to see 
in interim destination) but usually that is important, and valid 
information to the recipient.  (eg, the email WAS actually delivered to 
my mailbox, and came via a delivery route of a role address)

A message COULD be injected into an IMAP mailbox, with forged 
Delivered-To headers of course, but the absence of that header is a 
distinct indication that the message did not transverse an expected 
delivery path.

---

From: "John R Levine" <[email-masked]>
Date: 31 Dec 2020 12:16:33 -0500

> rfc5321bis goes to Proposed.

Hmmn.

> strong recommendation in the A/S.

It's not registered, which surprised me and is why I'd like to put it in 
5321bis.  How about if we add it as a MAY ?

Regards,

---

From: "John Levine" <[email-masked]>
Date: 31 Dec 2020 12:26:06 -0500

>transferred between systems.

That argument was over in 1981 when RFC 788 said to add Return-Path when
mail is delivered.

>folks should always use the first one seen scanning from the top?

Yes.  That's the existing practice.

R's,
John

---

From: "John R. Levine" <[email-masked]>
Date: 31 Dec 2020 12:52:25 -0500

> Better justification needed, I think.

Postfix and qmail add it, and have for decades.  Gmail adds it.  It's 
shown up in examples in RFCs.

I think Exim is in the rough here.

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

---

From: John C Klensin <[email-masked]>
Date: Thu, 31 Dec 2020 13:12:07 -0500

John,

Briefly as I have to run.   If it isn't in the registry,
probably adding it is a first step.  Probably Envelope-to should
be added to the header registry too, with appropriate notes
about how the two might be the same or different.  However, that
relationship, the question of what to do if multiple copies of
the field are present, potential privacy issues with
intermediate deliveries, possible implications for SMTP-level
forwarding or redistribution, and so on suggest that this is not
going to be a trivial change to get right.

Speaking both personally and as Editor and because we have so
often found that everything is connected to everything else, I'm
going to resist _any_ additional details or requirements (even
MAY is normative language) in 5321bis absent compelling needed.
But I will, of course, put in whatever the WG specifies.

    john

--On Thursday, December 31, 2020 12:16 -0500 John R Levine
<[email-masked]> wrote:

>> If we take the rules seriously, the moment you do that,
>> existing implementations that don't do that become
>> nonconforming and rfc5321bis goes to Proposed.
> 
> Hmmn.
> 
> It's not registered, which surprised me and is why I'd like to
> put it in 5321bis.  How about if we add it as a MAY ?

---

From: John C Klensin <[email-masked]>
Date: Thu, 31 Dec 2020 13:16:29 -0500

--On Thursday, December 31, 2020 12:26 -0500 John Levine
<[email-masked]> wrote:

>...
>> What's the rationale for leaving alone the existing
>> Delivered-To: headers?  Is this a Trace header which must
>> always be prepended, so folks should always use the first one
>> seen scanning from the top?
> 

If we are going to add it to 5321bis, even as a "MAY", it seems
to me that we need to agree, not just that it is the existing
practice, but that it is a good idea.

Again, I'm not violently opposed to the addition, just concerned
that we not put it in and create loose ends... and that trying
to discuss it not open up cans of worms.

    john

---

From: Ned Freed <[email-masked]>
Date: Thu, 31 Dec 2020 09:53:10 -0800 (PST)

> a long time. I know that Postfix and qmail do.

According to their documentation both qmail and PostFix primarily use
Delivered-To: as a loop prevention mechanism; it's use as a means of providing
information about the RCPT TO address is secondary.

Additionally, we already have a standardized means of delivering this
information: The "for" clause in the Received: field. We also have
language describing the issues it has when delivering to multiple recipients.

I note in passing that it's  not sufficiently useful that we've ever been asked
to generate it. 

> It shows up in examples in RFCs 5293 and 7681.

You might want to look at those examples a little more closely.

The example in RFC 5293, a proposed standard, shows removal of the first
Delivered-To: field when it has a particular value. No context is given, but it
sure looks like is it's being done to prevent bad behavior on the part of
PostFix or qmail. Not exactly a shining example of interoperability...

The example in RFC 7691, an informational RFC, is in a message in "traditional"
- which seems to mean obsolete - format. 

> line when it inserts a Return-Path line, and SHOULD NOT remove existing

How do you propose handling messages delivered to multiple recipients?

What do you propose be done about the additional semantics qmail and Postfix
have for Delivered-to:? Describe those semantics and tell others to implement
them? 

I'm sorry, but it seems to me that Delivered-to: has "hack" written all over
it.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Thu, 31 Dec 2020 10:30:41 -0800 (PST)

> destination.  You could have multiple Delivered To in those cases.

That's specifically the intent - you then check to see if values are
being repeated. If they are you have a loop.

> Return-Path is/could be different than the logic for placing a Delivered-To

Good point. Yes, the rules are indeed different.

> strip the Return-Path that your systems added before redirecting..

It's something submission servers should do. What I haven't seen is submission
servers removing Delivered-to: which TBH surprises me. OTOH, it's one line of
configuration to do it in our server, so it's entirey possible for it to be
widely implemented on our platform without me knowing about it.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Thu, 31 Dec 2020 10:36:08 -0800 (PST)

> folks should always use the first one seen scanning from the top?

It's a loop prevention mechanism, not an informational trace field.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Thu, 31 Dec 2020 10:43:52 -0800

> https://trac.ietf.org/trac/emailcore/ticket/44

We have competing constraints here.  I think there's a solomonesque way 
to navigate this...

1. It is helpful -- and sometimes extremely helpful -- for a message to 
document what address it was delivered to.  Multiple accounts and 
forwarding addresses, can make it unclear what address was used for rcpto.

2. The delivery address is not recorded, at the time of delivery, with 
any reliability.  Nor is there exactly one place used to record it.

    a) SMTP's Received header field parameters (Section 4.4, <Stamp>) 
permits -- but does not require -- use of a FOR clause, with either 
<path> or <mailbox>. Oddly, I am not finding an actual definition of its 
semantics, in the spec, though I often consult that parameter to see 
what the delivery address was.

    b) Some systems use Deliver-To.  Apparently it's not formally 
documented (presumably outside of system software documentation.)

    c) Exim uses  Evenlope-To.

    d) It wouldn't be suprising to find other variants

3. The working group charter does not permit adding new things to SMTP:

      "The limited review is restricted to corrections and clarifications
       only, with a strong emphasis on keeping these minimal and avoiding
       broader changes to terminology or document organization."

    and, as noted, trying to add something puts the goal of full 
standard at risk.

Still...

There seems to be a considerable base of appreciation for the function 
of having a message document what address it was delivered to. (I 
certainly would like it to be more reliably present.)

So I propose the interim step of creating a separate document to specify 
a standard for indicating the delivery address and, separately, getting 
it made Proposed Standard.

If there is support for this, I'm glad to do the documenting grunge.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "John Levine" <[email-masked]>
Date: 31 Dec 2020 14:22:58 -0500

>If there is support for this, I'm glad to do the documenting grunge.

Seems like a reasonable next step. Even if it's a hack, it's a widely
used hack so it would be nice to agree what its name is.

---

From: John C Klensin <[email-masked]>
Date: Thu, 31 Dec 2020 14:39:31 -0500

--On Thursday, December 31, 2020 12:52 -0500 "John R. Levine"
<[email-masked]> wrote:

> Postfix and qmail add it, and have for decades.  Gmail adds
> it.  It's shown up in examples in RFCs.
> 

Once again, while I think that a discussion of this would be
entirely in order in an A/S, if you are convinced that you want
it in 5321bis, I think what is needed is:

(i) An explanation of why this is needed, going beyond "lots of
people are doing it".

(ii) A decision about erratum 4055 (Appendix G.4 and Ticket #30
in Appendix H.1) or a conclusion that this header field is
equally useful without signatures over the headers.

(iii) Agreement about the relationship between this header and
existing trace headers covered in RFC 5321, including questions
of ordering requirements or old header removal.

(iv) A discussion of the relationship among Delivered-To:,
Envelope-to:, and X-Original-to:.  The latter seems popular in
some quarters, often in conjunction with Delivered-to:.  I
suggest the three have different semantics in some popular cases
and, if we are going to put text in 5321bis (or even the A/S)
the semantics need to be spelled out.  In particular, suppose we
have a message that is in transit with 
    RCPT TO:<[email-masked]>
It is handed off to the delivery server with that address,
presumably having "Envelope-to:" added at the same time
"Return-path:" is added.  But suppose that set of delivery
mechanisms (which we have resisted specifying in IETF standards
track documents for 30 or 40 years), encounters a local alias
file that says "tom" is really "dick".  Now, it is clear (at
least to me) that "Envelope-to:" remains unchanged because the
envelope said "[email-masked]".  But "Delivered-to:", if
interpreted according to the obvious meaning of the term, should
have a value of "[email-masked]".  Perhaps (but I don't know)
"X-Original-To:" is a workaround for that problem and has the
same semantics as "Envelope-to:".  

And, of course, if the above is a correct interpretation of how
"Delivered-to:" is expected to behave, it raises two other
questions: Do all of the systems that insert "Delivered-to:"
interpret it the same way, including in the much more unpleasant
case in which, rather than a local alias file, the delivery MTA
encounters a forward file that can explicitly allow the target
to be one or more addresses on different systems?  And is it
really an MTA function of part of internal processing on
delivery servers?  In the latter case, however useful it might
be, it does not belong in 5321bis (although "Envelope-to:"
might).

If those issues are resolved, I hope the resolution will come
with text.

    john

---

From: "John R. Levine" <[email-masked]>
Date: 31 Dec 2020 15:50:19 -0500

> it in 5321bis, I think what is needed is:

On further consideration I think Dave's approach for a separate draft 
makes more sense.

I would like to document Delivered-To so that if people are going to add a 
header like that, they use a consistent name, but it's not worth hanging 
up 5321bis.

Regards,

---

From: John C Klensin <[email-masked]>
Date: Thu, 31 Dec 2020 16:27:53 -0500

--On Thursday, December 31, 2020 15:50 -0500 "John R. Levine"
<[email-masked]> wrote:

>> entirely in order in an A/S, if you are convinced that you
>> want it in 5321bis, I think what is needed is:
> 
> On further consideration I think Dave's approach for a
> separate draft makes more sense.
> 
> I would like to document Delivered-To so that if people are
> going to add a header like that, they use a consistent name,
> but it's not worth hanging up 5321bis.

Agree with both of you.  And, when you do it, please clarify the
semantics as discussed in prior message.

   john