Bcc, throw-keyids, and metadata hiding [was: Re: Announcing Astroid v0.11]
Gaute Hope
eg at gaute.vetsj.com
Sun Feb 4 23:33:36 PST 2018
Daniel Kahn Gillmor writes on februar 5, 2018 2:21:
> 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.
> 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.
Yes; this seems like the ultimate approach to this problem, unless
it will be possible for GPG to completely hide receivers - I am guessing
this is inherently impossible?
A couple of concerns, some of them UI:
* What if one of the e-mails go through and not the other, especially
from an UI perspective - how do you modify and re-send just that copy
of the e-mail.
* What if you want to reply-all to your own e-mail, in notmuch land the
messages with the same ID will be joined together. An UI could do
differently, but either way all the information about receivers you
need is in different files.
Realistically; I think the approach using optional/configurable - and if
possible: custom `hidden-receivers` [0] - is much faster to implement + easier
to get right. In other words, I would very much like to see a proper
implementation of the multiple-messages approach, but unless someone
else is able to help out, I will probably go for the simpler approach at
first.
Regards, Gaute
[0] https://github.com/jstedfast/gmime/issues/45
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20180205/64fcfd15/attachment.sig>
More information about the notmuch
mailing list