Ok, this will mean nothing to the non-technical readers out there, but I am a very happy sysadmin today. I finally managed to put together a rig that will scan all our e-mail for viruses and (probably) spam without having to rip out our entire network infrastructure, spend $$$, or even disrupt things all that much. This means no more KLEZ!!! No more panicked calls from my users thinking they've got this stupid thing. WOOHOO!

Not only did I get the scanning thing working, I also got the sendmail server to talk to our LDAP server to do AUTH for our mobile users. This is cool, because otherwise I would've been subject to a nightmare of support calls when all these mobile users quit working. Say YEAH!

Total cost: $250 because the scanning engine isn't free. This is way cheaper than any other solution and will result in zero disruption to the network.

Because other sysadmins might be reading this, or might be searching, here's what I did:

The first step was easy... all new RedHat Linux systems come with Sendmail already configured and running. To scan for viruses I found this extremely slick scanner for sendmail called MailScanner. I put this combo on our public web server, which runs a mail account that was getting dozens of klez messages a day, and it worked like a champ.

So, I wanted to work it such that one of these scanners would scan for all of our mail, not just from one address. The problem was that our main mail server isn't sendmail, it's Netscape's Messaging Server. I actually like the netscape product, but more importantly e-mail is second only to oxygen around this place so I didn't want to tinker with something that was otherwise working.

So I hatched a plan. I'd put up a mail server that all outside mail would go to, and this "outside" server would route mail to our "inside" server. The "outside" mail server would hold my tres slick scanner, and the "inside" server would remain what it always has been, the Netscape system. This is actually a really common setup for many organizations, it's called a "mail proxy server".

The problem is that sendmail is complicated. I mean really complicated. You know you're in trouble when the books you buy tell you "this is going to be really hard, we're sorry, but it just is". I was slowly pushing my way through the bat book when the author of the above mentioned virus scanner gave me a really elegant hack that made it all extremely easy.

To quote from his e-mail:

There is an easy solution to this problem. Say "Oh, goodie".

For outgoing mail, set the "smarthost" on the "real" server so that it sends everything out via the "mail proxy server".

For incoming mail, setup your MX records like this:
@ IN MX 10 real.server.name.
IN MX 20 mail.proxy.server.name.
Then set up your firewall so that only "mail.proxy.server" is accessible on its SMTP port from the outside world. "real.server" must not be accessible on port 25 by any machine on the outside world.

One of the default jobs that any MX host will do is send its mail onto a better MX if it can (which "mail.proxy.server" can, as 10 is better than 20). By firewalling off the primary MX from the outside world, you force all incoming connections to back off to "mail.proxy.server", which picks up the mail and can reach "real.server".

That way all your incoming mail will be scanned :-)

Like I said, it's technical, and most of you won't understand it, but those of you that do, who didn't just automatically know about this, will be saying "wow... cool".

So that was it, but not quite...

The other problem is that I have a lot of mobile users here. Mobile users who make the proverbial "box of rocks" look like a group of Nobel laureates. They have to be able to send mail from the road out to the world using our mail server. This is called "relaying", and if you screw up relay configurations you end up opening your server to the world. Nothing like someone you don't know using your mail system to dump 100,000,000 (really!) messages on the world.

I honestly thought about just saying "you can't do it... time to learn a little bit about the computer", but then realized what a support nightmare it would be. So that's when I got extra clever...

Our current mail server uses an LDAP directory to authenticate users (it's why I like it), so it stands to reason that the Sendmail server should be able to do the same thing.

The short answer is, it does. The long answer is, it's not easy. I found this helpful post from a guy that did it 2 years ago. However, times have, as always, changed, and I found out the hard way that his method isn't exactly right today. So, for all you poor bastards that need to get sendmail talking to an LDAP directory today, here's my notes:

• Redhat 7.2 and up already comes with everything you need installed, compiled, and configured. You do not need to re-compile sendmail (1 day wasted), or download and compile NSSLDAP or PAM LDAP (1 more day wasted). You may not even need to download and compile SASL, but I did anyway.
• You do not use pam.conf. Instead go to /etc/pam.d and edit smtp. Remove what's in there and put this in instead:

  auth required /lib/security/pam_ldap.so service=system-auth
  account required /lib/security/pam_ldap.so service=system-auth
  auth sufficient /lib/security/pam_ldap.so
  

• For some reason my m4 thingy isn't working right. Won't comment or uncomment features correctly. If you find you can't get sendmail to reply back with AUTH codes when you give it the ehlo command, check your sendmail.cf file to make sure your auth options are actually turned on (1 more day wasted).
• If you find sendmail won't answer to anything but localhost, even though you commented out the right line in sendmail.mc, again check the .cf file. My mc file lied.

And that's it! Works fine now (for now), so tomorrow or the next day we're going to be triple-protected.

I hope someone out there finds this useful. If you have questions, let me know, I'm happy to give back to the community.