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

From: John C Klensin <[email-masked]>
Date: Sat, 05 Mar 2022 21:20:31 -0500

--On Thursday, February 17, 2022 14:25 +0000 Alexey Melnikov
<[email-masked]> wrote:

> Hi John/John,
> 
> On Sat, Jan 22, 2022, at 5:47 AM, John C Klensin wrote:
>> --On Friday, January 21, 2022 23:29 -0500 John Levine
>> <[email-masked]> wrote:
>> 
>>> It appears that John C Klensin  <[email-masked]> said:
>>>> 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.  
>>> 
>>> 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?
> 
> I still think that the replacement text proposed at the
> interim is better than taking this sentence out, but I am
> happy with either:
> 
>   This change to MAIL FROM doesn't affect the header section
> of the message.

It seems to me that, after the interim and the subsequent
discussion, we have multiple options.  In no particular order:

(1) Leave the RFC 5321 text (in Section 3.9 there and Section
3.4.2 of 5321bis-10 (forthcoming) unchanged.  In the latter,
that sentence reads:

	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.

(2) Remove that sentence and replace it with nothing.

(3) Replace that sentence with 

	This change to MAIL FROM doesn't affect the header
	section of the message.

(4) Replace the sentence with something like

	This change to MAIL FROM does not affect any header that
	is already present in the message.

For the last two options, I'm not sure whether we are agreed on
the descriptive "does not" or if we intend a normative MUST or
SHOULD.

I've added a note to the working copy of -10 flagging this.

Alexey, please see my separate comments about untangling the
tickets that interact with that Section.

best,
   john

---

From: "Alexey Melnikov" <[email-masked]>
Date: Mon, 07 Mar 2022 10:52:56 +0000

Hi John,

Replying below as a participant:

> 	is already present in the message.

Did you mean "header" or "header field"?

> the descriptive "does not" or if we intend a normative MUST or

Either of the last 2 work for me. I don't think we need normative language in either case.

> tickets that interact with that Section.

Best Regards,
Alexey

---

From: John C Klensin <[email-masked]>
Date: Mon, 07 Mar 2022 13:56:37 -0500

--On Monday, March 7, 2022 10:52 +0000 Alexey Melnikov
<[email-masked]> wrote:

>...

> Did you mean "header" or "header field"?

"Header field".  I should not compose messages at 2AM.

>> For the last two options, I'm not sure whether we are agreed
>> on the descriptive "does not" or if we intend a normative
>> MUST or SHOULD.
> 

Concur.  Anyone who has a strong preference, or who wants to
argue for either of the first two, should speak up.  Otherwise,
I will likely use (4) because, as John Levine suggested, (3)
could be read as prohibiting adding additional header fields.
I'm not sure that is an important case, but there is no reason
to leave confusion about whether it would be prohibited or not.

>> I've added a note to the working copy of -10 flagging this.

Barring more interruptions, -10 should be posted with the hour.

thanks,
   john