Better Email Security with Procmail - page 2
The filter looks for browser-based attacks, which exploit holes in HTML-aware email readers and web browsers. It also checks for attempted buffer overflow attacks in malformed mail headers. It mungs the filenames of executable files, so that they won't be automatically run. It won't look inside the executables, to spot binary viruses or trojans (like Back Orifice or Netbus etc.). It just adds another layer of protection, so that they can't be either auto-launched or clicked accidentally. This may sound trivial, but when you're dealing with mostly non-technical users, it's remarkably effective. What's more, recent versions offer some level of Office macro virus protection. It may not be the most in-depth scanning ever, but it's a valuable additional line of defence.
Installation is fairly straightforward. I used a Redhat 5.2 based machine, with all of the current update RPMs. The MTA (mail transport agent) in use was the common sendmail 8.xx, using Qualcomm's QPopper as a POP3 server.
This gives me a nice, reliable open-standards based box which will talk to all major mail clients, regardless of breed or platform.
The Local Delivery Agent, as luck would have it, was already configured as Procmail. I checked this by looking in /etc/sendmail.cf , where I found the following lines:
Mlocal, P=/usr/bin/procmail, F=lsDFMAw5:/|@qSPfhn9, S=10/30, R=20/40,
A=procmail -Y -a $h -d $u
Without getting into the nitty gritty of sendmail config and procmail arguments (man pages and bat books are there, for those who are feeling brave), this was fine. If you have something broadly similar, it probably means that it's set up correctly. If in doubt, remember to back up your config files BEFORE editing them. In most cases, this is as simple as doing a
mv sendmail.cf sendmail.cf.bak
The default config for system-wide procmail use is /etc/procmailrc. Since I didn't find this file on my system, it was fair to surmise that its procmail was just delivering the mail without question.
So, I just started to follow the excellent step-by-step instructions. First of all, after making modifications of my own, my newly-created procmailrc was dropped into /etc. Be careful with this; check that you don't already have one, and also, make sure that you DO put it into /etc. Since I was in a hurry, and typically enough for me, dealing with ringing phones and silly questions, I misread the docs initially, and put the file in /etc/procmail. Of course, the effect that this had was.. zilch. Zip. De nada. Procmail carried on as before, delivering quietly to all users.
Having fixed this, I dropped the sanitizing filters into /etc/procmail, and (just in case) restarted sendmail. To test the installation, I renamed a core dump to test.exe, and mailed it to a few users, and sent similar files from other accounts. I repeated the process with various office documents, and everything seemed fine. With files ending with ".EXE", the name is nicely munged to prevent automatic execution. Buffer overruns were stopped without any effort. With those awful HTML mail lists, the HTML was nicely defanged, with vital tags being strategically removed, to prevent the mail client interpreting it as such. Of course, it was a trivial matter to fix the files afterwards, too.
This does raise the issue of inconvience, though. By and large, users resent anything which involves making an effort in any way, shape or form. All security measures involve an inherent compromise between functionality and ease of use. For my part, I would argue that things like Outlook go too far in terms of putting all your eggs in one basket, but not everyone would agree. However, be aware that one size does not fit all, and that obviously you need to tailor things to fit your security policies.
Of course, if you're installing this software on your mailhub, you'll be concerned about reliability. I have been running this software on a smallish machine servicing about 25 users for a couple of weeks now, and it has performed nicely, with nary a hitch. A lot of those users are overly fond of mailing MS Office documents of quite staggering size around, and are very intolerant of the slightest delay, but I haven't had any complaints. The machine only has 64 megs of RAM, and though it touches swap from time to time, it's nothing serious. I'll probably at least double the RAM in the next week or so, since it keeps things flowing nicely.