Subject: [Emailcore] Post-Interim question about Section 3.4.2 of draft-ietf-emailcore-rfc5321bis-08

From: John C Klensin <[email-masked]>
Date: Fri, 21 Jan 2022 23:17:28 -0500

Hi.

During Friday's interim meeting, a decision was made (associated
with Ticket #4) to drop the last sentence of the first paragraph
of Section 3.4.2, which reads (in -08):

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

Checking back over my notes, that sentence appeared in RFC 2821.
Checking further, the decision in DRUMS to put it in was
apparently based on real-world confusion as to whether a change
in the reverse-path was required to be reflected in the mail
headers.  

So, IMO, we should remove that text iff people are convinced
that potential for confusion has vanished in the last 20 years.
Otherwise, it should be retained in some form.

So this is a request for mailing list discussion on that
specific topic before I take the conclusion of the Interim as
definitive and change the text.

thanks,
   john

---

From: "John Levine" <[email-masked]>
Date: 21 Jan 2022 23:29:49 -0500

>in the reverse-path was required to be reflected in the mail

If people still think that the bounce address has to match the From header,
we've got worse problems than this sentence.

For the list-id issue, I suppose we could say that existing message headers
are left unchanged, implying that if you want to add new ones, you can.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Sat, 22 Jan 2022 00:47:26 -0500

--On Friday, January 21, 2022 23:29 -0500 John Levine
<[email-masked]> wrote:

>> During Friday's interim meeting, a decision was made
>> (associated with Ticket #4) to drop the last sentence of the
>> first paragraph of Section 3.4.2, which reads (in -08):
>> 
>> Checking back over my notes, that sentence appeared in RFC
>> 2821. Checking further, the decision in DRUMS to put it in was
>> apparently based on real-world confusion as to whether a
>> change in the reverse-path was required to be reflected in
>> the mail headers.  
> 
> If people still think that the bounce address has to match the
> From header, we've got worse problems than this sentence.

Agreed.  But I think we have worse problems than that sentence
even without that condition, so I am trying to be careful and
ask.

> For the list-id issue, I suppose we could say that existing
> message headers are left unchanged, implying that if you want
> to add new ones, you can.

That was the case I was concerned about and (as an individual) I
like your suggestion for how to handle it.  

Others?
   thanks,
     john

---

From: "John R Levine" <[email-masked]>
Date: 22 Jan 2022 10:22:16 -0500

> like your suggestion for how to handle it.

As a general rule, it seems to me that if you're rewriting headers, you're 
doing submission, which is fine but it's not SMTP.

We might put something in the A/S along the lines of the point of the 
bounce address is send failure notifications to someone who can do 
something about it.  When an MTA changes the destination address, 
the decision whether to change the bounce address is an administrative 
one, not a technical one, to get the bounces to the appropriate party,

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

---

From: Dave Crocker <[email-masked]>
Date: Sat, 22 Jan 2022 10:39:55 -0800

> As a general rule, it seems to me that if you're rewriting headers, 
> you're doing submission, which is fine but it's not SMTP.
> 
> something about it.  When an MTA changes the destination address, the 
> decision whether to change the bounce address is an administrative one, 
> not a technical one, to get the bounces to the appropriate party,

+1

This probably aids the distinction between 'protocol spec' and 'service 
spec', where a service is one or more protocols and the relevant 
operational guidance.  An A/S seems more in line with a role as service 
specification.  Yes?

SMTP is only a component of an email service.  So it is problematic to 
have it give guidance about activities beyond its scope.  (That the 
protocol/service conflation dates back to RFC 821 doesn't change the 
nature of the issue, just makes its genesis more understandable and, 
arguably, excusable.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net