MailScanner Installation and Configuration: Part One

MailScanner

MailScanner configuration under pfSense 2.1.3.

MailScanner is an e-mail security and anti-spam package for e-mail gateway systems. It is not designed to be run on Microsoft Windows desktop PCs. Instead, it is designed to be run on mail servers operated by companies and ISPs so that all their users and customers can be protected from one place. This avoids the need for any software to be installed on individual desktop PCs at all. The software works with any Unix-based system and is compatible with a wide range of mail transports, and comes with support for any combination of 25 different virus scanner packages, including the free ClamAV scanner.

MailScanner is implemented in around 50,000 lines of Perl. It links with other software packages in order to perform its functions:

  • E-mail server (e.g. sendmail)
  • Anti-virus software (e.g. ClamAV)
  • Anti-spam software (SpamAssassin)

MailScanner Installation

To install MailScanner under pfSense, navigate to System -> Packages, and scroll down to “Mailscanner” in the package list. Press the “plus” button to the right of the listing, and on the next page, press the “Confirm” button to confirm installation. It will take a few minutes for the Package Installer to extract and install MailScanner.

Once MailScanner is installed, there will be a new entry on the “Services” menu called “MailScanner”. If you navigate to it, you will be able to modify several settings. There are 9 tabs: “General”, “Attachments”, “Antivirus”, “Content”, “AntiSpam”, “Alerts”, “Reporting”, “XMLRPc Sync”, and “Help”. Under the “General” tab, the first heading is “System Settings”. The “Enable Mailscanner” check box will enable the mailscanner daemon if checked. “Max Children” allows you to choose how many MailScanner processes you want to run at a time (the default is 50. “Processing Incoming email” allows you to either scan messages or reject messages.


In the “Logging” secion, “Syslog Facility” allows you to specify what type of program is logging the message. The default is “mail”, and that is probably what you want to leave it at, but there may be circumstances when you may want to specifiy a different Syslog facility. See the Syslog entry on Wikipedia for a list of facility levels, or read RFC 1164 for more information. The “Logging” list box allows you to choose which messages to log.

“Advanced Settings” has some additional options. “Advanced features” allows you to select several options. By default, only “Deliver in Background” is selected. “Deliver Method” allows MailScanner to attempt immediate delivery of messages, or just place them in the outgoing queue for the MTA to deliver when it wants. “Minimum Code Status” lets you set the minimum acceptable code status; if MailScanner comes across a code that is not at least as stable as what it set here, it will stop running.

In the next article, we will continue our look at MailScanner’s settings.


External Links:

The official MailScanner web site
MailScanner at Wikipedia

Spam Blocking in BSD with spamd: Part Three (Greylisting)

greylistingIn part one and part two of this series, I discussed the advantages of using spamd and some basic configuration steps. In this article, I will cover greylisting in more detail.

The Problem

Spammers try to use other people’s equipment to send their messages. In addition, the software they install without the legal owner’s permission needs to be lightweight in order to run undetected. Moreover, spammers do not typically consider any individual message they send to be important. From this we can conjecture that the typical spam sender is probably not set up to interpret SMTP status codes correctly, if at all.

The current standard for Internet e-mail transmission is defined in RFC 2821. Section 4.5.4 covers retry strategies, and subsection 4.5.4.1 covers sending strategies. This section specifies the following:

  1. Mail that cannon be transmitted MUST be queued and periodically retried by the sender.
  2. The sender MUST delay retrying a particular destination after one attempt has failed. In general, the retry interval SHOULD be at least 30 minutes; however, more sophisticated and variable strategies will be beneficial when the SMTP clients can determine the reason for non-delivery.
  3. Retries continue until the message is transmitted or the sender gives up; the give-up time generally needs to be at least 4-5 days. The parameters to the retry algorithm MUST be configurable.


The Solution

We can use these requirements to our advantage. When a compromised machine is used to send spam, the sender application tends to try delivery only once, without checking for any results or return codes. Real SMTP implementations interpret SMTP return codes and act on them, as explained above. E-mail, like most other Internet services, are described as best-effort services, with a significant amount of design and development being put into make services such as SMTP fault tolerant. Thus, real mail servers retry if the initial attempt fails with any kind of temporary error.
This is what is so elegant about greylisting. spamd reports a temporary local problem to the client. Well-behaved senders with legitimate messages will try to resend the message later, but spammers have no interest in waiting for the chance to retry, since it will increase their cost of delivering the messages. Thus, the spammers will keep hammering spamd, and will get greylisted.


Configuring spamd for Greylisting

Setting up spamd for greylisting is fairly easy, although under FreeBSD, you need to have a file descriptor filesystem mounted on /dev/fd. You can do this by adding this line to your /etc/fstab file (fstab lists all the available static disks and disk partitions and where they are to be mounted):

fdescfs /dev/fd fdescfs rw 0 0

You also want to place the relevant lines in /etc/rc.conf or /etc/rc.conf.local; e.g.:

spamd_flags = “-v -G 2:4:864”
spamd_grey = YES

This tells spamd to enable vpopmail configuration (-v); -G sets the passtime for greylisting to 2 minutes, greyexp to 4 hours and whiteexp to 864 hours (36 days). This means that the client must wait 2 minutes before resending an e-mail to avoid getting greylisted. A client will remain on the the greylist for 4 hours after violating this standard. If the client waits 2 minutes before resending, it will get whitelisted, and remain on the whitelist for 864 hours.

Why It Might Not Work

The reason why greylisting should work is because any standards compliant SMTP client is required to retry delivery after some reasonable amount of time. But there are circumstances in which it may not work. First of all, the first e-mail message sent from any site which has not contacted you for as long as the greylister keeps its data aroun will be delayed for some random amount of time which depends mainly on the sender’s retry interval. There are some circumstances where avoiding even a minimal delay is desirable. In addition, you are bound to encounter misconfigured mail servers which either do not retry at all or retry at all or retry too quickly, perhaps stopping delivery retries after a few attempts. Finally, there are some sites which are large enough to have several outgoing SMTP servers (e.g. GMail); these sites do not work well with greylisting since they are not guaranteed to retry delivery of any given message from the same IP address as the last delivery attempt for that message. The RFCs do not state that they new delivery attempts have to come from the same IP address, so these sites can legitimately claim to comply with the RFCs.

If you need to make allowances for such situations in your setup, it is fairly easy. One approach is to define a table for a local whitelist; the list should be fed from a text file in case of reboots:

table <my_localwhite> file “/etc/mail/local_whitelist.txt”

To make sure SMTP traffic from the addresses in the table is not fed to spamd, you add a no rdr rule at the top of your redirection block:

no rdr proto tcp from <my_localwhite> to $mailservers port smtp

Once you have added these changes to your rule set, enter the addresses you need to protect from redirection into the local_whitelist.txt file, then reload your rule set using pfctl -f.

External Links:

Greylisting on Wikipedia

RFC 2821 – the RFC with the specifications for Simple Mail Transfer Protocol (SMTP).

Greylisting.org – a site devoted to articles and tools related to greylisting.

Greylisting: The Next Step in the Spam Control War – Greylisting site created by Evan Harris, the guy who originally came up with the idea of greylisting. Also contains whitepapers and a fully functional example of greylisting called relaydelay.

 

 

© 2013 David Zientara. All rights reserved. Privacy Policy