We will be migrating to a new mail system in the near future. The primary motivation for this migration is to meet the need and demands for an anti-spam and anti-virus solution from our customers. The migration will also help to lengthen the patch/update cycle of our current mail system as well as allow us to share the load of our mail system among several machines, hence increasing the scalability. Currently, we are using Sendmail to handle the transfer of messages from and to remote hosts. We will be switching to Postfix, an MTA originally developed by IBM, as part of the migration. Postfix has a much better security track record than sendmail and is also more efficient and faster than sendmail. Another advantage of Postfix is it's configuration, which is plaintext and human readable. When adding a new local domain to Sendmail's configuration, it must be restarted. Postfix, however, can read this information from a database and would not require a restart. Messages are delivered to users mailboxes using procmail in our existing system. Procmail is a very powerful mail filtering application, but it must be executed once for every message that is delivered. Cyrus, the mail storage system that we will be switching to, ships with an RFC standardized mail filtering implementation called Sieve. The component of Cyrus that handles filtering is daemonized (always running), thus it is far more scalable than Procmail. It also provides a standard interface for users to change their mail filters. We have modified a plugin for squirrelmail, a webmail interface, to provide our users with a 'wizard' to select their mail filtering preferences. The wizard is very simple and just adds filters for the user to handle mail based on tags added to the headers of each message by our mail filtering system. The downside to cyrus is that it requires more system resources. Cyrus uses systems resources more efficiently and will provide quicker responses to client requests. The 'core' of our mail filtering system is Amavis, an extremely flexible message filtering interface. Amavis is free, actively developed, and well supported. Postfix hands messages off to Amavis, which filters the message (adding the tags mentioned earlier to the header) and passes it back. Amavis also allows us to utilize multiple anti-virus applications for increased virus protection. It can tag message headers, reject virus infected/spam messages, or silently discard them. A weakness of any mail filtering system is the amout of resources they require and Amavis is no exception. However, the design of our mail system will allow us to scale our mail system in a cost effective manner (new filtering servers only cost ~$650). SpamAssassin (SA) is the application that handles spam filtering in our mail system. SA, like Amavis, is free, actively developed and well supported. SA is highly configurable and allows the administrator to modify the default weights for the characteristics that it uses to classify messages. SA also utilizes an implementation of the bayesian algorithm to enable it to classify messages more effectively. We are already using RBLs to help block messages, but SA views them as just another charasteristic while classifying a message rather than simply rejecting a message because the remote mail server is listed in a single RBL. We evalutated several anti-virus packages when designing the new mail system. Most vendors were expecting $9,000 or more annuallly for a subscriber base of our size. We opted to go with ClamAV primarily due to cost constraints. ClamAV is an open source anti-virus package that is under active development. We will be mirroring the virus data files for ClamAV, which will help facilitate keeping fresh copies on our servers. ClamAV can run as a daemon to allow it to scan multiple files (e.g. from separte emails) more efficiently. To facilitate distributing the load of message handling more effectively, we will be logically separting the functionality. Message filtering will be handled by frontend servers. The number of frontend servers can be increased easily and cheaply as previously mentioned. The backend server will only handle delivery of message to local mailboxes and IMAP/POP3 requests, which is very I/O bound. In order to make the conversion to the new system easier, we have purhcased a new mail server. Interestingly enough, the new mail server was cheaper than the cost of increasing our existing mail servers memory (not including the necessary storage). Cyrus has builtin support for clustering multiple backend servers together. The clustering is fairly simple/transparent to implement if it becomes a necessity. The filtering solution we are implementing will provide our customers with the mail filtering features that they're demanding as well as provide us with a stable, easily configurable, scalable, and cost effective mail system.