Please do this in main.c read_options so that its aligned with all other options, see my comment in the header below, why.

Postponed?

I see why you made this a function instead of using read_options if you used "check_html_preferred" as an example. The difference between check_html_preffered and check_auto_vd_mail is that check_html_preferred depends on an Outlook setting. All the other options (including auto decrypt) are gpgol options. Since we don't get a signal when the outlook option changes, we check it at runtime.

Here it gets intresting. In the log, check how far in the event loop the second mail is created. I think here it is only the item load event. No further events. But an event handler will be installed for the "new" mail and a GpgOL mail object is created.

This is done to mark in the GpgOL Mail object that this is a copy, so that in the event handler it can be treated differently.

I think this is the main issue where you might be stuck. The copied mail at this point will only be very shallow. You have to return here, give outlook a chance to really load and populate the copy (read etc.) and then decrypt in the event handler of the second mail. I would expect calling "open" directly will also fail with an oom error like "you cannot call this method at this time" so you need to use an async window message to queue the open for the newly created mail and return in this event handler.

So something like:

if (m_mail->isCryptoMail () && m_mail->isVdProsponed ())
        {
               Mail *copy = m_mail->copy();
               do_in_ui_thread_async (OPEN, copy);
               log_dbg("Delegating open to copy: %p", copy);
               TBREAK;
        }
 else if (!opt.dont_autodecrypt_preview || m_mail->isCopyOfCryptoMail())
        {
              m_mail->decryptVerify_o();
        }

The open windowmessage you have to implement, it should just invoke open, like the send window message. There are examples. There is also a decrypt window message which was used to enable some kind of API like access to GpgOL allowing an external tool to send a window message to trigger a decrypt.

isVDProsponed should probably be something like opt.dont_autodecrypt_preview && mail->is_crypto_mail(). The naming could be clearer that this is queried to decide wether or not to show the decrypt action.

The idea is that the user can switch the feature on and off w/o restarting Outlook. I meanwhile merged the patch and added a comment

/* Note: This is called for each Read event - it may make sense to add
    some optimization.  */

For example timer based or via some other reload mechanism for certain options.

We tested the code and it works as expected. Thus I do not really undertand your idea here. Anyway it has been merged and we can enable the code via a Regisry setting. Thus no harm should happen in the standard case. The new code needs more testing in the field of course.