G.21. Appendix B and Message Submission

[aamelnikov]

John Klensin wrote:

Appendix B was written long ago and does not distinguish very
carefully from the case where an MSA is involved from direct MUA-MTA
communications. On the other hand, the situation it describes cannot
arise with a conforming message submission system. Should it be
rewritten and, if so, how much?

[aamelnikov]

Alexey Melnikov wrote:

I think the text needs to be updated to say "MSA" instead
of "MTA", and maybe to do other tweaks.

I think the text is useful, because this is pretty much
what every MUA is doing. My Web Mail server (acting as MUA)
certainly does this.

[aamelnikov]

John Levine and Ken Murchison volunteered to double check the text.

Proposed to close this with "no change" in 2 weeks (March 21st 2023), unless some objections received.

[aamelnikov]

In https://mailarchive.ietf.org/arch/msg/emailcore/kgmqJV7CcxTrxZbJxqZAh8I-2PU/ Ken Murchison suggested:

I just read the text in -18 and I am fine with most of it, but I wonder
if we want/need to reference 5322bis, Section 3.6.3 when discussing
handling of Bcc. The reason being is that I was initially taken aback
by these two sentences:

Any BCC header fields SHOULD then be removed from the header section.
Once this process is completed, the remaining header fields SHOULD be
checked to verify that at least one TO, CC, or BCC header field remains.

Without the context that 5322bis provides regarding how blind carbon
copies could be generated, it seems strange to say that all Bcc header
fields should be removed and then immediately afterward say to make sure
that one or more of To/Cc/Bcc still exists..