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