S 5.109 Use of an e-mail scanner on the mail server

Initiation responsibility: Administrator, IT Security Officer

Implementation responsibility: Administrator

To increase security, an e-mail scanner with a memory-resident anti-virus program (often referred to as an e-mail guard) which checks incoming as well as outgoing e-mails (and especially their attachments) for spam features, computer viruses, and other harmful content should be installed on the central e-mail server .

In addition to configuring an e-mail guard on the e-mail server itself, it is also possible to set up an SMTP gateway on the gateway to the Internet which examines the incoming and outgoing e-mails. The connection to the Internet must be implemented so that SMTP connections can only be established through the SMTP gateway.

E-mail scanners use two fundamentally different approaches. A "store-and-forward" scanner accepts an e-mail first and then applies its mechanisms in order to classify the e-mail. After classification, the scanner decides what should happen with the e-mail (deleting, flagging, ...). The advantage of this method is that the e-mail is accepted first and can then be checked unhurriedly. However, this is at the same time a disadvantage, as from a legal point of view, the e-mail has already been accepted, and thus there is an obligation to deliver it to the user. An online scanner checks an e-mail while accepting an e-mail and tries to classify it. If it determines that an e-mail might be unwanted, it can directly reject it and the e-mail remains the responsibility of the originator. The advantage of this method is that the users are not flooded with flagged e-mails or quarantine notifications. The disadvantage is that, in case of incorrect classification by the scanner, the e-mail is no longer available locally. It is physically located at the originator and neither user nor administrator have access to it. In practice, a mixture of both methods is often used. The filter measures to be applied "online" or after acceptance of the e-mail must be defined in a corresponding policy and co-ordinated with management.

It is important in this context to scan outgoing e-mails as well. On the one hand, it is then possible to detect a virus infection in the internal network before too much damage is caused. On the other hand, it also protects the government agency or company against a possible loss of reputation or even damage compensation claims resulting from sending e-mails infected with viruses to business partners. For outgoing e-mail scanners it must be defined what happens to the e-mails determined as being infected with viruses. As a minimum, an alarm should be triggered for the administrator.

Most e-mail guards offer extensive configuration options relating to the handling of "suspicious" e-mails. For example, the basic policy might be to delete such e-mails, to deliver them flagged, or to store them temporarily on a "quarantine server" until it has been determined if the content is harmless or not. Another option is just to detach any potentially malicious e-mail attachments while sending the message itself together with a corresponding note to the recipient.

In order to detect spam features in an e-mail, appropriate e-mail scanners support various mechanisms.

In a first step, "blacklists" or "whitelists" are often used in order to verify the reputation of the external IP address involved in the communication. For example, there are lists that provide a statement as to whether an IP-address has sent unwanted e-mails in the past or whether a valid mail server is behind the IP address. In addition, there are lists that provide a statement as to whether the behaviour of a mail server behind an IP address complies with RFC, or whether this mail server is located in a dial-up network.

These lists are often used in order to terminate the communication with the IP address early and to not accept any e-mails at all. They are maintained by providers and offered free of charge as well as subject to a charge. When using such lists it must be taken into account that they potentially may be prone to errors. It may happen that a business partner is included in such a list due to negligence and as a consequence it is no longer possible to receive e-mails from this partner. Furthermore, it must be taken into account that a provider of such a list has the power to decide from which partner the organisation will continue to receive e-mails in the future.

In many cases, the providers of such lists make these available via a DNS sever (so-called DNSBL, DNS-based Blackhole Lists). If a provider of an e-mail scanner uses such a DNSBL, the e-mail scanner sends the IP addresses of all incoming e-mails to the provider of the DNSBL. As a response, the e-mail scanner receives a statement as to whether the IP address is listed or not. Through this procedure the provider of a DNSBL receives the IP addresses of all mail systems that communicate with the organisation. This enables him/her to create comprehensive profiles of the mail communication. To avoid this problem it is advisable to use local copies of the blacklists. Many providers make copies of the database available (subject to a charge).

The risks linked to the use of blacklists must be examined prior to their use. The risks arising from their use must be minimised by means of corresponding precautions or contracts with the provider.

RFC compliance check

Another important step is an RFC compliance check during the SMTP dialogue. It must be checked whether the originating mail server responds with a valid name (HELO/EHLO), whether the IP address of the server is resolvable through DNS, whether the resolution of the name returns the IP address, whether the syntax of the e-mail sender and recipient is correct, and whether the recipient actually exists. Spammers often create so many errors that it is possible for a large number of e-mails to be rejected by means of compliance checks. However, by implication, this means that an administrator must configure his/her systems so that they are compliant with RFC to ensure that the organisation's own e-mails are not blocked due to such errors.

Checking e-mail content

In a next step, the content of an e-mail is often checked. Signature-based filter systems are used here to detect unwanted e-mails using key terms or other characteristics typical for spam. The filters frequently employ a point system. If the filter system detects a certain negative characteristic, points are given. The points for all negative characteristics are then added and provides an indicator for the probability that the e-mail is unwanted. The filters that need to be configured for this are subject to constant change. The vision of an independently working e-mail scanner thus remains a vision. The filter systems must be adapted dynamically to the current spam waves and must provide possibilities for manual intervention by the administrator.

Every e-mail scanner should have at least one, preferably several, modules for detection of malware. E-mails with detected viruses should not be delivered, but stored temporarily in quarantine directories.

When handling attachments which may be potentially harmful but in which no malware could be proven at the time of delivery, a policy must be defined first that either specifies what file types are harmful for an organisation or what file types are definitely harmless. The need to transmit executable attachments in e-mails should be examined very critically. After the policy has been defined, it can be implemented by means of corresponding "blacklists" or "whitelists". A blacklist defines a list of "prohibited" file types that are never allowed under any circumstances to be sent as e-mail attachments and that are not accepted when encountered in incoming e-mails. A more restrictive approach is to use a whitelist, in which case the only file types that are allowed as e-mail attachments are those found in the predefined list of allowed file types. When specifying blacklists or whitelists, care should be taken to ensure that the organisation strikes a reasonable compromise between security and functionality. Under some circumstances, settings that are too lax could allow harmful content to get into in the internal network, while settings that are too strict could hinder productivity.

Since encrypted e-mails cannot be checked automatically, it is necessary to specify how encrypted e-mails will be handled (see also modules S 1.6 Protection against malware and S 1.7 Crypto-concept for more information).

The employees must be informed of the fact that e-mails are scanned automatically and which rules apply. In addition, the personnel representative and the Data Protection Officer should be involved if the organisation decides to scan e-mails automatically on the e-mail server. Depending on the country and type of organisation (government agency or company), it may also be necessary to comply with other laws and regulations.

Virus scanners should always be used on the workstation computers, even if an e-mail guard has been installed on the e-mail server. Although the vast majority of viruses and other malicious software are distributed by e-mail nowadays, there are still enough other ways to spread malicious programs, for example via USB sticks or other removable media or by downloading files from the Internet.

Business continuity plans in case of overloading

Systems transmitting e-mail often have to cope with sudden changes in the volume to be processed. Even if the organisation meticulously ensured good scaling of the systems, the moment will come when the systems are overloaded. A business continuity plan must be prepared for these moments.

A business continuity plan must be defined that describes how the functionality of the e-mail scanner can be gradually reinforced in order to reduce the processing volume as well as the effects of this on the communication. As the effects are frequently linked to restrictions, management must be informed of these restrictions and the business continuity plan must be co-ordinated with management. The practical feasibility of the business continuity plan should be practised in advance and modifications must be made, if necessary.

An exemplary business continuity safeguard would be the possibility to configure the e-mail scanner such that it only allows communication between defined communication partners. All other (new) communication partners are locked out during activation of the business continuity plan.

Review questions:

© Federal Office for Information Security. All rights reserved.