A spam-checking POP3 proxy server
The problem
I have a similar setup in my home network as many other people. I have a broadband router, which connects me to the internet. I have a number of client PCs, which run assorted operating systems, mostly various flavours of Windows. And I have a GNU/Linux (Ubuntu) machine, which I use as a file server and for various other services.
If someone sends me an email, it lands up in a POP3 inbox provided by my ISP. This is convenient as it means I have access to their webmail features, they provide list server capabilities, one-click setup of additional mailboxes, a number of other facilities that I like. However, like most people these days, I also get an awful lot of spam, and although my ISP also provides an anti-spam solution, they charge extra for that and I'm always looking for a free way to do things!
The solution
Undoubtedly one of the better (if not the best) anti-spam products currently available is SpamAssassin. It's open source, written in Perl, very configurable and very powerful. It's also very largely a Unix product -- SpamAssassin certainly can be made to run on Windows but it's not a simple procedure, especially as most Windows installations won't even have Perl available.
So how to use the power of SpamAssassin for the Windows computers on my network? One solution would be to install a POP3 server on the Linux box and use Eric Raymond's Fetchmail to retrieve mail from my ISP, passing all mail through SpamAssassin. This would work, but it would mean I lose features such as the webmail my ISP provides -- yes I could set up a webmail system on the Linux machine, but that's an extra application to maintain, and an extra service that I'd have to expose to the dangers of the wild internet. Using my Linux machine for POP3 would also mean maintaining an extra set of config files which I'd need to keep in sync with any additional mailboxes created at the ISP, and so on.
The obvious solution (to me anyway) was to use the Linux box as a proxy to the ISP's mail server. My Windows clients would connect to the Linux box, which would then connect to the ISP POP3 server. Any mail retrieved would be passed through SpamAssassin before being returned to the client. I wrote myself a Perl program to do just that, which I've gradually refined over the last year or so to work in the way I want.
But it still had its downsides. The POP3 server was set in the proxy's configuration file, which meant that I couldn't use it to proxy to any other POP3 servers. But now I think I've stumbled across a solution that overcomes that (and other) problems, and uses freely-available software.
The product I found that makes this all possible is an amazing multi-purpose proxy called DeleGate. I originally found it when I was looking for an HTTP proxy / cache that wasn't quite as heavyweight as Squid, but it's got all kinds of potential.
The implementation
Make sure you have both DeleGate and SpamAssassin installed and working correctly on your Unix system. Both pieces of software have good, detailed installation instructions so there's no point me repeating them here.
Once that's done, you need to create a DeleGate Filter Control File which we will use to tell DeleGate what to pass through to SpamAssassin. Fortunately, the format of that file couldn't be simpler:
#!cfi
Message-Filter:/usr/bin/spamassassin
The first line merely identifies the file and the second one should point to your spamassassin binary -- of course if you make use of SpamAssassin's client/server feature this could just as easily give the path for spamc. Save the above two-line file somewhere convenient (eg /etc/delegate/pop3.cfi (the ".cfi" is for Common Filter Interface).
Now you just have to start the DeleGate program with the relevant options:
/usr/bin/delegated -P110 -v FTOCL=/etc/delegate/pop3.cfi SERVER=pop
/usr/bin/delegated is the DeleGate binary.
-P110 is the port to listen to. I chose 110 as it's the standard POP3 port, but anything will do. Of course if you want to use a privileged port you'll need to be root.
-v merely puts DeleGate into debugging verbose mode. Useful while you're checking everything is set up right. Once you're happy with it you'll probably want to remove that so it can go into the background and write output to logfiles rather than the terminal.
FTOCL=... - the path to the Filter Control File that we created above. This option tells DeleGate we're creating a Filter on anything sent TO the CLient, and that the details of the filter should be read from the file (which says that only the (mail) messages should be passed through to SpamAssassin).
SERVER=pop tells DeleGate what sort of proxy server it should be running as.
There's one further thing to do -- but this is done on the mail clients running on your Windows (or any other OS!) machines. You have to change the username from being mypop3name to being mypop3name@mypop3serveraddress. This is so that DeleGate knows which POP3 server to proxy to, neatly bypassing the problem that I'd encountered in my self-built solution I mentioned earlier. If the mail client doesn't like the '@' sign in the username, a % or # sign can be used instead.
If you have lots of clients to alter the settings for, or are simply too lazy to change them and most of them go through to the same POP3 server, you can set up a default for DeleGate to use. Remove the SERVER=pop bit from the call to delegated and replace it with:
MOUNT="* pop://yourpop3server/*"
The MOUNT command is one of the most powerful options that DeleGate supports, allowing you to proxy all kinds of things in clever ways.
And that, as they say, is that. Your Windows users can carry on using their mail clients in exactly the same way as before, only now all their mail traffic will be scanned by SpamAssassin.
As for DeleGate, well I think it's a wonderfully powerful program. Its syntax is somewhat idiosyncratic and it takes a while to get to grips with, but it's worth persevering as it can make many difficult things possible. I for one am very glad I found it!
