Email So Hot it Burns

My patch and files are listed at the end.

WARNING: Something about the patch breaks qmail-remote, which is pretty bad. Quick work around is to save a vanilla qmail-remote and replace the broken one. I'll look into it when I have time, but that's what I did for now. (I'm thinking the problem is with the DNS functions? I haven't acutally done any looking into it though. None. Not even at the core dump.)

o/~ ... and I don't read spam o/~

I've traditionally not had a big problem with spam. I guess I have been lucky--it took almost two years for my school account to get its first piece of spam. Free accounts have been more problematic (my anglefire account was horrible), and long lasting aliases (officers@ for the RPI-ACM) are just horrible. The Exult-General mailing list has more spam than non-spam. I gave a disposable (@nonce) address to a place I rented skis from in January, curious to see what would become of it, and by mid-March I was getting so many worm-related email from their MicroSoft Outlook users that I had to kill the address.

So how to fix all this? SpamAssassin has been a God-send. Very little gets passed it. The things that seem to be the most problematic are emails that are entirely text/html--whic I dump anyway because I can't read them. Between these two things, very little if any spam gets through. Despite that, I also have a RBL check (primarily against DSBL but also a few others) as most of the spam (even that which is caught by other means) is coming through these.

Open relays used to be accepted. Things changed, and there is no valid reason for them any more. Every ISP should have an outgoing SMTP server, and it is not unrealistic to run your own in the modern Internet. Likewise, one could say they were anyone when sending an email--a problem which now results in so-called 'joe-jobs' and also causes problems with the aforesaid MicroSoft users--causing innocent people to be innundated by bounces and replies to email somebody else sent.

Protection from the Heat

Like disallowing relaying, this requires its a new way of administrating a server. SPF (Sender P{ermitted,olicy} Fr{om,amework}) is the answer. SPF requires that users only send email from the servers specified in their domain's DNS entries. There is even a simple to use wizard to use to construct the TXT entry necessary.

I'm not to experience with the the ports system (beyond managing installed files) so that might explain some of the problems I had creating a new port with the SPF patch, but I eventually I was able to build a new qmail binary by downloading qmail, applying the FreeBSD qmail-103.patch, then the patch for SMTP-Auth and SPF. There were a few rejected chuncks in dns.c which were straight forward to fix (I don't know why they failed). The odd thing was that patch didn't create any of the new files, so I had to do taht manually and that took a couple extra minutes. I added the 'nofiles' group (I already had a 'qnofiles' group but I was just wanted the thing installed at this point), and it built and installed fine.

SPF won't look up any mail that's authenticated or for which you allow realying (rcpthosts and localhosts). Any other mail will be tagged with a 'Received-SPF' header (assuming you enable the functionality) and optionally rejected. I'm currently just tagging mail. I plan to move to rejecting anything that fails within a couple weeks. Beyond that, it depends heavily on the current climate. I've currently said my dns record to reject all mail except that sent from my mail server (everything is NATed behind the same IP anyway), which I expect to affect me the most. SMTP-AUTH is the savior here, except RPI's network is broken and won't let you connect to anywhere on port 25.


I merged a few patches to get this to work, but it went pretty quickly and painlessly thanks to the work before me. A virgin qmail-1.03, patch against it, and the patched version are available in my patch section.

This covers the SMTP-Auth patch and the TLS patch which are often included together. It includes Christophe Saout's SPF patch that implements the standards track Sender Policy Framework (I actually used a patch that already had SMTP-Auth and TLS with SPF). Finally, I used an mfcheck patch that was designed to be used against a sysem that already had the SMTP-Auth and TLS patches. Because I'm running this on FreeBSD I also used the qmail-103.patch that is fetched by the qmail port. I'm not sure what this changed exactly, or how it will work on other systems.


To enable MFCheck, echo "1" > /var/qmail/control/mfcheck

SPF does ruin forwarding, and the work arounds on the SPF site did not help. My procmail script will handle one-hop forwards fine (although not any bounces--but there shouldn't be if you don't break your system).