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