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

[Daniel Kahn Gillmor]

On Mon 2018-02-05 08:33:36 +0100, Gaute Hope wrote:
> 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? 

I'm not sure how gpg could do that -- the metadata leak of most
recipients (To:, Cc:) is *outside* of the material that GnuPG handles,
since GnuPG doesn't see the mesage headers when it's encrypting the
body.  Maybe i'm misunderstanding you though?

> * 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.

yes, this is an ugly situation, and i can understand how you're framing
it as "like taking over the job of the MTA" :/

What if you treated the message as "unsent" until *all* of the outbound
copies were successfully sent?  most MUAs have an "unsent" or "sending"
state for messages, right?  seems like it'd be the same state here.  at
worst, this means you might trigger some message redelivery if one copy
goes through clean and another copy does not.  that doesn't seem like
too bad a price to pay.

> * 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.

what happens if you reply-all to your own e-mail that has a bcc
currently?  in my experience, notmuch will not show you the Bcc and you
will only be "replying all" to the visible recipients.  Since the
headers will be identical on the Bcc and non-Bcc versions of the
outbound mail, this doesn't seem to be an issue to me at all.

> Realistically; I think the approach using optional/configurable - and if 
> possible: custom `hidden-receivers` [0] - is much faster to implement + easier 
> to get right.

well, easier for the developer -- it's tough for the user to manually
flip the switches when they need to, unfortunately, even though we as
developers know how they *should* be set.

> 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.

yup, understood.  thanks for looking into this!

     --dkg