Much effort has recently focused on new and better ways of filtering email traffic. Of course, static rules can always be applied with every MTA, but SPAM and virus traffic have increased the need for dynamic filtering.
Email filtering is a complex topic with lots of different methods of filtering. First of all you must understand that processing all your email traffic is going to take a substantial amount of resources, especially on busy servers. Before even discussing the technology you're going to use, you must decide if filtering your emails is really necessary and where the filtering should be done.
Of course the trouble-free approach would involve having the final user filter his or her own mail using his or her own resources. Your security policy or the user-awareness level in security matters, however, might demand site-wide filtering.
For local delivery, and if the user is accessing the mailboxes via shell access, you can defer filtering to the Local Delivery Agent. This means that the filtering is performed with user privileges, usually with a site-wide-enforced configuration and custom user settings as a fallback. Keeping everything user-side has the advantage of any problems or failures affecting at worst a single user's messages and not all email traffic.
Even when centralized email control seems necessary, we always strongly recommend not blindly dropping and/or quarantining affected messages, but rather politely adding a header that the informed user client can check later. This has the bonus of increasing user awareness, providing the user with a tool he or she can easily use for sorting emails and not giving administrators the troublesome problem of dealing with quarantined messages.
Mail filtering is usually performed site-wide at the MTA level, with direct hooks in your mail server configuration. Different MTAs provide different interfaces for applying external filtering applications. Some of them, like Sendmail and postfix, have a fullblown API (libmilter) that allows fast and effective filtering; others allow you to pipe to external programs directly or define the filter as an LDA replacement.
Here is an example of a milter definition:
%S=unix:/var/spool/MIMEDefang/mimedefang.sock, F=T, T=S:1m;R:1m')
Keep any form of filtering you might apply safe from failures. Emails should never be lost if your filter program starts to fail; rather, a temporary error (telling the sending server to keep the messages in the queue and retry at a later time) should be issued.
For SPAM filtering, Spamassassin and Dspam are the most prominent choices. The former is a rule-based solution that implements many "recipes" for catching known SPAM as well as Bayesian filtering. Dspam has a different approach and doesn't involve any specific rules, but provides generic adaptive filtering based on statistical analysis. They both have different methods for being hooked to your MTA and can be executed either by the final user or in the middle of the delivery process.
MIMEDefang is a generic filter that allows usage of arbitrary programs for tagging SPAM and blocking viruses. You can use commercial antivirus software and Spamassassin along with it for performing both tasks. It only works with the libmilter API.
In the same fashion Amavis (more specifically amavisd-new) is a generic virus scanner that also allows you to use your favorite antivirus software and Spamassassin. Unlike MIMEDefang, Amavis is more generic and supports various mail servers.
For virus-only scanning, the open-source project Clamav can be used directly with the shipped milter program or with additional interfaces (including MIMEDefang and Amavis).
For thorough auditing of your antivirus implementation, you should always make sure that simple archiving of infected binaries is not going to fool your antivirus software.
Of course, in the end, eluding the software with password archiving or public key encryption allows you to tag or block archived attachments depending on your internal security policy.
When implementing site-wide filtering you should try to trigger it before the email is accepted in the queue, so that you'll have an error over the SMTP connection rather than a later bounce in case of rejection. As mentioned already, bounced messages for malicious emails can stay in your queue for a long time if the envelope sender is forged and invalid.
Was this article helpful?