Announcing Astroid v0.11
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Sun Feb 4 13:18:02 PST 2018
On Sun 2018-02-04 20:10:25 +0100, Gaute Hope wrote:
> Because that is currently the only option when using GMime [0].
right, sad. and that's likely due to the constraints of GPGME. what a
dependency chain!
I've just opened two issues to try to push that forward:
https://github.com/jstedfast/gmime/issues/45
https://dev.gnupg.org/T3775
Feel free to weigh in there as another MUA developer -- if you let them
know what kind of an interface you'd prefer that would help them see
that this is a valued feature.
> Agreed; it should be turned off (as per the spec in my previous email)
> when there are no Bcc-recipients.
right, that's a clear win over the current status quo.
> 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.
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.
I don't think that's too bad of an option, actually, and it's not taking
on the job of the MTA entirely. It is a little bit strange because then
there's two ciphertexts generated that are publicly marked to have the
same cleartext (by matching Message-IDs), but that shouldn't be a
problem if the ciphers are reasonable.
--dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20180204/18ddd674/attachment.sig>
More information about the notmuch
mailing list