What Is MailScanner?

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 internet service providers (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. It comes with support for any combination of 25 different virus scanner packages, including the free ClamAV scanner, and its design allows the use of multiple virus scanners in parallel to increase the level of security.

Protection against spam is mostly based on the widely acclaimed SpamAssassin package, which again is free and open source. It is supplemented with fast blacklist lookups that can be used to reject a large proportion of messages with minimal overhead.

Protection against malware is provided by a very wide selection of checks and tests, ranging from simple filename rules to content-based file type detection. It also incorporates one of the most sophisticated phishing detectors available anywhere. Many other checks and tests can also be run against messages, far too many to list here.

MailScanner is highly configurable using a very easy-to-use system of rulesets. Virtually every configuration option can, for example, be controlled on a per-user, per-domain or per-IP basis.

MailScanner is extremely easy to integrate into your existing mail transport system, requiring no modification of existing sendmail configurations. Other MTAs require only minor modifications to configuration files, and these are all well documented both online and in the MailScanner book, available direct from the MailScanner web site.

MailScanner is completely free of charge, requiring no licence, installation or subscription fees. Free assistance is provided through mailing lists and instant support is available through a dedicated IRC channel, which is monitored 24 hours per day. A range of companies also provide commercial tailor-made support contracts. It is currently used by a very large selection of organisations around the world, from small companies and ISPs to the US Government and Military.

Best Practice using MailScanner

The Internet sucks. It’s a horrible, nasty place where people try to do unspeakable things to each other, and that’s just craigslist. Seriously, though, there are some pretty nasty things going on every second of every day. Viruses, worms, script-kiddies and other threats are constantly trying to get past defensive barriers, and more times than not it’s through email that these attacks are launched.

There are many ways to attempt to keep these things from affecting your users, some good, some bad. But how are you to know which is which? Who polices this sort of thing?

The good and the bad news is: nobody does. It’s the wild west, and you’re expected to be Clint Eastwood. How cool is that? Grab a cigar, throw on a colorful Mexican poncho and load up your 6 shooters ‘cause we’re going spammer hunting.

What the layperson, and the budding admin, usually fails to understand is that the Internet is a co-operative. Things work because we have all decided on inter-operable standards, and the reward for not complying is loss of connectivity.

There are documents that describe these standards and they attempt to tame the wilds of the Internet. These documents are called RFCs, which stands for “Request for Comments” and have been how the Internet has been administered for several decades. (The first RFC, “RFC 1 - Host Software” was written on April 7th, 1969 by Steve Crocker.)

Unfortunately, RFCs are sometimes vague (usually this is intentional – it allows for flexibility and creativity) on the details in certain areas. Areas such as e-mail virus warning messages, bouncing viruses and spam, SPF records and more. So it is up to the individual administrator to interpret these RFCs and come to a conclusion as to how to implement a certain feature or function. The course to follow is of course “the best one” – but how do you know which one is the best one? Why, that’s what this page is for. We’ll just tell ‘ya, how does that sound? Remember that most things on this page are interpretations of what the “best practice” is, and in some cases there is vehement debate. This is just what the MailScanner community has determined to be the best practice in regards to e-mail administration – or at least the best practice according to the last person to edit the Wiki.
Have Valid RFC Contact Email Addresses

Have valid, case insensitive postmaster@ and abuse@ addresses. This is not a suggestion; this is a requirement to be RFC compliant (RFC 2142.) These addresses must not point to /dev/null and mail sent to these addresses must be read periodically. You can have an autoresponder, but that autoresponder may only make suggestions like “Your request will be processed, but for faster response use for correspondence in the future.” You may not say “Please mail for a response” since that does not make it clear that the issue will be dealt with. See RFC 3834 for specific recommendations on autoresponders.

These addresses are used by other admins to contact a responsible party. It is highly irritating to get a bounce to a postmaster@ address, it immediately screams “the admin of this domain needs a helmet to go up and down stairs.” Don’t be that guy.

RFC 2142 defines other standard addresses that you may or may not want to implement, depending on the services offered by your domain. For example, “hostmaster@” is required if you run a DNS server and “webmaster” is required if you run a web server. Please read RFC 2142 for more information.

It is also a good idea to register your abuse@ address
Do Not Send Virus Warning Email

For the love of whatever you hold personally dear, do not configure your system to send email virus warnings by default.

“Why?” I hear someone asking. Let me tell you why: it’s part of the problem, not the solution. Out of the huge volume of viruses that are going to be hitting your mail server, 99.9999999% of them are going to be viruses that forge the senders email address. So your warning is going to go to the wrong person.

Some person who isn’t infected is going to get a warning going something like this:

PANIC! PANIC! PANIC!!!!11

You sent us a virus! Call your administrator who’s at
home sleeping RIGHT NOW so that he can scan everything
on your network! Don’t let him hang up until you’re

sure he’s awake and dressed and ready to come in and
put out this fire ohgodrightnoworwe’reallgonnadie!

We could easily give useful information here, but
we’re not, just so your administrator has a challenge
proving that whatever the hell it was that generated
this message, it didn’t come from your network!

Also, since you receive so many of these misdirected
warnings, you are now expected to ignore all of them!
Even the ones that may indicate a legitimate problem!
There’s no way for you to know which are legitimate
and which are not! Either way, you have no good
course of action!

PANIC! PANIC! PANIC!!!111111one

This message brought to you by False Alarm Anti-Virus
www.falsealarmav.com__
Call us today for a free quote!
www.falsealarmav.com__

PANIC!!!! TODAY!

So, you can see why this might be a bad idea. There are so few non-forged viruses going around these days that it’s a trivial matter to keep a list of the viruses that don’t forget and notify only those senders. Anything else is a waste. If you feel so inclined, feel free to send notices to yourself, then you can track down the IP of the infected machine and inform the responsible party at the ISP or corporation that owns the IP. I do this all the time, and it’s a great way to find people who aren’t RFC compliant.

As if that wasn’t enough of a reason, consider that over half of the traffic on any given Internet backbone is email, then consider that more than half of that email traffic is unwanted spam and viruses. If you’re sending invalid warnings you are contributing to all that unwanted email. Couple that with the fact that most of these warnings have a reference to the AV product used and guess what? You’ve just become a spammer, Spammy Spammerson. Now you’re on my “list”.

Lastly, RFC 3834 states in part that “In general, care should be taken to avoid sending useless or redundant responses....” I’d say that virus warnings that you know are going to the wrong person are rather useless. So don’t do it.
Have a reverse lookup that matches your HELO/EHLO.

Many of these policies stem from the fact that spammers will forge addresses. When you send mail to a system that doesn’t know you, you’ve become a potential spammer. You must show that you can be trusted before you will be trusted, and one way of doing that is to have a reverse lookup that matches what your system says it is. Unfortunately, this may be a problem in virtual hosting situations. At the very least make sure that your MX is listed in DNS as the name that will respond to the HELO. See RFC 2821 for more information on the SMTP command HELO.
If using a mail gateway, firewall your destination.

If you have a system where one machine receives and scans the mail, then forwards it to another server for delivery, make sure that the delivery server will only accept connections from trusted hosts, ideally only the final scanner machine. It wouldn’t do you much good to go through the trouble of scanning your mail for viruses and spam, only to have a bunch of crap sent directly to your delivery server by some jerk. Spammers don’t follow the rules, and your MX priority means nothing to them.

You should only expose the services that you need to expose. While it may be nice to have ssh open on your mail server, you should at least firewall it to only allow connections from specific known addresses.
Use SPF Records

These have nothing to do with UV protection. Just so you know. The “official” acronym expansion for SPF is “Sender Policy Framework” but they are really “Sender Permitted From” records to many of us. They are nothing more, really, than a TXT DNS record for your domain that says “if email is being sent and it says it’s from me, it must come from one of these hosts”. This framework will allow domains to publish who is allowed to send mail, making joe-job attacks and forged viruses a thing of the past. First, however, there must be a decent amount of domain admins implementing this feature, so get cracking, bucko. Once you’ve set them up and allowed time for DNS to propagate, you can test your SPF records at dnsstuff.com.
Use SMTP-AUTH for Roaming Clients / Don't be an Open Relay

Got people in the field who need to send and receive email? If they must do it from a client program like Outlook, Outlook Express, Evolution, Thunderbird, or whatever, make sure that you’ve set up SMTP-AUTH or some other way of keeping your MX from being an open relay. You could also set up some sort of web mail solution like SquirrelMail, or set up a VPN and only allow senders from inside your IP space. But make sure the only people who can send mail from your mail servers are people you’ve explicitly allowed. Anything else and you’re an “open relay” which means anyone can send mail through you. If you don’t understand why this is a bad thing, leave your credit cards and keys in plain sight in your unlocked car and marvel at how crappy human behavior can be.

You can also set up SMTPS/TLS and MSA for external users that use ISP‘s that have blocked off port 25. SMTP/TLS Howto for Sendmail MSA on Sendmail, and SMTPS/TLS and MSA for Postfix. However, you should note that if an ISP has blocked port 25 then they probably have a policy against sending mail to mail servers outside of their control – you may want to ask them for a policy exception, just to be nice.
Compartmentalize Your Servers

You know those all-in-one server packages that put a file server, database server, web server, mail server, dns server, usenet server, print server, server server and other servers all on one machine? They are a really bad idea.

One reason being that if the hardware fails, you’ve lost your entire network instead of just a subset. That’s never a good thing. The other being that it’s impossible to seperate internal services from external services. You need to be able to do that for security purposes. If you have a single machine exposed to the Internet with multiple services running, that greately increases the chance that someone will exploit a vulnerability, compromising all your network services.

The solution is to comparmentalize as much as is practical. Ideally you’d have one server per service, but in most places that’s just not practical. At the very least, you should have one server for external services (mail, web, dns, etc) and another for internal services (file and print serving, internal instant messaging, database, etc.) Limit your internal connections and there’s less chance that your internal servers will be compromised.

A lot of companies use a groupware server like Microsoft Exchange or Lotus Notes. You can safely keep those machines inside your firewall and put an SMTP server outside (running MailScanner, of course) the firewall, then forward your mail to your groupware server. Childish accusations of stability aside, Exchange and Lotus Notes are very complex software packages. The more complexity in a piece of software the more vulnerabilities it will have, the software being written by Microsoft or not – the same could be said of an open source group-ware package. Regardless, it’s important to only expose the absolute minimim of services to the outside world.

Please note that every place “outside the firewall” is mentioned the phrase “outside your internal firewall but inside your DMZ” is implied. This was necessary to avoid redundant typing.

FIXME Add links to articles supporting compartmentalization and explaining modularity in more detail. Add links to MS, IBM, MailScanner, “script kiddies.”
Don't Bounce Spam or Viruses

Mostly this is in the “don’t be part of the problem” camp. Bouncing spam and viruses contributes to the joe-job problem, wastes bandwidth on delivery failure messages that will never reach a valid recipient and generally irritates people who receive the bounce but never sent a message. Don’t do it. By the time you’ve processed a peice of mail and determined that it’s either spam or a virus, you’ve determined that it’s either spam or a virus. Why would you then send that garbage on? Just dump it to /dev/null and get on with things. The chances of a false positive are very low, especially on viruses. If you’re worried, you can always have a set of rules that will bounce on, say, filename rule triggers, but still junk any virus message as determined by your virus scanners. Once again RFC 3834 may be referenced in regards to this. A bounce is nothing more than an autoresponder – and these sorts of bounces are useless. If you must bounce this sort of content, do not bounce the attachments. You will most likely get onto a blacklist very quickly.
Use Multiple Virus Scanners

If your budget allows one virus scanner you can afford at least three, since ClamAV and BitDefender are free. There’s no reason not to use multiple scanners. If one scanner misses something or is temporarily not working, you’ve got more chances, plus your basic rules should catch any executable and stop it before it enters, whether it’s caught by your scanners or not.
Keep your software/your knowledge up to date.

It’s been said many times, but in case you’re one of the three people on the planet who’s never heard it: Security is a process, not a product. You can’t set this stuff up and let it rot. Spammers and virus writers are constantly coming up with new tricks to get past your defenses. A year old MailScanner setup, while still effective for old stuff, is vulnerable to new attacks. Keep things up to date. This doesn’t mean that you must be bleeding-edge constantly, but once a month or so check your versions and upgrade if need be.

It should go without saying that you should keep the rest of your system up to date as well. The last thing you want happening is to spend a week setting up the perfect mail filter, only to have someone compromise your box with an ssh exploit. Please see your vendor or system documentation for solutions – there are many automated solutions for all relevant versions of Unix and Unix derivatives.

Your brain is almost as important as your software. You must keep yourself abreast of changes in the industry, new vulnerabilities, new exploits and new tools. One great way of doing this is to join the MailScanner mailing list where we cover so much ground we occasionally discuss overpriced ergonomic chairs. You should also join other more security oriented mailing lists, and take advantage of any notifications that your vendors may make available.
Test your setup frequently.

Almost a continuation of the previous topic: test your stuff. You’ve spent hours setting up spam and virus blockers, you’d better make sure it works before you accidentally send your bosses “How to Irritate your Employees” monthly e-newsletter to the bit bucket. There are a few places you can go to test:

How to test your setup with telnet
http://www.dnsreport.com
http://www.dnsstuff.com
http://www.samspade.com
http://www.abuse.net/relay.html
http://www.webmail.us/testvirus

One more open relay test you could perform from a shell on your local machine:
telnet relay-test.mail-abuse.org

Please note that the testvirus site is for testing only. The only “virus” sent is the Eicar test virus, which may or may not be caught by your virus scanner. Eicar is a safe piece of code that many AV companies have decided to catch for testing purposes.
Confidentiality Disclaimers are Annoying

This is probably the most controversial topic on this page, but I think it needs to be said: confidentiality disclaimers are dumb, especially when they’re sent to mailing lists. They’re not legally binding in any country that I know of, and they just make a lot of noise. First of all, if you’re sending unencrypted messages across the Internet and you’re under the delusion that your messages are safe from prying eyes, you need a reality check – fast. Your message is available for anyone with a packet sniffer to see, at any point across the path that the message takes. If you want confidentiality, look into a public key encryption program like gpg.

If your boss or legal department has required that you set this up then there’s nothing you can do about it, and I feel for you. However, you should at least point the responsible party to the following sentence, so that they may be educated. People are laughing at your precious disclaimer.