Announcing Astroid v0.11

Gaute Hope eg at gaute.vetsj.com
Sun Feb 4 11:10:25 PST 2018


Daniel Kahn Gillmor writes on februar 4, 2018 19:32:
> On Sun 2018-02-04 18:52:22 +0100, Gaute Hope wrote:
>> This is done to hide Bcc-recipients.
> 
> sure, but i'm wondering why you throw *all* keyids, instead of only the
> key-ids of the bcc'ed people?

Because that is currently the only option when using GMime [0].
 
>> As you say, GnuPG must try all the secret keys; but many 
>> users use some sort of keyring to unlock their keys - in which case 
>> the hassle is limited to a bit extra time. I don't have any stats on 
>> this though!
> 
> right, but the sender can't know whether this is the case or not, i
> think.
> 
> fwiw, i do agree with you that the onus is ultimately on the recipient's
> MUA to fix this UI/UX disaster; but why force it on them in the case
> where it doesn't actually eliminate any metadata leakage? (i.e., when
> they're in To: or Cc: already, and not Bcc'ed)

Agreed; it should be turned off (as per the spec in my previous email) 
when there are no Bcc-recipients. The best would of course be to send 
the e-mail seperately to each Bcc-recipient, but that feels like being 
overly careful / taking on the job of the MTA.

Regards, Gaute


[0] https://developer.gnome.org/gmime/stable/GMimeMultipartEncrypted.html#g-mime-multipart-encrypted-encrypt
-------------- 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/20180204/b2be0342/attachment.sig>


More information about the notmuch mailing list