This is a longstanding problem in GpgOL. When sending encrypted mails with BCC the best behavior would be to send each BCC recipient it's own Mail to avoid any privacy leaks from the encrypted message.
Internally this requires us to copy the mail object and send it multiple times so it will be quite some work, but it will be worth it because this will then allow us to finally implement OpenPGP and S/MIME Mixed recipients, which I think is quite a killer feature.
| rO GpgOL | |||
| rO66ab6d830ade Add error handling and closing for split mails | |||
| rO48aa002f3a96 Implement BCC splits of Mails | |||
| rO2fbfc91d7de8 Add RecipientManager class | |||
| rO2d71d605a6d3 Avoid callbacks to track copied mail object | |||
| rOe6fbea5b0049 Add additional passed headers in mimemaker | |||
| rO080f5bd701f1 Implement multi mail sending for a crypto op | |||
| rO15ba0e600979 Fix cryptcontroller handling of resolved mails | |||
| rO1dc0fea716c7 Add opts splitBCCMails and combinedOpsEnabled | |||
| rOf70faebca1cb Use recipient objects in kleo based lookup, too | |||
| rO7118d1b65076 Change cryptcontroller to track recipients | |||
| rO31f9a4c0ed5e Add recipient class to carry key and type | |||
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Wontfix | aheinecke | T4814 GpgOL: Send multiple E-Mails for BCC recipients | ||
| Resolved | aheinecke | T5273 Release Gpg4win 4.x.x |
The idea of the implementation is that BCC recpients will get a mail with no other recipients. Because Exchange / Outlook handles the sending we can't do it more low level. We use the "Protected-headers" scheme to transfer the original To / CC headers.
It's all a bit of a struggle because you can easily have hundreds of BCC recipients if you use Address lists. The current code would send each of them its own mail. We need to figure this out a bit more so that a "Recpient" is internally not an SMTP address but similar to the recipient object in outlook. So a list that is represented as one recipient should only receive its one mail.
More fun: Combined with the S/MIME & OpenPGP split feature you can have a BCC list with some OpenPGP and some S/MIME recipients.
I think this is a great feature to have. Thanks for working on it, @aheinecke .
fwiw, i'm not super convinced that the split S/MIME and OpenPGP feature. Since it only works for Bcc: lists -- but not for Cc: or To: lists -- it's likely to be a very confusing feature for normal users.
Sadly, i also don't see an easy way to make it work for To: and Cc: lists. If you have a suggestion for how that might be done i'd be curious to hear about it. (maybe splitting up the e-mail into two messages with the same message-id: one batch of OpenPGP recipients and one for S/MIME recipients? that still makes reply-all kind of disastrous)
For the split OpenPGP / SMIME it's not intended to only work for BCC, its just the same mechanism I use internally.
KMail has this feature for ages, and it just works™, ;-) my users at a german governmental institution who were migrated from KMail to Outlook last year really miss that feature.
Indeed you split out the message and encrypt & sign it differently with the different protocols. The problem here is that you don't want to send the recipients two mails, so you have to also split out the CC / multiple To fields into different mails, I don't construct the To / CC headers, exchange / outlook does that. So that is where I am using protected headers to also communicate the original To / CC headers so that reply all etc. still works. This will then only work within GpgOL but as the alternative is not to have any support for encrypted mails to some recipients for which you have OpenPGP keys and some recipients where you only have S/MIME keys I think that its still a very nice feature even though it might feel a bit hackish and the mails may look weird in the message list because the TO/CC/BCC headers don't really match.
I think this works now with error handling. At least it works for me, but needs some more testing of course.
This will not translate into the new addon and is too large a change for the current one.