Outlook clients and Exchange servers are designed to communicate securely. But Exchange also often uses the legacy...
SMTP and IMAP protocols for external communication. This tip discusses the security features that are built into SMTP and IMAP.
Built-in security features in SMTP
In the early days of the Internet, there were only a handful of trusted mail servers. Because of this, there was no real reason to include security features in Simple Message Transfer Protocol (SMTP).
Once the Internet became public, SMTP security concerns grew. And attempts to retrofit the SMTP protocol with security mechanisms have largely failed because of compatibility problems with mail servers that were running legacy versions of SMTP.
During the 1990s, several extensions were added to the SMTP protocol; however, only the AUTH extension (from RFC 2554) is directly security-related. This extension allows SMTP sessions to be authenticated.
Even though AUTH is the only SMTP extension that's directly related to security, many mail server products and third-party mail server add-ons such as spam filters. These products are designed to provide SMTP security independent of the actual SMTP protocol.
For example, in an Exchange Server environment, it's possible to prevent mail relaying, even though the original SMTP implementation was designed for this. Exchange is also designed to limit the size and volume of inbound SMTP messages to prevent denial of service attacks.
Microsoft has prevented the use of SMTP's EXPN command, which is used to expand a distribution list. By expanding a distribution list, an attacker can gain access to email addresses for all individual recipients on the list. Microsoft chose to block this command -- even though it's a part of SMTP -- to improve security.
IMAP's built-in security features
The Internet Message Access Protocol (IMAP) uses the following four IMAP states, making it more secure than SMTP.
- Not authenticated state -- An IMAP session begins by establishing a TCP/IP connection. When this connection occurs, IMAP is usually in the not authenticated state. While in this state, the client is only allowed to provide the server with authentication information or disconnect from the server.
The not authenticated state works differently if the client has been pre-authenticated. IMAP does not perform pre-authentication by itself; pre-authentication can only be used if an external authentication mechanism has established the client's identity.
- Authenticated state -- An IMAP client enters the authenticated state when it has either provided the messaging server with authentication information or has been authenticated through the pre-authentication process. Once in an authenticated state, a client may select which mailbox it wants to interact with.
- Selected state -- An IMAP client enters the selected state once it has chosen a mailbox to interact with. A client can only access email messages once its session has been placed into the selected state.
When a client finishes using a mailbox, it can logout or disconnect from the current mailbox. Disconnecting from a mailbox places the client back into the authenticated state, where it can select a different mailbox.
- Logout state -- This state terminates the client's connection to the IMAP server. To reach the logout state, you can enter the Logout command or time out due to inactivity.
About the author: Brien M. Posey, MCSE, is a seven-time recipient of Microsoft's Most Valuable Professional (MVP) award for his work with Exchange Server, Windows Server, Internet Information Services (IIS), and File Systems and Storage. Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, Brien has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal website at www.brienposey.com.
Do you have comments on this tip? Let us know.