Subject: [Emailcore] Ticket #7: Better definition for trace header fields (rfc5321bis changes only)

From: Alexey Melnikov <[email-masked]>
Date: Mon, 4 Oct 2021 16:33:42 +0100

Hi John,

Below I am summarizing proposed changed to 5321bis to address ticket #7. 
The changes only address trace header fields and other tickets remain 
unaffected.

1) Move the current content of Section 4.4 into Section 4.4.1. Rename it 
to be "Receive header field" (or similar).

2) Add the following paragraph to the now empty (other than the new 
subsection) 4.4:

   Trace information is used to provide an audit trail of message handling.
   In addition, it indicates a route back to the sender of the message.

3) In Section 2.3.10, 1st paragraph, last sentence:

    A "relay" SMTP
    system (usually referred to just as a "relay") receives mail from an
    SMTP client and transmits it, without modification to the message
    data other than adding trace information

Insert cross reference to section 4.4 here.

    , to another SMTP server for
    further relaying or for delivery.

4) In Section 3.6.3 (Message Submission Servers as Relays), last paragraph:

    As discussed in Section 6.4, a relay SMTP has no need to inspect or
    act upon the header section or body of the message data and MUST NOT
    do so except to add its own "Received:" header field (Section 4.4)

Change "Section 4.4" to "Section 4.4.1". Also add "and possibly other 
trace header fields" after it.

    and, optionally, to attempt to detect looping in the mail system (see
    Section 6.3).  Of course, this prohibition also applies to any
    modifications of these header fields or text (see also Section 7.9).

5) In Section 7.6:

    In some circumstances, such as when mail originates from within a LAN
    whose hosts are not directly on the public Internet, trace
    ("Received") header fields produced in conformance with this

Insert "e.g." before "Received".

    specification may disclose host names and similar information that
    would not normally be available.  This ordinarily does not pose a
    problem, but sites with special concerns about name disclosure should
    be aware of it.  Also, the optional FOR clause should be supplied
    with caution or not at all when multiple recipients are involved lest
    it inadvertently disclose the identities of "blind copy" recipients
    to others.

Best Regards,

Alexey

---

From: John C Klensin <[email-masked]>
Date: Fri, 22 Oct 2021 18:13:20 -0400

Alexey,

Thanks and sorry for the long delay in getting back to this.

I have tried to implement this as I think you intended, but I
don't think part of it works.  See below.

--On Monday, October 4, 2021 16:33 +0100 Alexey Melnikov
<[email-masked]> wrote:

> Hi John,
> 
> Below I am summarizing proposed changed to 5321bis to address
> ticket #7. The changes only address trace header fields and
> other tickets remain unaffected.
> 
> 1) Move the current content of Section 4.4 into Section 4.4.1.
> Rename it to be "Receive header field" (or similar).
> 
> 2) Add the following paragraph to the now empty (other than
> the new subsection) 4.4:
> 

Ok, but this leaves a subsection 4.4.1 without a 4.4.2.  I
object to that editorially and the RFC Editor usually objects to
it as well.  Do we need at least a stub 4.4.2 for "Return-path:"
which would solve that editorial problem?  Or, IMO less
attractively, we could make the new paragraph 4.4.1 and the
Received text 4.4.2.

> Insert cross reference to section 4.4 here.

Done.

> Change "Section 4.4" to "Section 4.4.1". Also add "and
> possibly other trace header fields" after it.

Done.  If the "Received" subsection becomes 4.4.2 as in the
not-preferred solution about, this will auto-correct.
 
> Insert "e.g." before "Received".

Done.

>     it inadvertently disclose the identities of "blind copy"

One comment, just to be sure we are all on the same page.  The
text, especially with these changes, makes substantially any
relay (there might be exception, but I can't think of one) that
goes into the anti-spam or anti-malware business on the basis of
headers or content -- even noticing DKIM/SPF/DMARC failures and
rejecting or bouncing a message on that basis -- non-conforming
unless it relies entirely on the "operational necessity"
provisions.  Otherwise, we intend to only allow such filtering
behavior in, or prior to, the submission server and after what
SMTP believes is final delivery (i.e., within the vaguely
defined administrative domain of the recipient.   I can life
with that but, if others are going to object, it would be good
to hear from them RSN rather than much later.

best,
   john

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 25 Oct 2021 18:12:19 +0100

Hi John,

On 22/10/2021 23:13, John C Klensin wrote:
> it as well.
I had several RFCs published with a single subsection, so I personally 
don't see this as an issue.
> Do we need at least a stub 4.4.2 for "Return-path:"
That would also be acceptable to me, but what you've done in -05 looks 
very reasonable as well.
> not-preferred solution about, this will auto-correct.
Sure.
>>      it inadvertently disclose the identities of "blind copy"

As far as I am concerned, you resolved ticket #7 for rfc5321bis.

Best Regards,

Alexey