RemoteClient E-mail Security

Remote/Client E-mail Security

It is just as important to secure communication between clients and the e-mail system as it is to secure the MTA and internal e-mail systems themselves . E-mail clients may or may not have any connection to an organization's MTA architecture; however, more and more people are working from home or remotely. This requires organizations to provide some type of remote connection for the e-mail client. If a client connection to the e-mail system can be exploited, the connection is effectively a backdoor for attackers to use.

While various protocols and connection methods exist, many are inherently insecure . For example, the POP3 protocol sends credentials without encryption by default. These credentials, coupled with information gathered about an organization's infrastructure/architecture, may give an attacker "keys to the kingdom" by simply sniffing network traffic. The key to securing e-mail client-to-server communication is to encrypt the traffic. The following sections provide information on securing e-mail client connections through various types of connections/protocols.

POP3/IMAP

POP3 and IMAP connections are not encrypted by default. Secure Socket Layer (SSL) and Transport Layer Security (TLS) are the mechanisms that are most popularly used to encrypt POP3 and IMAP communication with e-mail clients. By default, POP3 and IMAP use ports TCP/110 and TCP/143, respectively. When encryption is used, the port numbers may change. POP3 over SSL (known as Secure POP3, POP3S, or SPOP3) uses port TCP/995. IMAP over SSL (known as IMAPS) customarily uses port TCP/993. The Internet Assigned Numbers Authority (IANA) determines which ports should be used for services and the port numbers listed above are assigned through IANA. One item to note: port TCP/585 is assigned to IMAPS as well; however, it is recommended by IANA to use TCP/993 instead.

By using POP3 and IMAP over SSL, authentication mechanisms as well as e-mail data itself is encrypted and far more secure than plaintext. Even if this information is sniffed at some point in transit, the data is unreadable. Secure Password Authentication (SPA) is another form of encrypting credentials; however, this mechanism provides no protection for the e-mail data transit itself.

Web Access

Depending on the e-mail package used, web access features may be built in or may be added. Whatever the implementation, administrators must ensure the data is encrypted as it traverses the Internet. HyperText Transfer Protocol (HTTP) by nature is insecure, so any data sent between the client and the e-mail server is not protected. Certificates must be enabled on the web server where web access is served from to provide encryption means between the web server and the client. Similar to any secure HTTP (HTTPS) offering found on the Internet, web access generally will use SSL/TLS for its encryption.

Virtual Private Networks (VPNs)

In many organizations, more than just e-mail access is needed from the internal network. For that reason, access to e-mail may be more secure through Virtual Private Network (VPN) connections. VPNs provide a point-to-point tunnel that is securely encrypted from end to end. Any e-mail traffic sent is safely transported through the tunnel to the internal network of the organization.

Message Submission Protocol

POP3 and IMAP4 are protocols used for receiving e-mail at the client level. In most organizations, remote clients using POP3 or IMAP4 use (e)SMTP (port 25) for sending outgoing messages. This may be configured through the remote client's ISP or through some type of authenticated SMTP with the organization's MTA. Whatever the case, there are usually concerns such as those discussed earlier in the chapter about clients sending e-mail on the standard SMTP port 25.

The Message Submission Protocol uses port 587 to allow clients to submit messages to Message Submission Agents (MSAs). These MSAs then either deliver the messages to the recipient MTA or send the messages to a relay MTA within the organization. This can be used for all clients in an organization but provides an alternative for remote clients and some of the challenges in using SMTP for outgoing messages.

Message submission is defined as a mechanism for users or clients to introduce new e-mail messages into a MTA network. In most organizations today, MTAs handle both the tasks of taking on new messages as well as routing and transferring the messages to the appropriate addresses. When using message submission, the client submits a message on port 587 to a system designed and configured to accept messages from clients. Various MTA packages also have features that can be configured to act as Message Submission Agents. Many open source e-mail packages such as Sendmail (which can also be commercial) and Postfix support MSA configurations. Some advantages of using message submission include

• Segregated security policies between MTAs and MSAs to assist in anti-spam techniques

• Different authentication mechanisms for MTAs and MSAs

• Simpler administration because services are separated to accept client connections and to accept MTA connections

Message submission is not widely used; however, it is available in several of the existing MTA packages available today as an alternative means for client connections (and subsequently sending e-mail messages).

Permissions and Passwords

One important aspect of remote client authentication is to limit account permissions to only what access is required by the user to conduct his or her duties . Stringent account and password policies should be enforced. Distinct passwords meeting these policies can help minimize the risk of remote client connections to e-mail systems. The scope of this book is not to provide account permissions advice; however, it is important to mention a true layered security model accounts for all of these items in addition to the details provided here.