Subject: [Emailcore] Ticket #15: G.7.9. Discussion of 'blind' copies and RCPT

From: Alexey Melnikov <[email-masked]>
Date: Tue, 19 Jan 2021 16:11:45 +0000

Dear collegues,

The 1st pagaraph of Section 7.2 ("Blind" Copies) currently says:

   Addresses that do not appear in the message header section may appear
   in the RCPT commands to an SMTP server for a number of reasons. The
   two most common involve the use of a mailing address as a "list
   exploder" (a single address that resolves into multiple addresses)
   and the appearance of "blind copies". Especially when more than one
   RCPT command is present, and in order to avoid defeating some of the
   purpose of these mechanisms, SMTP clients and servers SHOULD NOT copy
   the full set of RCPT command arguments into the header section,
   either as part of trace header fields or as informational or private-
   extension header fields.

Suggested replacement for the last sentence quoted above (as per 
feedback from Arnt Gulbrandsen):

   When more than one
   RCPT command is present, and in order to avoid defeating some of the
   purpose of these mechanisms, SMTP clients and servers SHOULD NOT copy
   any of RCPT command arguments into the header section,
   either as part of trace header fields or as informational or private-
   extension header fields.

(This removes "especially" and replaces "the full set of" with "any" -- 
copying the first one can be as harmful as copying all of them, at least 
without verifying that the addresses do appear in the headers.)

Please provide feedback on this proposal within 2 weeks.

Best Regards,

Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 19 Jan 2021 16:14:05 +0000

Hi again,

Also, John Klensin asked: May also need to discuss whether that 
terminology is politically incorrect and suggest a replacement.

My reply as a participant:

  I think CC and BCC are well established terms, so changing it now is 
going to cause more harm then good. Besides I don't have any better 
proposal.

Best Regards,

Alexey

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 19 Jan 2021 18:07:28 +0100

On Tue 19/Jan/2021 17:11:45 +0100 Alexey Melnikov wrote:
> Suggested replacement for the last sentence quoted above (as per feedback from 
> Arnt Gulbrandsen):
> 
>    When more than one
> (This removes "especially" and replaces "the full set of" with "any" -- copying 
> the first one can be as harmful as copying all of them, at least without 
> verifying that the addresses do appear in the headers.)
> 

Having removed "especially", we could raise to MUST NOT.  Were there other 
circumstances that would allow violating the SHOULD NOT?

Anyway, this Section deserves a comefrom Section 4.4.  That is, for example:

    For            = CFWS "FOR" FWS ( Path / Mailbox )
                   ; Not if multiple recipients, see Section 7.2

Best
Ale
--

---

From: Jeremy Harris <[email-masked]>
Date: Tue, 19 Jan 2021 17:44:22 +0000

>                    ; Not if multiple recipients, see Section 7.2

Diverging topic, sorry.  Is it strictly needed to shout "FOR" here?

I notice that Exim currently, in its default, uses lower-case "for";
and similar "by", "id" and "with".  This code dates from 1996.
-- 
Cheers,
   Jeremy

---

From: "John Levine" <[email-masked]>
Date: 19 Jan 2021 21:36:27 -0500

>Diverging topic, sorry.  Is it strictly needed to shout "FOR" here?

In ABNF, upper and lower case ASCII have always been equivalent. There
is a recent tweak in RFC 7405 to let you make strings case sensitive,
but that of course doesn't apply to anything in 5321 or 5322.

---

From: "Alexey Melnikov" <[email-masked]>
Date: Fri, 29 Jan 2021 17:12:09 +0000

Hi Alessandro,

On Tue, Jan 19, 2021, at 5:07 PM, Alessandro Vesely wrote:
> Having removed "especially", we could raise to MUST NOT. 

Good point.

> Were there other 

Personally, I can't think of any. I would be fine with MUST NOT.
My question is: would MUST NOT break existing implementations and, if it does, do we (as the WG) care?

>                    ; Not if multiple recipients, see Section 7.2

Sorry, I think I am missing your point here. I don't think the quoted ABNF need to change?

Best Regards,
Alexey

---

From: Dave Crocker <[email-masked]>
Date: Fri, 29 Jan 2021 09:29:06 -0800

> Please provide feedback on this proposal within 2 weeks.

The suggested wording is functionally problematic.

The goal is to prohibit divulging addresses other than the one used to 
delivery to the recipient getting this copy of the mail.  The wording 
should reflect that, rather than making a blanket prohibition of showing 
any address.

Perhaps:

    An address that does not appear in the message content header 
section might appear in a RCPT command to the receiving SMTP server for 
a number of reasons. The two most common involve the use of a mailing 
list address -- a single address that produces automated re-distribution 
to multiple addresses -- and the use of a "blind copies" address. In 
order to avoid address disclosures that are problematic, in terms of 
privacy, any copying of a RCPT command argument into the message header 
section MUST be restricted to only the one used for delivery to the 
recipient getting the specific version of the message that discloses 
that address.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 29 Jan 2021 19:23:21 +0100

> Sorry, I think I am missing your point here. I don't think the quoted ABNF need to change?

Just the "see Section 7.2" part of the comment.

Best
Ale
-- 

The comefrom statement was an ironic proposal after Dijkstra's goto considered 
harmful.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 29 Jan 2021 18:36:32 +0000

I am happy with either wording.

My suggestion might be said to 
reveal/indicate that the message has several recipients at that point, 
whether that is a bug or a feature is a matter of view.

Arnt

---

From: John C Klensin <[email-masked]>
Date: Fri, 29 Jan 2021 16:17:25 -0500

A radical alternative/suggestion at the end (skip there if you
like)...

--On Friday, January 29, 2021 09:29 -0800 Dave Crocker
<[email-masked]> wrote:

>> Suggested replacement for the last sentence quoted above (as
>> per feedback from Arnt Gulbrandsen):
>> 
>>     When more than one
>>     RCPT command is present, and in order to avoid defeating
>>   some of the   purpose of these mechanisms, SMTP clients
>>   and servers SHOULD NOT copy   any of RCPT command
>>   arguments into the header section,   either as part of
>>   trace header fields or as informational or private-  
>>   extension header fields.
>> 
>> (This removes "especially" and replaces "the full set of"
>> with "any" -- copying the first one can be as harmful as
>> copying all of them, at least without verifying that the
>> addresses do appear in the headers.)
>> 
> The goal is to prohibit divulging addresses other than the one
> used to delivery to the recipient getting this copy of the
> mail.  The wording should reflect that, rather than making a
> blanket prohibition of showing any address.
> 
> Perhaps:
> 
>     An address that does not appear in the message content
> header section might appear in a RCPT command to the receiving
> SMTP server for a number of reasons. The two most common
> involve the use of a mailing list address -- a single address
> that produces automated re-distribution to multiple addresses
> -- and the use of a "blind copies" address. In order to avoid
> address disclosures that are problematic, in terms of privacy,
> any copying of a RCPT command argument into the message header
> section MUST be restricted to only the one used for delivery
> to the recipient getting the specific version of the message
> that discloses that address.

Dave and others,

With the understanding that, as editor, I'm quite agnostic about
this and willing to make any changes the WG decides on, so the
following is personal opinion...  

I think your suggestion above is problematic too (and the last
paragraph of Alexey's even more so), partially for reasons you
have identified earlier.

First, since at least RFC 821 and some of the discussions
leading to RFC 1123, we have carefully avoided imposing any
requirement that an MTA (or SMTP sender or receiver) inspect and
evaluate, or even know how to parse, message headers.  The
language about adding trace fields has always been written to
just insert them at the beginning/top of the message content,
message content that (especially before RFC 2821) might well not
contain 822-derived header fields at all.  I am not sure whether
your proposed text requires changing that principle; Alexey's
"at least without verifying" certainly does.  If whatever we
decide to do does make that change, we should all understand
that is a big step.  And, if it doesn't, I think text that is
extremely clear about that would be helpful.

Second, while we use terms like "final delivery system" (or
"server") frequently, including in the text of 5321, we need to
keep in mind that there are a collection of cases (and
implementation designs for conforming SMTP servers) for which
that is ultimately handwaving.  In some cases, unless special
efforts have been made to preserve all (or all relevant) RCPT
information, by the time the system knows what should go into
"FOR" under the above description (or either of the prior ones)
is long gone.  That definition is, of course, further
complicated when the SMTP server turns out to be a gateway or is
handing the message off (possibly still with multiple recipients
on the same host) to some sort of mail store manager.

We should also remember that the main purpose of carrying trace
information forward at all has historically been to facilitate
understanding of what went wrong, caused delays, etc.   (And, in
the nastier world we face today relative to 1986, to allow some
crude post-delivery judgments of likely authenticity.)  From
that standpoint, in the overwhelming number of cases the final
recipient won't need the FOR clause to tell her who she is: she
probably already knows that and all three of these suggestions
seem intended to assure that nothing else ends up in that field.

Worth noting too that, if I pass an address of
"[email-masked]" or just "bozo" off to a Submission server and
it transforms it into "[email-masked]" but puts "bozo"
into a FOR clause before sending the message along with that
single RCPT field, another type of privacy problem has occurred.
And, especially in practice, that is not the only place one-one
substitutions can occur.

So, that radical suggestion,...

Given that sloppy use of "FOR" can disclose information that
might be private, that the syntax and applicability for FOR has
never been defined when multiple RCPT commands are present, and
that any steps we might take to improve privacy in conjunction
with that clause reduce its utility, why not just deprecate the
use of the thing?   Saying "SHOULD NOT put these things in but
MUST NOT choke if one is encountered" is entirely consistent
with the rules for going to full standard if a feature has
turned out to be bad news.   Maybe an exception is needed and
would be helpful for Submission Servers or first-hop SMTP
processors but they presumably are able to know what is actually
intended.  Or not.

That would not necessarily eliminate the need for some version
of Arnt's text via-a-vis private or additional information
header fields.

I am _not_ completely convinced that deprecating FOR is a good
idea, only that it would considerably simplify this discussion
and the specification if we decided it was wise and hence that
the question should be asked.

best,
   john

---

From: John C Klensin <[email-masked]>
Date: Fri, 29 Jan 2021 16:19:29 -0500

--On Tuesday, January 19, 2021 16:14 +0000 Alexey Melnikov
<[email-masked]> wrote:

> Hi again,
> 
> Also, John Klensin asked: May also need to discuss whether
> that terminology is politically incorrect and suggest a
> replacement.
> 
>   I think CC and BCC are well established terms, so changing
> it now is going to cause more harm then good. Besides I don't
> have any better proposal.

Agreed.  Just felt obligated to raise the issue so that, in
particular, if someone else raises it on Last Call or later, you
and Todd could truthfully say that the WG had examined the
question.

  john

---

From: Dave Crocker <[email-masked]>
Date: Fri, 29 Jan 2021 17:09:15 -0800

> evaluate, or even know how to parse, message headers.  The

The issue, here, is not about parsing header fields.  It is about 
generating them.  And RFC 821 specifies creation of some header fields.

This also is about delivery, which is when FOR get created.

But since you raised it...

Actually, this highlights why the SMTP specification should not deal 
with delivery issues, per se, and should leave that to an MDA 
specification.  The SMTP specification gets a lot simpler if it stops 
trying to cover the entire range of end-to-end handling issues and just 
sticks to what it is actually used for.  Delivery has gotten far more 
complex than this specification does or can deal with.

> extremely clear about that would be helpful.

The 'FOR' clause gets into the delivery assessment issue.

Since it's part of the Received specification, which does apply to 
normal relaying, perhaps just say that there must be no more than one 
For clause and it contains only one address.  The physics of that will 
adequately constrain its use.

> that is ultimately handwaving. 

Indeed it is.

  In some cases, unless special
> on the same host) to some sort of mail store manager.

SMTP has nothing at all to do with gateway functionality.  Zero.

Trying to touch that topic, in a mail relaying protocol specification, 
is a problematic distraction.  Especially given how irrelevant and 
incomplete the text is to actual gatewaying behavior.

> recipient won't need the FOR clause to tell her who she is: she

I suspect it's not because of my gender, but I frequently look for the 
FOR clause.  I get mail under a variety of different addresses.  As do 
many others.  So excluding that utility is problematic.

> And, especially in practice, that is not the only place one-one

I don't understand how the above paragraph is relevant to the SMTP 
specification.  Mixing submission with discussion of the FOR clause 
makes no sense to me.

In any event, I also don't understand what privacy problem is being claimed.

> Given that sloppy use of "FOR" can disclose information that

The 'given' has not been clearly established here.  So the premise needs 
some work.

> use of the thing? 

Because it is used and it is useful.

d/

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 31 Jan 2021 13:40:55 +0100

On Sat 30/Jan/2021 02:09:15 +0100 Dave Crocker wrote:
>> "at least without verifying" certainly does.

That was descriptive text for the list, not proposed text for the I-D.

The proposed text was:

     When more than one

It seems precise enough.  Deriving that there might be "informational or 
private-extension" fields which are not trace fields is not fully correct, 
since the "or" can be inclusive.

IMHO, that SHOULD NOT can be promoted to MUST NOT.

>> If whatever we decide to do does make that change, we should all
>> understand that is a big step.  And, if it doesn't, I think text that is 
>> extremely clear about that would be helpful. >
> Since it's part of the Received specification, which does apply to normal 
> relaying, perhaps just say that there must be no more than one For clause and 
> it contains only one address.  The physics of that will adequately constrain 
> its use.

I disagree.  Uniqueness of FOR doesn't imply uniqueness of RCPT.  The original 
alternative text had the same problem:

     any copying of a RCPT command argument into the message header section
     MUST be restricted to only the one used for delivery to the recipient
     getting the specific version of the message that discloses that address.

It requires too much salt to derive that "to only the one" means that a single 
RCPT command is present in the envelope.

>> In some cases, unless special efforts have been made to preserve all (or
>> all relevant) RCPT information, by the time the system knows what should
>> go into "FOR" under the above description (or either of the prior ones) is
>> long gone.

I don't get this.  The trace header is written during the SMTP transaction, 
isn't it?

>> [...]
> I suspect it's not because of my gender, but I frequently look for the FOR 
> clause.  I get mail under a variety of different addresses.  As do many 
> others.  So excluding that utility is problematic.

+1, although Delivered-To: is better at recovering the original target.

>> Worth noting too that, if I pass an address of "[email-masked]" or just
>> "bozo" off to a Submission server and it transforms it into
>> "[email-masked]" but puts "bozo" into a FOR clause before
>> sending the message along with that single RCPT field, another type of
>> privacy problem has occurred. And, especially in practice, that is not the
>> only place one-one substitutions can occur.

Aliases at the MSA are quite rare.  That kind of mechanism is more often used 
(for lists of recipients) at the MUA.  Since SMTP does not specify that, we can 
ignore its possible nasty effects.

> The 'given' has not been clearly established here.  So the premise needs some 
> work.
> 
> 

Agreed.  Clarifying that it is only allowed in the presence of a single RCPT 
command is enough.

Best
Ale
--