The Internet Message Access Protocol, first specified in the 1980s, enables remote users to view and manage messages stored on mail servers. While IMAP has become less important as enterprises and users move to webmail services to manage email directories and messages, it is still widely deployed and used — often behind firewalls and gateways. This means that managing IMAP security issues continues to be a challenge for many users and organizations.
Like so many other protocol specifications for internet applications that originated when the internet was largely an academic and research network, IMAP security was left as an exercise for the implementers. And like those other protocols, fully-compliant IMAP implementations expose all users by permitting remote users to authenticate themselves with plaintext user ID and passwords.
Most IMAP security issues have been addressed in the decades since the protocol was first documented as a proposed experimental specification. But IMAP continues to be an email security trouble spot because it is so widely implemented and deployed in so many different environments, and as a part of so many different platforms.
IMAP security issues
The top IMAP security issue is due to the fact that it was designed to accept plaintext login credentials. While this is not the only issue, it is probably the most intransigent challenge to defenders.
Another IMAP security vulnerability has to do with a lack of support for strong authentication, in particular the enforcement of multifactor authentication (MFA) for third-party email clients when logging into IMAP services hosted on cloud services. A recent example is the password spraying attacks against Microsoft Office 365: While Office 365 can be configured to require a second factor to authenticate remote users, that authentication step could be bypassed by accessing IMAP services from a third-party email client.
Security professionals have long been aware of the dangers of application protocols that permit plaintext credentials, and the default configuration for IMAP software has long been to enable TLS encryption of credentials. However, there is still no mechanism in the IMAP protocol for requiring the use of MFA.
Similarly, third-party IMAP clients don’t always support Office 365 sign-on policies that would shut down remote users who attempt to sign on too many times, which opens the door to attackers attempting brute-force attacks on accounts.
The most obvious IMAP protocol vulnerability — transmitting credentials as well as email interactions in plain text — has largely been addressed through the use of implicit TLS for all email protocols. The IMAP over TLS protocol, spelled out in RFC 8314, clarifies that all legacy email protocols, including SMTP and POP, should by default use TLS for encryption of user mail sessions, or at least implement opportunistic encryption through the STARTTLS protocol. However, requiring TLS by itself is not enough to prevent the IMAP password spraying attacks.
Tightening IMAP security
Knowing that there are issues is the first step to strengthening IMAP security. Protecting vulnerable systems must begin with identifying all the places where the vulnerable protocols are deployed, followed closely by making sure that all protocol services are properly configured to enforce encryption either through STARTTLS or IMAP over TLS.
The original default port for IMAP is port 143 for requests from clients, but port 993 is specified for IMAP over TLS; reconfiguring all clients and servers to use port 993 can help eliminate plaintext connections. Firewalls and other gateway systems can also be configured to block connections on the unsecured port 143.
Other ways to secure IMAP should address the different ways that IMAP servers are accessed. For example, some tactics include:
- Use firewall rules to prevent direct remote access to IMAP servers.
- Enable multifactor authentication as broadly and widely as possible for remote access.
- Use zero trust models to restrict users from accessing IMAP services without MFA.
- Reconfigure email and other services to disable unauthenticated remote access.
- As an extreme measure, disable end-user access to legacy email services entirely and require they access email remotely through HTTPS services.
While it may not yet be practical to eliminate all legacy email protocol services, it is possible to secure these services against the most common vulnerabilities and the attacks that take advantage of them.