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