MailScanner Guide



This project was initially funded by JCAS and was first presented at the JANET Networkshop and User Support Workshop 2001. The ongoing development of MailScanner has been greatly helped by the donation or loan of equipment from transtec Computers, Netergy and The Jackson Family Ltd.

I must also thank Nick Philips for all his contributions and tireless work on the Exim support. Credit also due to ic Consulting for contributing the Inoculate-IT support, Funk Gabor for contributing the Inoculan 4.x support. Many thanks to the folks at ReflexIP for giving me a licence for NOD32 to aid development and testing.

Last but by no means least, my thanks to numerous other people who have contributed translations, ideas for new features, support for more virus scanners, ....

Brief Description

MailScanner is a complete e-mail security system designed for use on e-mail gateways. It protects against viruses, and detects attacks against e-mail client packages (such as Outlook, Outlook Express, Eudora). It can also detect almost all unsolicited commercial e-mail (spam) passing through it and respond to all incidents in a wide variety of ways.

Not only can it scan for known viruses, but it can also protect against unknown viruses hidden inside e-mail attachments by refusing entry to attachments whose filenames match any given pattern. This can include generic patterns that trap filenames attempting to hide the true filename extension (e.g. ".txt.vbs").

Attachments containing viruses that can be disinfected (e.g. word processor macro viruses) are automatically disinfected and sent on to their original destination.

It is superior to many commercial packages in its ability to handle attacks against itself, such as Denial Of Service attacks caused by messages containing the "Zip of Death".

It is easy to install into an existing e-mail gateway, requiring very little knowledge of sendmail (or Postfix, Exim or ZMailer) and no change to an existing sendmail configuration.

If you cannot afford to run it as a virus scanner, but wish to use it solely for e-mail spam protection and e-mail client vulnerability protection, you can just set "Virus Scanner = none" and it will no longer require any form of virus scanner to operate.

MailScanner itself is entirely open source, but it uses widely known commercial virus scanning packages at its core. The other software it uses is all high quality open source software, leading to a system that can be trusted for performance and reliability.

Features and Highlights

How It Works

E-Mail Service and Delivery

In its most common use, sendmail provides both SMTP service and delivery service at the same time. It listens for incoming e-mail messages on the SMTP port, places them into a queue, and delivers them to their destination at the earliest opportunity.

When using MailScanner, this is split into two separate jobs, each handled by a different sendmail process and a different queue. The first sendmail process listens for messages on the SMTP port and places them into an incoming queue. MailScanner is responsible for collecting messages from the incoming queue, checking and filtering them, then placing them in an outgoing queue and triggering the second sendmail process to deliver them.

Due to the design and structure of sendmail, this split is extremely simple to achieve and requires no recompiling or configuration file changes. All the required changes can be easily done by editing the commands used to start sendmail.


After initialisation, MailScanner repeatedly executes a loop that does the following:

  1. Collect messages from the incoming queue
  2. Check the messages to see if they are probably spam, and mark them if necessary
  3. Optionally move simple plain-text messages to the outgoing queue and trigger their delivery
  4. Unpack MIME structure of all remaining messages
  5. Scan everything for viruses
  6. Scan everything for filenames matching user-supplied ruleset
  7. Scan everything for attacks against e-mail client programs, such as Outlook or Eudora
  8. Move infected or dangerous attachments into a quarantine area if desired
  9. Replace infected or dangerous attachments with text attachment containing explanation to user
  10. Add a short message on the front of the original message body encouraging the recipient to read the replaced attachments
  11. Move entirely safe and uninfected messages to the outgoing queue
  12. Rebuild modified messages into the outgoing queue
  13. Delete original messages from incoming queue
  14. Trigger delivery of messages placed in outgoing queue
  15. Notify local postmaster, and message senders, of infections or dangerous attachments found
  16. If possible, disinfect original attachments and send them onto the original recipients with a note explaining what happened

Almost every aspect of the process above can be configured, from the maximum size of the batch of messages to scan on each iteration, to the e-mail address of the local postmaster.

To minimise any chance of message corruption, any messages that are found to be entirely clean and uninfected are moved directly between the two queues; no attempt is made to rebuild them from their constituent MIME entities. A message is only rebuilt from its MIME entities if an infection or dangerous filename was found, causing the replacement of the attachment with a text message.

To eliminate any chance of delivering a message containing an infection that failed to be disinfected, the disinfection process scans, then disinfects, then scans again. Only attachments that passed the virus scanner in the last scan are forwarded to the original recipient.

Spam Detection

Every incoming message is checked to see if it was sent by either an open mail relay, a known spam source, or was sent directly from a known dial-up line without passing through a proper mail server. This is all done using publicly available on-line databases, and therefore requires no maintenance by the administrator of this package. If, as a result of these checks, a message looks suspicious, it is marked by the addition of an extra header listing the databases where it was found. The message is then delivered as normal (after virus-checking, of course).

The SpamAssassin system is also supported as an optional extra, which if installed will greatly improve the ability to be able to identify spam. This is a very clever heuristics-based engine that identifies spam using a wide range of dozens of tests on both the headers and body of the message.

In the case of a regular correspondent whose mail server is marked as a source of spam, their address can be added to a "spam white list" of addresses or networks whose email will not be marked as spam.

This approach of marking but still delivering suspicious messages allows the end-user to take full control over their e-mail. Many e-mail packages and delivery agents, such as Eudora, Microsoft Outlook, pine or procmail, can be configured to check incoming mail against rules and save or even delete messages appropriately. Some users who are very anti-spam may choose to automatically delete any marked messages. However, most users configure their e-mail package to automatically save marked messages in an "Auto-Spam" folder.


Considerable lengths have been taken in the design of this software to ensure that there is no chance of e-mail messages being lost due to failure of any part of MailScanner or its supporting software packages. It is well appreciated that robustness and reliability are of great importance in the choice or use of any software system which handles e-mail.

As can be seen from the above order of operation, even if everything fails (e.g. due to complete failure of the virus scanner), simple plain-text messages will still propagate through the system and be delivered normally.

If at any time the process is interrupted (by, for example, MailScanner being killed or the entire computer crashing), no mail will be lost. The worst possibility is that there is a very small chance of a few messages being delivered twice, but this has not been reported in practice.

To avoid operating system resource leaks, MailScanner periodically kills and restarts itself. There have, in the past, been a few Perl modules which have managed to leak memory, and this simply avoids this ever causing problems by giving the operating system regular opportunities to clear up from the application.

There has never been any indication that this application does indeed leak resources, but it is a prudent design step which may improve the reliability of the program, and certainly does no harm.

red by Google]   Translate this page to 

Julian Field