Subject: [ietf-smtp] Delivered-to and Return-path

From: John C Klensin <[email-masked]>
Date: Thu, 18 Feb 2021 00:55:26 -0500

If I correctly understand the intended use of Delivered-to and
the meaning of "added at the time of delivery", I believe that
the examples in Section 4 are in error.   The example does not
show a Return-path and I'm having trouble figuring out a case in
which the Delivered-to header field could be added before the
SMTP processor made whatever it would think of a final delivery
and inserted the Return-path.

If that analysis is correct, it appears to me that the examples
can be easily corrected by adding Return-path: header fields,
presumably below the top Delivered-to: one. 

If not, some explanation may be in order in Section 5 that I'm
not finding there.

Also, I believe, after reading through this document (at -00)
several times, reading the diffs and then -01, that the meaning
of "final delivery" in its text is different from that in RFC
5321 and 5321bis.   If that is correct, it seems to me to be
worthwhile to be explicit about the difference in this document,
not to simply point to another document and assume the reader
will figure out it.

thanks,
   john

---

From: Sam Varshavchik <[email-masked]>
Date: Thu, 18 Feb 2021 07:09:42 -0500

> and inserted the Return-path.

Return-Path: and Delivered-To: are traditionally added by the MDA, both.  
Even though MTA is handing off a message to the MDA for what the MTA thinks  
is the final disposition, the MDA has the final word on that. This is  
because MDA-managed forwarding comes into play, think about classic  
procmail's forwarding rules.

Return-Path: predates Delivered-To: and I have a dim recollection of stuff  
that expected to see Return-Path: as the first line in a message in  
mailboxes.

So, when Delivered-To: entered the picture: to preserve this dependency the  
MDA adds Delivered-To: after Return-Path:.

---

From: "John Levine" <[email-masked]>
Date: 18 Feb 2021 11:28:21 -0500

In article <3073462D484914E07B452E20@PSB> you write:
>the examples in Section 4 are in error. ...

The examples show long standing practice so if they disagree with the
text, the text is wrong.

It is quite common for an MTA to add Delivered-To headers as an
address is internally rewritten or forwarded without also adding a
Return-Path.  I've sent a few examples of MTAs doing that.

This is of course completely consistent with it being a trace header.

As far as loop detection, again, that's existing practice. We can
describe it, without offering advice on what we think the best loop
breaking techniques are. The MTAs that add Delivered-To also count
Received headers since there are plenty of loops that Delivered-To
doesn't catch.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Fri, 19 Feb 2021 19:36:35 -0800

> show a Return-path and I'm having trouble figuring out a case in

You appear to be adding a requirement for the example to be exhaustively 
complete.

That isn't claimed or intended in the current example text. It merely 
seeks to show a sequence of Delivered-To fields, with a bit more context.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: John C Klensin <[email-masked]>
Date: Fri, 19 Feb 2021 23:27:35 -0500

> You appear to be adding a requirement for the example to be
> exhaustively complete.

No.  I am just suggesting that, given the obvious relationship
between one as a forward pointer and the other as a backward
pointer, both assigned at or after the time SMTP hands the
message off to something other than another SMTP server (acting
as such), an example that shows "Return-path:" as well as
"Delivered-to:" and "Received:" would be a bit more clear and
helpful.   Please note "suggesting" in the previous sentence,
which I do not believe to be a synonym for "a requirement".

> That isn't claimed or intended in the current example text. It
> merely seeks to show a sequence of Delivered-To fields, with a
> bit more context.

Then, as an alternative to the suggestion above, I would suggest
a sentence somewhere that makes it explicit that the examples
show only those header fields that are relevant to what you are
illustrating.

Dave, I am not the enemy.  Given that the header field is
already implemented and deployed, I favor having a spec go
forward that provides implementation and interpretation
guidance.  I am just trying to constructively point out a place
where the document might be made more clear for the benefit of
those who do not already understand how the field is used and
who are looking for implementation guidance.

     john

---

From: Dave Crocker <[email-masked]>
Date: Sat, 20 Feb 2021 10:23:25 -0800

> pointer, both assigned at or after the time SMTP hands the

Noting an abstract connection does not mean there is a practical one.

The current draft provides information that is necessary and sufficient 
for understanding and using the field.

If you think otherwise, please explain carefully, since I think there is 
no other indication of technical problems with the draft.

The example provides sufficient tutorial context to make the 
understanding and use concrete and accurate, as far as I can tell. And I 
believe that no one else is expressing a concern, so far.

As for possible interactions with other fields, again, the instructions 
in the specific are quite simple and pointed.  And sufficient.

Introducing commentary about secondary issues invites readers to be 
confused or to debate matters.  Absent normative import -- and 
especially absent demonstrated implementation or operational issues -- 
adding such material mostly has downsides.  At best, it's simply 
extraneous and ignored.

To the extent that discussion about broader issues with header field 
creation or use is needed, such material is suited to a broader, 
systems-oriented document.

d/

---

From: "John Levine" <[email-masked]>
Date: 20 Feb 2021 13:27:41 -0500

>which I do not believe to be a synonym for "a requirement".

If I may repeat myself, that is NOT existing practice.

I was under the impression that the point of this draft was to document
the way that MTAs have used Delivered-To for over 20 years, as a trace header
that shows a message's progress through the MTA's (and sometimes MDA's) process.

Unfortunately, it is increasingly clear that is not the point of this draft.  I do
not know what the point actually is, but it would be absurd for us to write a spec
that creates a Delivered-To header that is unlike the one that already exists.

It is time for us to abandon this draft. It is so far in the weeds it can never escape.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Sat, 20 Feb 2021 10:43:35 -0800

> It is time for us to abandon this draft. It is so far in the weeds it can never escape.

John,

 From reviewing your postings about the draft, I do not see any 
expressions of concern or suggestions for change, other than about the 
trace field reference.

If you believe there are other technical, operational, or documentation 
problems with the draft that have placed it 'so far in the weeds', I've 
no idea what they are.

Please explain.

d/