If you want something done right, you often have to do it yourself. This philosophy led me to address my own frustration about spam/UCE by operating my own mail server. At that time, ISP anti-UCE policy was weak and my own e-mail client's anti-UCE rules were ridiculously extensive. I realized that, even by automatically deleting offensive messages from the server -- even without downloading them first -- I wasn't actually stopping the spam. The problem was that the spammers were succeeding, even if I never read their message; their message had left their machine and was now on mine (or my ISP's). Auto-delete filters aren't good enough any more. I wanted to stop the spammers at the server level. To do that, I needed a full service mail server of my own which I could configure right.
Feeling something like a vigilante, I invested immeasurable time and energy into learning Red Had Linux and any tools I'd need to run my own mail server. I even went so far as to register my own NS server along with a few domains that I'd use to help pay for all this (on my existing Microsoft Windows NT/2000 servers, which had no e-mail server software other than CDO and CDONTS for sending mail outbound). After considering a few mail server solutions, I decided to learn postfix. The price was right and there seemed to be abundant support available. The real selling point for me was a write up on its built-in anti-UCE mechanisms.
Learning any new system natually requires hours of experimentation and, often, frustration. Most of all, I spent many hours reading documentation and searching the web. In the end, I had what I thought was a fully functional mail server. In my test environment on my LAN, the new box was receiving mail from other LAN clients after some troubleshooting. It was working! However, it didn't take long to discover that I was unable to check and read that mail (download and read it from the new mail server onto workstations). I scoured the web looking for "built-in POP+postfix". As you can imagine, there were no useful hits. To my surprise, postfix offered no POP functionality and my Red Hat installation didn't come with anything that fit the bill, either. I felt like such a n00b.
A new search was launched for a suitable POP3 daemon. I asked around at relevant newsgroups, laying my needs out clearly (and drawing the ire of some who prefer to communicate in less complicated vocabulary). The POP3 daemon would have to be compatible with postfix and virtual hosts. It would also have to be relatively small and easy to implement. I was directed to vm-pop3d. Many people offered qmail, but that was an SMTP and POP3 bundle. I was already happy with postfix and didn't want to make a switch. To my delight, vm-pop3d was very easy to install and configure. I was able to send mail to my new mail server and check that mail in short order!
I adopted DNS control of my first domain and, within moments, I was handling mail. Unfortunately, a whole new problem arose very quickly. My users were certainly receiving mail just fine, but they couldn't send any messages through the new mail server. Everyone but me -- on the LAN -- was getting, "Relay access denied." I didn't know why, so I returned to the postfix documentation, Google, and the newsgroups. Fortunately, my users were patient while I learned all about open relays and access control. I puzzled over why the introduction documentation for postfix didn't say anything about needing yet another utility to facilitate "normal" mail usage. For that matter, I became frustrated that there weren't any bundled recommendations at postfix.org (at that time). I was at a loss, but a nice individual stepped up and helped me out.
With Stephen McHenry's help, I was up and running with his version of popauth within the week. I would have implemented it faster, but I was forced to learn about regular expressions, Perl, and the benefits of FOSS as quickly as I could. Two books later (Learning Perl and Programming Perl by O'Reilly), I knew enough to find yet another problem. My POP3 daemon, vm-pop3d, didn't log authentications on a single syslog line. It was at that time -- the first ever -- that I actually appreciated Open Source. I had enough C programming experience to patch the vm-pop3d source and recompile. In short order, the whole system was finally working!
I spent the next couple years fine tuning the whole system (which was, at that time, all running on a single server). As the rate of messages I handled (and the number of domains I managed) increased, I returned to my original purpose: to fight spam. I learned about RBL providers, content filtering, and that there is an unfortunate tradeoff between successful blocks and false positives. After a fair success of keyword-based filtering using header and body checks, I began to find specific situations that postfix wouldn't handle as I needed. I turned to the popauth code. I realized that, because popauth received maillog events in real-time from both postfix and vm-pop3d, I could use it to extend the functionality of both. The result is popAuth3, a near complete rewrite of the original source provided by William R. Thomas.
That was in 2002. Since then, my home network has grown substantially -- now at seven servers. My e-mail handling solution today requires four distinct servers and a complex mail routing configuration. Today, I still use postfix and popAuth3, but I have added MySQL, Courier IMAP, MailScanner, SpamAssassin, Razor, Pyzor, DCC, ClamAV, BitDefender, Apache, PostfixAdmin, and SquirrelMail. I no longer use vm-pop3d. Mail relay authentication is no longer handled by popAuth3 as I don't use POP-before-SMTP. Instead, I'm using SASL/TLS and my mail servers all utilize SSL communications -- even internally from server to server. This highly secure scenario works wonderfully and I can handle e-mail loads that I never anticipated when I started this project. While popAuth3 is just one out of many key components, its role is no less important.
Even at the time of this writing, the fight is not over. We are all faced with the "better mousetrap" parable. However, what I have today is strong enough for me, and modular enough to evolve easily. In my pursuit for the best possible solution, I have turned to you the reader. Help me take this system to the next level. Our community, at large, could benefit from our mutual and cooperative efforts.
Contributing Authors: William Kimball