The mobile versions of Microsoft Outlook have broken support for using STARTTLS during an IMAP connection. After sending the first STARTTLS command and receiving a reply, they send a second, spurious STARTTLS command. This gets misinterpreted as a bizzare, implausibly high TLS version by OpenSSL, which causes it to cut the connection. Outlook then reports an alleged "certificate error".
Outlook Mobile is still able to connect using the legacy port which uses TLS from the beginning. However, if you connect to the normal port, if it detects STARTTLS support it will attempt to use it even if you attempt to configure it not to.
There's a Python mail suite called Twisted that includes an IMAP server implementation and TLS implementation in pure-ish Python. I was able to build a toy server and patch it so that if received a TLS version of 63.48 (for example), instead of immediately disconnecting it tried to reinterpret that packet as a cleartext IMAP command and, if it was STARTTLS, send another affirmative reply and restart TLS from there. With this patch, Thunderbird, Outlook desktop, Outlook mobile, and Twisted's client libraries were all able to connect and run without issue.
I know this is awful, that OpenSSL goes out of its way to make it hard to support this -- and with good reason -- and that Microsoft should fix their application to comply with the IMAP specification. However, I've reported this problem to them several times and they won't fix it. There is no MercuryI Events support in the DDK (and its internals are specifically and explicitly not documented, unlike most of the rest of Mercury) so I can't fix this on my end; if I'm to get this to work, I'll need it in Mercury itself.
(I'm posting this here because the Feature Suggestions forum doesn't allow new topics, I don't think this is within the scope of a technical support incident, and Mercury's licensing system is down anyway so I couldn't file one even if I was wrong.)