Rocking A New Spam Filtering Server

If there is one thing I hate, it is spam. New laws and random enforcement is fine, for all of ten nano-seconds, while stronger control over what ends up in my inbox lasts for ever. This is largely what drove me away from the flailing mess known as Spam Assassin. While it might make a good tool for some, I simply can not take the missed email anymore. In short, it sucks and even with the Bayesian training addition, it still fails to do anything right.

This brought me back to POPFile. However unlike last time where I found myself being frustrated with trying to train and maintain multiple installations on multiple machines, I instead opted to do this right. Seeing as I already have a dedicated Linux server for video streaming and other non-mission critical stuff, I decided to put POPFile to work on it, rather than limiting myself with multiple POPFile installations yet again.

Another thing I was bent on was making sure I would be able to tap the POPFile server, even when I am away from home. This was key for me. But I also needed to protect my POP mail password by using the existing SSL provided by my email provider. I may not feel the need to protect the contents of my email messages, but I will be darned if I am going to broadcast my POP mail password with each mail check!

1. Setup my POPFile server. I keep two networks here at the house. One that is completely cut off from the Internet and another that is not. I used a dedicated server (code for really old PC with Ubuntu on it). I installed POPFile which was as easy as I remembered. I then rebooted the server box and made sure that 127.0.0.1:7070 was coming up in my browser (Windows users might find the needed port as :8080, but I forget).
2. Open up some ports on the server. In my case, using Gufw makes this a snap. I simply made sure I had opened up 7070, 7070 and 995. Obviously this is not needed for a local POPFile install, but it is to use POPFile as a server with a firewall (IPTables in my case).
3. Static local IPs or reserving them, router magic. Some will argue that this is unneeded, but I find it makes life massively easier. Thankfully my router is not all that bad with regard to features, so I was able to reserve the IP address currently used for my POPFile server. From here, I head over over to my router’s virtual server settings. I then create a setting called POPFile, set it to use the local IP I reserved currently assigned by DHCP from my router and set it to watch for port 7070 on both public and private, for TCP. And yes, based on the fact that I keep my other machines well insulated, I set it to “allow all” on that machine only.
4. DynDNS - it is a wonderful thing. I head on over to DynDNS.com and created a free account. I setup a host by choosing to Add a host service. Get something like jimbob.dyndns.net or whatever, then I am ready to rock. (Note - it seems that I am not needing to install any client solutions for this service as DynDNS appears to keep an eye on my everchanging external IP address for me.)
5. Checking things out. Before even bothering to set anything up, it is time to check a few things: first, goto the http://the-internal-ip-address-for-your-server-pc:7070 - you should be able to connect -and see the web admin interface? Great, now goto http://your-new-dyndns-url:7071 . On Ubuntu based servers, you should see something like:

+OK POP3 POPFile (v1.0.0) server ready
-ERR unknown command or bad syntax
-ERR unknown command or bad syntax
-ERR unknown command or bad syntax
-ERR unknown command or bad syntax
-ERR unknown command or bad syntax
-ERR unknown command or bad syntax
-ERR no response from mail server

6. Email client setup. Due to the fact that there are countless email clients, I am only giving the info on what to enter. Where to enter that info is up to you. Here is how I did it:

Server - your-new-dyndns-url:7071 (note the lack of http here)

Username -  (non SSL) mail.whatever.com:me@whatever.com.com (note the : and note that the username is now the ISP mail server followed by the user name of that account)

Username -  (w/SSL) mail.whatever.com:995:me@whatever.com.com:ssl (in the mail client, the SSL setting provided as a pull down MUST BE off or the “:ssl” setting will not work)

Windows server users: read up here as there are differences in the server settings. Never tested this with a Windows box, so other than the web admin interface using port 8080 instead of 7070, I am not sure how your username is to be setup for SSL on a Windows server box.

Here is why this rocks. First, I can now use this server on a Windows, Mac or Linux client - it really should not matter. Overall, the basic mail client settings should remain true. I do not believe there will be any differences in setting up the server and username settings as outlined above as the ports and server address remains a constant on all client platforms since the server platform is Linux.

You will want to train POPFile first, before taking it out on the road. Why? Because I purposely never setup a DynDNS link for the web admin - it is not encrypted and frankly, the password protection is simply too weak to use outside of a firewalled LAN. Do the bulk of your POPFile server training before taking the laptop on the road. It learns very quickly if you stick to minimal buckets. What is a bucket? learn more about the app here.

The second reason this rocks is that I no longer need to worry about keeping my spam filtering in sync in between PCs - yes, it can mix email client accounts just fine. Yeah, I could use someone else’s server solution, but what fun would that be?