On Mon, Aug 7, 2023, at 10:54 PM, Murray S. Kucherawy wrote:
> On Mon, Aug 7, 2023 at 8:00 PM Emanuel Schorsch
> <emschorsch=40google....@dmarc.ietf.org> wrote:
>> If there are not that many BCC recipients for a message then it is likely
>> not necessary as the duplicate message counting is unlikely to have a
>> negative impact. If there are a large number of BCC recipients for a given
>> message then I think the solutions proposed in Wei's DARA draft are helpful:
>> standardizing the way to indicate BCC/Forwarded-To and signing a separate
>> copy of the message for each BCC recipient so that it can still be verified
>> as direct mail.
>
> Doesn't putting "invisible" recipients into an actual field like Bcc create a
> privacy concern, i.e., they're no longer invisible? You need to hope that
> the agents in the handling chain that are supposed to delete that field will
> actually do it, which presumes the entire deployed base will adopt DARA in a
> reasonable period of time.
According to RFC 5322 it should be handled correctly by "but the recipients on
the "Bcc:" line get a separate copy of the message containing a "Bcc:" line"
The "Bcc:" field (where the "Bcc" means "Blind Carbon Copy") contains
addresses of recipients of the message whose addresses are not to be
revealed to other recipients of the message. There are three ways in
which the "Bcc:" field is used. In the first case, when a message
containing a "Bcc:" field is prepared to be sent, the "Bcc:" line is
removed even though all of the recipients (including those specified
in the "Bcc:" field) are sent a copy of the message. In the second
case, recipients specified in the "To:" and "Cc:" lines each are sent
a copy of the message with the "Bcc:" line removed as above, *but the
recipients on the "Bcc:" line get a separate copy of the message
containing a "Bcc:" line.* (When there are multiple recipient
addresses in the "Bcc:" field, some implementations actually send a
separate copy of the message to each recipient with a "Bcc:"
containing only the address of that particular recipient.) Finally,
since a "Bcc:" field may contain no addresses, a "Bcc:" field can be
sent without any addresses indicating to the recipients that blind
copies were sent to someone. Which method to use with "Bcc:" fields
is implementation dependent, but refer to the "Security
Considerations" section of this document for a discussion of each.
...
Many implementations use the "Bcc:" (blind carbon copy) field,
described in section 3.6.3
<https://datatracker.ietf.org/doc/html/rfc5322#section-3.6.3>, to facilitate
sending messages to
recipients without revealing the addresses of one or more of the
addressees to the other recipients. Mishandling this use of "Bcc:"
may disclose confidential information that could eventually lead to
security problems through knowledge of even the existence of a
particular mail address. For example, if using the first method
described in section 3.6.3
<https://datatracker.ietf.org/doc/html/rfc5322#section-3.6.3>, where the "Bcc:"
line is removed from the
message, blind recipients have no explicit indication that they have
been sent a blind copy, except insofar as their address does not
appear in the header section of a message. Because of this, one of
the blind addressees could potentially send a reply to all of the
shown recipients and accidentally reveal that the message went to the
blind recipient. When the second method from section 3.6.3
<https://datatracker.ietf.org/doc/html/rfc5322#section-3.6.3> is used,
the blind recipient's address appears in the "Bcc:" field of a
separate copy of the message. If the "Bcc:" field sent contains all
of the blind addressees, all of the "Bcc:" recipients will be seen by
each "Bcc:" recipient. Even if a separate message is sent to each
"Bcc:" recipient with only the individual's address, implementations
still need to be careful to process replies to the message as per
section 3.6.3 <https://datatracker.ietf.org/doc/html/rfc5322#section-3.6.3>
so as not to accidentally reveal the blind recipient to
other recipients.
Or maybe Resent-Bcc is more appropriate for situations in which an
intermediary/ESP needs to insert a header
Resent fields SHOULD be added to any message that is reintroduced by
a user into the transport system. A separate set of resent fields
SHOULD be added each time this is done. All of the resent fields
corresponding to a particular resending of the message SHOULD be
grouped together. Each new set of resent fields is prepended to the
message; that is, the most recent set of resent fields appears
earlier in the message. No other fields in the message are changed
when resent fields are added.
Jesse
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
