Securing Email Services (POP3 and IMAP)

POP3 and IMAP are arguably even more vulnerable to clear-text security risks than Telnet. If your users have set their email clients to connect to the server every five minutes or so to check for new messages, a plainly visible login and password transaction occurs with each one of these connections, resulting in an even higher likelihood of password compromisesespecially because these services send their sensitive data at predictable, regular intervals. If you're enforcing SSH rather than Telnet on your server, it's in your interest to do the same for your email services.

You learned in Chapter 25 how to secure the Qpopper program to use the built-in SSL tools in FreeBSD to encrypt POP3 connections. You can use the same method to secure IMAP, employing the IMAP-UW software package. You can enable SSL support in IMAPUW by generating a certificate with a Certifying Authority (as you learned in "Enabling SSL Encryption," in Chapter 25). If you have a certificate generated for a different service (Qpopper, for example) on your site, you can use the same certificate for IMAP-UW. Refer to the IMAP-UW documentation at http://www.washington.edu/imap/ for more details.

The stunnel program provides an alternative way to encrypt both POP3 and IMAP. stunnel manages your SSL certificates centrally and doesn't use each service's built-in SSL support. Also available in the ports (/usr/ports/security/stunnel), stunnel allows you to set up a universal SSL tunnel for any service on the system that you choose. If you install stunnel from the ports, its default startup script (/usr/local/etc/rc.d/stunnel.sh.sample) starts a listener process on port 993 (for IMAP) and 995 (for POP3), which are the generally accepted ports for the secure versions of these protocols, as you can see in /etc/services.

Note

Remember to rename stunnel.sh.sample to stunnel.sh, as you learned in the section titled "Resource Configuration Scripts," in Chapter 14, "System Configuration and Startup Scripts." The .sample suffix is there to make sure you look at the script's contents to ensure the paths to the .pem certificate files are correct.

If you choose to use stunnel, you'll still have to generate a certificate, just as you do with Qpopper and IMAP-UW. The stunnel certificate should be placed at /usr/local/etc/stunnel.pem. When it's in place, your POP3 and IMAP clients should be able to connect to the appropriate ports to establish a secure connection (993 instead of 143 for IMAP, and 995 instead of 110 for POP3).

Caution

Many of the popular email client programs, such as Microsoft Outlook and Apple Mail, support SSL encryption for POP3 and IMAP, but others have support for only one of the two, or neither. In other email client programs, such support is incomplete or optional. Requiring users to use SSL might mean requiring them to switch email programs, something not many people like to do.

Also, note that stunnel is not a replacement for POP3 or IMAP. Rather, it's an augmentationthe generalized addition of SSL capability to any specified service. This means that the regular POP3 and IMAP services must still be enabled; you can't remove these services from /etc/inetd.conf. You'll need to use IPFW (as you will see later in this chapter) to disallow connections to these ports from any host other than localhost if you want to enforce a "secure connections only" policy.