A quick look at IMAP capabilities in Mail for Windows 10

The IMAP standard defined TLS support all the way back in 1999. Yet, when Mail for Windows 8 and Windows Phone 8 was released back in 2012, only the now deprecated SSL method was available for encrypted communications with IMAP servers. Three years later with the release of Mail for Windows 10 and Outlook Mail for Windows 10 Mobile, the built-in email client in Windows finally understands the STARTTLS command and starts using modern protocol encryption standards.

Mail has a strong preference for SSL over TLS. Windows will try to connect to the legacy port 993 (IMAP+SSL) and attempt to establish an SSL connection. Failing that it will try the same on port 143 before falling back to attempting a standard STARTTLS negotiation for TLS on port 143. Specifying the port number to 143 will remove the first attempt, but will still attempt to establish an SSL connection on that port before making another attempt for TLS.

As few — if any? — IMAP servers support SSL on port 143, this should be enough for Mail to default to TLS over SSL. Mail must be manually configured to use port 143 and users may not know how to do that. I’d advice IMAP server administrators to disable support for SSL — a now entirely deprecated and discouraged protocol — to help ensure their users will use TLS instead.

Disabling the “Require SSL for incoming email” setting under advanced account settings will skip the SSL behavior on port 993 and 143. Mail will instead negotiate TLS directly on port 143 after a server has announced support for the STARTTLS capability. Unfortunately, this puts Mail in a mode where it will transmit the password to any attacker-in-the-middle attackers pretending to be the server and either stripping out the STARTTLS capability of killing the connection once TLS negotiation has started.

Mail will stupidly proceed to login over an unencrypted channel even on a server that declares a LOGINDISABLED capability. LOGINDISABLED informs clients that all login attempts will fail without the client first taking other actions like STARTTLS. This protocol downgrading is a weird response to a failed login attempt. But in any case, always leave the encryption enforcement setting enabled to stay clear. Mail for Windows 10 is like it’s predecessor on Windows 8 when it comes to ignoring the LOGINDISABLED instructions from IMAP servers.

An account can make exactly one security exception for one self-signed or otherwise invalid certificate sent from the server. After allowing an account one exception, Mail will not accept any changes to that email account’s certificates in the future. If the server were to change an exempt and thus allow-listed certificate to another invalid certificate, the account must be removed from Mail and recreated for, a new exception to be allowed to be added.

This is an interesting security measure/inconvenience that should encourage email service providers to get their certificates in order and keep them that way. The user must manually click the Sync button twice after adding an account with an invalid certificate to get the client to connect to the server. The first click on the button will display an invalid certificate dialog, allowing the user to create an exception, and the second click will kick-start the syncing after the exception has been created.

The client will show an unhelpful error in a toolbar saying “Your account settings are out-of-date” before doing this. The same procedure must be repeated after the first time the user tries to send an email as the client will need an exception for the SMTP server.

The lack of STARTTLS support for IMAP was a personal pet-hate for me with Windows 8. My personal email server didn’t support the legacy SSL method for security reasons (and it would be extra work to set up and maintain it.) I used to have a Microsoft Surface tablet with Windows RT; a limited and now discontinued version of Windows that didn’t have any other email clients available.

Another annoyance that unfortunately will be familiar to those of us who use mainly different computers and thus many different email clients, Mail for Windows 10 doesn’t support LIST SPECIAL-USE folders. This is the IMAP extension RFC 6154 that the client should have used to configure special-purpose folders like Trash, Junk, and Sent.

Instead, Mail will use hardcoded localized folder names that may or may not match those of your other email clients. You may end up with one Sent and one Sent Items folder, for example. On a more positive note, the Outlook 2016 app — part of Office 2016 Preview — does now indeed support the SPECIAL-USE folders extension.

The naming issue with the Windows 10 and 10 Mobile apps is also a bit offsetting. On Windows 10 Mobile, the app is called “Outlook Mail” but on Windows 10 it’s called simply “Mail”. Searching in the Start menu in Windows for “Outlook” will not find the Mail app even though the Windows Store lists it as Outlook Mail on both platforms. Similarly, Mail for Windows 10 identifies to IMAP servers as “"OS" "Windows Mobile"”, and Mail for Windows 10 Mobile identifies to IMAP servers as “"OS" "Windows"”.

For being a new and modern app, Mail for Windows 10 as an IMAP client leaves a lot to be desired on the security front. It prefers deprecated and insecure standards over the newer (from 1999!) and more secure replacement protocols. It speaks the IMAP language, but it’s clearly not a native speaker.