Subject: [Emailcore] RCPT commands, BCCs, and the "for" clause

From: John C Klensin <[email-masked]>
Date: Tue, 22 Mar 2022 09:22:35 -0400

Hi.

I have been thinking about these (very connected, IMO) issues,
partially in conjunction with some side conversations.   My
first conclusion is that they really are one basic issue and
that trying to discuss them separately is just confusing us and
that previous versions of that confusion may have created a hole
in which we are continuing to dig.

The second conclusion is that RFC 5321 says rather more about
these topics than it should and that we are trying to fix the
issues that text causes by adding more text and risking even
more confusion (in other words, trying to get out of the hole by
digging deeper). With the understanding that none of the ideas
below are new except for the organization and context, my
current hunch is that 5321bis should:

(i) Remind people that a conforming SMTP server or
(non-submission) client doesn't look at header fields, much less
start performing heuristics on them, and hence does not have a
clue as to which RCPT commands (or their arguments) are
associated with "To:", "Cc:", or "Bcc:" header fields.  Section
7.8 provides a loophole for, e.g., malware resistance measures,
but does not change the principle.

(ii) Mention that no attempt should be made to include "for" in
a "Received:" header field if there is more than one RCPT
command present, noting that this is forbidden by the syntax
anyway.

(iii) Clarify the text that mentions that "for" can cause
unintended privacy disclosures and say that, if one is not sure
of the appropriateness of the clause and the information that
should go into it, it is generally better to just omit the
clause.

(iv) Mention as well that _any_ trace field might, under the
wrong set of circumstances, disclose information that someone
might consider sensitive and that, while those fields are often
essential for debugging messages that have run into transport
problems and may even be helpful in distinguishing spoofed or
otherwise problematic messages from more desirable traffic (and
even identifying the source of such bad traffic), complete
protection of anything that might be considered private would
argue for eliminating trace information entirely.

Wordsmithing and some decisions about where to use 2119/8174
language obviously needed, but I'm hoping we can agree on the
above or something like it as general principles.

We then get rid of all of the hair-splitting about internal
names and addresses on LANs, which addresses should be included
in "for" clauses and which ones avoided, etc.  If someone
believes they can persuade the WG that it is worth doing the
case analysis and offering more specific advice in the A/S they
should certainly try (and be ready to write text).  But, as far
as 5321bis is concerned, my recommendation is that we
concentrate on the above four points and tear everything else
out.  That would, IMO, improve clarity and and shorten 5321bis
by a few pages.

   --john

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 22 Mar 2022 15:08:50 +0100

Hi John,
(Replying as a WG participant)

> On 22 Mar 2022, at 14:22, John C Klensin <[email-masked]> wrote:
> 
> Hi.
> 

I think this statement is stronger than currently specified in the draft and is not something I agree. If a message has 2 RCPT TO recipients A and B (let’s assume for simplicity that A and B are end user email addresses, not mailing lists), I think it is perfectly ok to do either:

1) The same message with Received with no FOR is delivered to both A and B

 or

2) Recipient A receives a copy of the message with Received with FOR A, while recipient B receives a copy of the message with Received with FOR B.

Your statement (ii) prevents choice 2)
> should go into it, it is generally better to just omit the
Agreed.
> argue for eliminating trace information entirely.

Agreed.

> out.  That would, IMO, improve clarity and and shorten 5321bis

I am personally Ok with this direction, but I think I would like to see the new proposed text before fully committing to it. Is it something you can post to the mailing list before Friday or at least soon-ish?

Thank you,
Alexey
> 
>   --john
> 
> -- 
> Emailcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emailcore

---

From: John C Klensin <[email-masked]>
Date: Fri, 25 Mar 2022 00:49:57 -0400

>> more confusion (in other words, trying to get out of the hole
>> by digging deeper). With the understanding that none of the
>> ideas below are new except for the organization and context,
>> my current hunch is that 5321bis should:
>> 
>> (non-submission) client doesn't look at header fields, much
>> less start performing heuristics on them, and hence does not
>> have a clue as to which RCPT commands (or their arguments) are
>> associated with "To:", "Cc:", or "Bcc:" header fields.
>> Section 7.8 provides a loophole for, e.g., malware resistance
>> measures, but does not change the principle.
>> 
>> (ii) Mention that no attempt should be made to include "for"
>> in a "Received:" header field if there is more than one RCPT
> I think this statement is stronger than currently specified in
> the draft and is not something I agree. If a message has 2
> RCPT TO recipients A and B (let's assume for simplicity that
> A and B are end user email addresses, not mailing lists), I
> think it is perfectly ok to do either:
> 
> 2) Recipient A receives a copy of the message with Received
> with FOR A, while recipient B receives a copy of the message
> with Received with FOR B.
> 

I think we are thinking about different parts of the relay
chain.  For the server that is inserting a "Received:" header
just before making final delivery, you are absolutely correct.
The "for" clause of that trace field is, I think, also fairly
useless unless some post-delivery process makes changes to the
recipient address.  However, assume DNS records that look like

   example1.com.   MX 5 relay1.example.
   example1.com.   MX 2 relay2.example.
   example1.com.   MX 0 deliveryServer1.example1.com.
   example2.com.   MX 5 relay1.example.
   example2.com.   MX 0 deliveryServer2.example2.com.

Also assume the message in question leaves the MSA with
    RCPT TO:<[email-masked]>
    RCPT TO:<[email-masked]>
    RCPT TO:<[email-masked]>

Now, assuming the two deliveryServers and relay2 are not
answering when the MSA asks and that the MSA does not decide to
send three separate messages on principle, relay1 gets a single
mail transaction with the RCPT commands above.    So, question 1
is what, if any, it puts in the "for" clause of the trace field
it adds given that it has three possible target mailbox
addresses?  Statement (ii) above says "no for clause" but I'm
listening for other options that clarify RFC 5321 rather than
making substantive changes.

Now, it (relay1) notices that the message contains domains with
two different next-hop MX preferences (again assuming that
deliveryServer1 is not being responsive).  It opens a connection
to relay2 with a mail transaction specifying 
 
    RCPT TO:<[email-masked]>
    RCPT TO:<[email-masked]> 

Question 2 is what relay2 puts in the "for" clause of the trace
field it generates.  It still has a choice of two addresses and,
as far as it is concerned, it is delivering one message to both.
It opens a mail transaction to deliveryServer1, which, assuming
it actually delivers separately to the two mailboxes (your
case), generates a trace header for each that differs only in
the "for" clause.  FWIW, if deliveryServer1 hands off to a
separate MDA (a distinction RFC 5321 does not recognize) that
splits the messages up on a per-mailbox basis and deposits them
in the mail store (something else 5321 at best hand waves
about), it has the same problem as relay2 and cannot split the
"for" clauses either.

deliveryServer2 of course has it easier.  It gets only one
recipient from relay1, [email-masked], puts that in the
"for" clause in the trace field it generates, and delivers the
message to that mailbox.

And, of course, if there were any way for relay1 to write a
"for" clause with more than one RCPT command, tom, dick, and
harry would all find out about the others unless the respective
delivery servers edited those additional "for" subclauses out.
5321 forbids both multiple addresses per "for" clause and
editing of trace fields by servers later in the chain, so that
is, fortunately, a non-issue.

So, my statement of the options (I did say "hunch" and not
"conclusion" :-)) was clearly not correct and is in need of
fixing (at least).  On the other hand, your choice 2 is possible
only for the MTA that splits multiple-recipient messages into
individual ones, presumably for delivery.

>> unintended privacy disclosures and say that, if one is not
>> sure of the appropriateness of the clause and the information
>> that should go into it, it is generally better to just omit
>> the clause.

>> might consider sensitive and that, while those fields are
>> often essential for debugging messages that have run into
>> transport problems and may even be helpful in distinguishing
>> spoofed or otherwise problematic messages from more desirable
>> traffic (and even identifying the source of such bad
>> traffic), complete protection of anything that might be
>> considered private would argue for eliminating trace
>> information entirely.

>> names and addresses on LANs, which addresses should be
>> included in "for" clauses and which ones avoided, etc.  If
>> someone believes they can persuade the WG that it is worth
>> doing the case analysis and offering more specific advice in
>> the A/S they should certainly try (and be ready to write
>> text).  But, as far as 5321bis is concerned, my
>> recommendation is that we concentrate on the above four
>> points and tear everything else out.  That would, IMO,
>> improve clarity and and shorten 5321bis by a few pages.
 
> I am personally Ok with this direction, but I think I would
> like to see the new proposed text before fully committing to
> it. Is it something you can post to the mailing list before
> Friday or at least soon-ish?

Obviously, no, since it is Friday already (busy week).  Up to
you, in your chair capacity, to decide whether we should discuss
in circa seven hours or just defer the whole topic for the
mailing list.  My personal preference would be to see if we can
get general agreement on the approach and then sort text out on
the mailing list but, again, up to you.

best,
   john