S 5.56 Secure operation of a mail server

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: Administrator

Secure operation of a mail server requires that communication is secure both locally and also over the public network. The mail server receives e-mail from other mail servers and forwards it to connected users or mail servers. The mail server also forwards e-mail transmitted by local users to external mail servers. Here, the mail server must ensure that local e-mail transmitted by connected users is only forwarded internally and not allowed to reach the public network.

A mail server temporarily stores e-mail until it is forwarded. Many Internet providers and administrators archive incoming and outgoing e-mails additionally. The mail server must be protected appropriately to prevent unauthorised persons from gaining access to messages on it. For this purpose, the server must be located in a secure area (server room or server cabinet). One administrator and one substitute should be trained and placed in charge of the proper functioning of the mail server as well as its operating system. A postmaster and abuse account must be configured (also refer to S 2.456 Secure administration of groupware systems).

Only locally connected users should have access to their mailboxes. However, these local users should not be allowed to access areas where e-mail is stored temporarily prior to forwarding (e.g. spool files).

Regular checks must be made of the stability of links with neighbouring mail servers, particularly that of the mail provider. Furthermore, regular checks are required to determine whether there is still sufficient hard-disk space for the temporary storage of mail, otherwise the exchange of messages might be impeded.

Logging of the mail server's activities should be defined with respect to scope and contents. The log data must be evaluated regularly, mainly in order to detect potential attacks on the mail server and their effects.

No other services should be dependent on the availability of the mail server, for example, the mail servers should not serve as a file server at the same time. Quick deactivation of the server should be possible at all times, e.g. in the event of a denial of service or if manipulation is suspected (see also S 4.97 One service per server).

To make unauthorised access to user accounts more difficult, user names on the mail server should not be directly inferable from the e-mail addresses.

MX entries and relaying

The DNS Internet naming scheme provides for a specific server to be dedicated as a mail exchanger by means of a so-called MX record. Normally, e-mails between computers of different domains should then only be forwarded via the relevant mail exchanger "in charge". The forwarding of e-mails between different domains is referred to as relaying. A mail server should be protected against use as a spam relay. For this purpose, the mail server should be so configured that it only accepts e-mails intended for the organisation and only transmits e-mails originating from the employees of the organisation. The mail server should only accept incoming e-mails if the IP address of the transmitting mail server is located in an IP network authorised explicitly by the administrator, or if the mail server holds an MX record for the recipient. All other e-mail must be rejected with a corresponding error message.

In spite of these safeguards, authorised users can continue to send/receive e-mails to/from any required party. However, the filtration of incoming e-mails described above prevents the mail server from being misused as a spam relay by external parties.

If IP networks from which e-mail is to be accepted have been inadvertently omitted from the list mentioned above, the administrator of the mail server must be informed duly so that he can subsequently include these networks in the list.

Non delivery notifications

In general, non delivery notifications are compliant with RFC and useful to inform the senders of e-mails that the e-mails cannot be delivered in case of temporary errors of the mail systems. However, the generation of non delivery notifications must be restricted to the event of an error and must be minimised as far as possible.

For example, it should be avoided at all cost that non delivery notifications are generated due to incorrect recipient addresses. Instead, it should be ensured that e-mails for which the organisation is not responsible are not accepted in the first place. It is absolutely necessary here to ensure that a service provider that checks the e-mails of an organisation in advance knows which e-mails must be accepted and which not so that it does not need to generate non delivery notifications if e-mails cannot be delivered. If this is not observed, spammers may exploit the sending of non delivery notifications to send spam to third parties in the name of the organisation.

In order to avoid risks caused by non delivery notifications, the following procedure may be advisable: Non delivery notifications are generally permitted. At the same time, all systems of an organisation that transmit e-mails and the e-mail systems of upstream service providers (up to the server to which the MX record points) are co-ordinated so that non delivery notifications are only generated in the event of an error. Among other things, non delivery notifications must not be generated because a recipient does not exist, because a mail system considers an e-mail too big, even though an upstream mail server has already accepted this e-mail, or because a mailbox is full.

The administrator should set up an alarm system which informs him/her when a system generates non delivery notifications. He/she should then check why this happens and eliminate the fault promptly.

Principle: From the first acceptance by the IP address of the MX record up to the user's mailbox, it must be ensured for a domain that the e-mails are transported and do not cause non delivery notifications due to contradicting configurations of the mail relays involved.

The problem caused by non delivery notifications indicates a general problem of e-mail communication. The sender of an e-mail is freely selectable and may be forged. If someone sends an e-mail with a forged sender address to an automatically responding system, this system will send the messages to the forged sender addresses. This can be used by an attacker to attack a third party in the name of the organisation and to flood them with e-mails. Virtually all systems that automatically respond to e-mails are suitable for this attack scenario. For the same reason, out-of-office messages, acknowledgements of receipt and forwarding may only be used with with extreme caution.

The following safeguards must be implemented for protection:

• No automatic reply to or forwarding of e-mails already classified as spam must take place.
• The sender addresses of the reply or forwarding must be an address from the name space of the organisation. The sender of the incoming e-mail must not be used.
• It must be prevented that a large number of e-mails is sent to a specific destination (destination address or destination domain) in an uncontrolled manner. If using out-of-office assistants this can be done by sending an out-of-office message to a sender only once.

Naturally, it must be possible for the mail server to be accessed from the Internet. For this reason, the server should also be protected on a network level by adequate safeguards. This can be accomplished, for example, by configuring an upstream firewall so that connections from the outside are only authorised to the corresponding ports. It is even better to locate the mail server in a demilitarised zone (DMZ) and to also restrict the connections to the internal network to the necessary protocols and services.

Authorised protocols and services on the mail server must be specified. For example, in most cases it is necessary to authorise SMTP (TCP port 25) for outbound and inbound links. The protocols POP3 or IMAP (TCP ports 110 and 143, depending on the way the mails are retrieved from the server), however, should only be authorised for accesses from the internal network. There are versions of both POP3 and IMAP in which login and transmission of data is protected by SSL. If the software used supports these versions, they should be used whenever this is possible.

E-mails are among the most common media used for spreading spam and malware. To protect oneself against this there are various strategies (see also S 2.154 Creating a security concept against malware). Experience has shown that e-mails should be checked on the firewall or on the mail server as well as on each client computer (see S 5.109 Use of an e-mail scanner on the mail server). All virus protection programs used must be updated regularly.

If, instead of operating its own mail server, an organisation accesses the mail server of a provider via one or more mail clients, clarification by the provider is required as to the rules and security safeguards applicable on that server (see S 2.123 Selection of a groupware or mail provider).

Review questions:

• Is the mail server located such that it is protected against unauthorised access?
• Is there a correspondingly trained administrator and substitute who is in charge of administering the mail server?
• Do only locally connected users have access to their mailboxes?
• Are local users not allowed to access areas where e-mail is stored temporarily prior to forwarding (e.g. spool files)?
• Are the activities on the mail server logged regularly and are these logs evaluated at regular intervals?
• Are regular checks made of the stability of links with neighbouring mail servers, particularly that of the mail provider, and as to whether there is still sufficient hard-disk space?
• Is there a policy specifying authorised protocols and services on the mail server?
• Is the mail server configured such that it cannot be misused as a spam relay?