Bcc, throw-keyids, and metadata hiding [was: Re: Announcing Astroid v0.11]

[Daniel Kahn Gillmor]

On Sun 2018-02-04 16:18:02 -0500, Daniel Kahn Gillmor wrote:
> Well, i guess you could limit it to two copies total: one copy is to all
> Bcc'ed recipients, and one copy to all non-Bcc'ed recipients.  you'd
> want to make sure that you got the same Message-ID on each generated
> copy, of course.
>
> That avoids even the count of the Bcc recipients going out to the
> non-bcc folks, too, which is a nice outcome.

Hm, let me clarify: this only results in 2 copies total if either (a)
there is only one Bcc recipient, or (b) you actually do throw-keyids on
the Bcc'ed version, which results in the same pain for the folks
receiving the Bcc.

To avoid (b), you could do one copy of the message per Bcc'ed address,
and never throw keyids at all.

This isn't an extra metadata leak, because the bcc'ed person's e-mail
address will be put in the SMTP envelope (and, likely, in Delivered-To or
other equivalent headers appended by the MTA).

So it's N + 1 copies of the message, where N is the number of Bcc'ed
individuals.  This also removes any leak of the number of Bcc'ed
individuals from the Bcc'ed message.

i think it might be the most principled approach to metadata hiding, and
it also minimizes the pain on the receiver side.

If we ever end up with an e-mail transport that doesn't leak this
recipient metadata, then it might be worth revisiting the "throw-keyids"
situation.  but for now, it seems like the best approach really is to
have the MUA handle multiple message generation.

what do you think?

    --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20180204/8d0f2c1f/attachment.sig>