I have a user who is connecting from outside the office and he can receive email but not send email.
Most people these days are switching to Outlook Anywhere (RPC over HTTP), Outlook Web Access, or Exchange ActiveSync because they provide a richer client experience than POP or IMAP. Certainly, I use these methods when I am not at my primary corporate desktop machine. However, there are still those who are in the world of *nix or who have a client or phone that only supports POP or IMAP protocols.
Configuring Exchange 2007 for POP3 and IMAP4 clients is a little more complicated than in previous releases. The two major reasons are the introduction of server roles and the current lack of GUI for POP3 & IMAP4. The complications imposed by lack of a GUI should be solved in Service Pack 1. In this post, I will help you get up and running with POP3 & IMAP4 by helping you to configure the Exchange 2007 server and a sample client.
POP3 and IMAP4 protocols are part of the Client Access Server role. However, SMTP is also required for these clients to be able to send mail. SMTP is part of both the Edge Transport and Hub Transport server roles. Although Edge Transport server role is recommended for the Internet-facing servers in your organization, Hub Transport is more suited for authenticating and providing SMTP relay services for POP3 & IMAP4 clients, as Edge servers are generally not connected to the domain.
Configuring POP3 & IMAP4
The first thing you’ll notice is that these protocols are not running by default. So before you begin, you’ll need to change the service startup type to Automatic and start the services. Here’s the links to the steps if you’re not comfortable doing this on your own or want to learn how to use the PowerShell:
Next, you’ll want to recognize that by default, POP3 & IMAP4 are locked down to only accept SSL/TLS connections. This means your client will need to connect to the secure port or negotiate explicit TLS. Outlook Express / Windows Mail has an option to connect on the secure ports (995 for POP3 or 993 for IMAP4). If you do not use SSL, you will get an error similar to “Command is not valid in this state”.
Below, I will show you how to configure the client such that you do not have to make any changes whatsoever to the server. But, if you do not wish to enforce this requirement, then you can change the -LoginTypes switch using the appropriate Exchange Management Shell cmdlet for POP3 or IMAP4. Although PlainTextLogin does give you the most flexibility, I strongly discourage using this option, as it will allow passwords to be transmitted in clear text. Please note that if you make any changes, you should restart the POP3 and IMAP4 services for the changes to take effect.
Because the Edge Transport server role is designed to be Internet-facing, it might be expected that this would serve the needs of your POP3 & IMAP4 clients. Most commonly, however, your clients will be authenticating for the purposes of identifying themselves (sender permissions checks) and prove that they are allowed to relay. This authorization can be done by Edge only if it is in the domain. Since is not be the most common configuration, the Hub role may be more suited for this purpose. If the clients will be submitting mail from outside of your network, then that just means opening another SMTP port specifically for POP3 and IMAP4 submissions. As suggested in my previous blog about configuring Hub Transport for Internet services, separating anonymous SMTP traffic from authenticated and relay makes a good deal of sense for security and isolation purposes, regardless of the Exchange server role that you use for each. Certainly, the smallest organizations may prefer the simplicity of a single Exchange transport role.
Exchange supports the following authorization mechanisms on receive connectors which you will find useful for POP3/IMAP4:
- Basic (clear text, not recommended)
- Basic Requiring TLS (the most common choice because it works with all clients and is secure)
- Integrated Windows (also known as NTLM or SPA)
Out of the box, the Hub Transport role comes pre-configured with a receive connector for the purposes of accepting these types of client submissions. This default client receive connector listens on port 587 which is becoming the industry standard for client to server SMTP communication (to distinguish it from 25 for server to server). If you’re not planning to deploy an Edge Transport role, then for simplicity the “Default” receive connector (port 25) on a Hub Transport role is also configured to accept these SMTP submissions from authenticate POP3 and IMAP4 clients. Again, below I will show you how to configure the client such that no configuration changes are required on the server.
Table 8 in the Exchange 2007 Transport Permissions Model documentation contains some information about troubleshooting the various SMTP errors you may get.
Configuring the Client
To some extent this obviously depends on the client you’re using and the authorization mechanisms that you’re allowing on the server. Here’s an example of my own Windows Vista Mail client configuration. This client configuration requires no changes to the server, except for starting the services. These screenshots are for configuring IMAP, but POP configuration is nearly identical.
The most important thing on this screen is the authentication settings for SMTP. You must select “My server requires authentication” under “Outgoing Mail Server”. Additionally, you may choose to specify “Log on using Secure Password Authentication” which will use Windows Integrated.
Because by default both SMTP and IMAP are configured to require TLS, you’ll also need to configure the client to use SSL.
Note: This is not required if you changed the LoginType from SecureLogin to PlainTextAuthentication for IMAPSettings on the Exchange server. If you did that, you’ll be able to just use Secure Password Authentication (Integrated Windows) for both SMTP and IMAP and you can skip the SSL check boxes. Of course the option to use SPA is only available on some clients. Regardless, don’t use the defaults which are basic authentication without SSL.
Quick Note About Explicit vs. Implicit TLS (SSL)
One of the most commonly available clients today is Outlook Express 6, as it is on most machines that have (or had at one time) Internet Explorer 6. This is a pretty good client, but it has one known issue. At this time, it can only do SMTP explicit SSL on port 25. There is now a fix available to allow this on port 587, for more information, see http://support.microsoft.com/kb/933612/.
If this is your problem, you will get an error of “Your server has unexpectedly terminated the connection” or 0x800CCC0F.
This issue is fixed in Windows Vista’s Mail client, most recent versions of Outlook, and the replacement for Outlook Express, Windows Live Mail Desktop. As a workaround, use only port 25 when requiring TLS (even if it means using a different IP address than your MX record), or simply use a different client. Also, note that even with clients that support explicit TLS on 587, you may not be able to pick some arbitrary port of your choosing, as the client may still attempt to use implicit SSL and therefore fail. Also, do not attempt to use port 465 as that is for implicit SSL, which Exchange does not support for SMTP.