Implement multi mail sending for a crypto op
080f5bd701f1
Actions

Description

Implement multi mail sending for a crypto op

* src/cryptcontroller.cpp (CryptController::do_crypto): Return
after key resolution if multiple mails are needed.
* src/mail.cpp (g_mail_copy_triggerer): New. Helper to find
our Mail object in the event loop of the copied message.
(Mail::Mail): Initialize new state variables.
(Mail::preProcessMessage_m): Return early for copied mails.
(do_crypt): Reset recipients on key resolution error.
(Mail::updateOOMData_o): Handle explicitly set recipients.
(Mail::updateOOMData_o): Add sender as a recipient in our
internal data.
(Mail::setRecipients): Allow to set the recipients for a mail.
(Mail::updateCryptOOM_o): Reset recipients on error.
(Mail::setSigningKeys): Renamed from Mail::setSigningKey
to handle multiple signing keys.
(Mail::getSigningKeys): Accessor.
(Mail::copy): New. Copy a mail and return the copied IDispatch.
(getKeysForProtocol): Helper around some cryptic c++.
(Mail::splitCopyMailCallback_o): New. Main function to handle
splitting of mails.
(Mail::splitAndSend_o): Split out other mails and send the
mail.
(Mail::resetCrypter): Move definition out of header.
(Mail::resetRecipients): Clear out recipients and set keys.
(Mail::setSplitCopy, Mail::isSplitCopy): New.
* src/mail.h: Update accordingly.
* src/mailitem-events.cpp (Write): Detect if the written mail
is a copy and handle it accordingly.
(ReadComplete): Log it.
* src/windowmessages.cpp, src/windowmessages.h (SEND_MULTIPLE_MAILS)
(SEND): New callbacks.

This is the main commit that implements proper BCC handling
in which different mails are sent out to different recipients.

One of the main difficulties was to find our Mail object
for the copied mail as the IDispatch pointer returned
by the copy invocation differs from the one that we track
internally from the ItemLoad event.

The OOM also behaves a bit weirdly as the copy invocation
triggers the ItemLoad of a copy. But that copy is then unloaded
again when Send is invoked and a new mailitem is constructred
that will then see the send events. That is why we detect
if we are a copy in the write event, as we can there happily
access and modify the OOM and obtain the UUID from MAPI.
So if we see a crypto op (NeedsFirstAfterWrite)
of an item that has a UUID in MAPI but
no UUID in our internal data we can know that its a copy
and handle it using the g_mail_copy_trigger copy triggerer.