On Tue, Aug 8, 2023, at 12:55 AM, Murray S. Kucherawy wrote: > On Mon, Aug 7, 2023 at 9:23 PM Jesse Thompson <z...@fastmail.com> wrote: >> __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" >> >> [...] > > As you cited, RFC 5322 describes three ways that the "Bcc" field is typically > used. You're talking about just one of those, and I'm not sure it's the most > common one. In any case, I suggest that "should" is a bit of a leap, > especially given that the choice of which of the three to use is described as > "implementation dependent". > > The second part of your citation confirms the risk to which I was referring.
I don't understand why it's a privacy issue that an individual recipient sees their own address in the Bcc header. Jesse
_______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
