Dave Schweisguth in a Bottle

8 Feb 2011: Caveat lector! I no longer recommend the setup I described in this post. See the followup for the reason why not. The details in this post may still be useful to some, however.

I run my own domain name service (DNS) and mail service (sendmail) on my home Linux server. Until recently I filtered spam with spamassassin, but the spam that it let through grew until it was time to find another way. I could lower spamassassin’s bar for considering something spam, but it would then not be easy to rescue good mail that was wrongly considered spam. GMail allows you to forward mail from elsewhere to it and retrieve mail via POP or IMAP and it has severe but easy-to-tune spam filtering, so that’s what I used.

In my first setup, I aliased my home account to my GMail account in /etc/aliases and used fetchmail to pull mail back from GMail to home. Initially, that appeared to work great: I got all of my mail just as before and no spam at all (in fact, I had to spend some time rescuing bulk mail that wasn’t spam from my spam folder, but GMail knows about that now).

However, I had a residual problem: some of my filtered emails had an Authentication-Results header indicating that, according to the SPF record for the sender’s domain, my home server was not allowed to send mail from the sender’s domain. Forwarding through sendmail results in email that says it’s from one domain (the original sender’s) coming from another (that of the forwarder), which is exactly what SPF is supposed to prevent. All of my mail was getting through, either because it came from domains without SPF, because it came from domains with SPF configured to ‘softfail’ (that is, to be considered as only advisory), or because GMail wasn’t acting on SPF advice. (I have no evidence that the latter was happening; I just never ruled it out.) Although I was getting my mail for now, I might lose mail if any of several things changed.

This is a known problem. There are two general ways to fix it: use SRS or remail mail instead of forwarding it. SRS seemed to be too complex, so I went with remailing. To cut to the chase, here’s the necessary configuration:

In .procmailrc:

:0
* ^X-Spam-Flag:.*YES
data/mail/spam

:0
* !^From dave[ ]
* !^FROM_DAEMON
! dschweisguth@gmail.com

Last things first: The last rule forwards (actually remails) all of my email to my GMail account, unless

• it’s from “dave” (my actual username on my home server). (The “[ ]” following “dave” represents a single space in a way that isn’t chopped off when procmail reads it out of my .procmailrc.) This prevents email delivered locally by fetchmail (see below) from being forwarded right back to Google.
• it’s from MAILER_DAEMON. This prevents email rejected by Google (for example, because it has a forbidden attachment, such as an executable) from being forwarded right back to Google.

The first rule saves mail identified as spam by my local spamassassin to my spam folder. This rule was here before I hooked up GMail. I left it in since it seemed impolite to forward known spam to GMail. (One of these days I’ll turn this rule off and see if I notice any difference in how GMail handles my mail — that is, if forwarding more spam causes GMail to consider more of my real email spam.)

Note that my sendmail had already been configured out of the box to use .procmailrc if present, so I didn’t need to do anything for procmail to kick in.

In .fetchmailrc:

defaults mda "/usr/bin/procmail -d dave"
poll pop.gmail.com protocol pop3 username exampleaddress@gmail.com password thepassword options ssl

The “defaults mda” line tells fetchmail to deliver mail straight to my local mailbox (using procmail) rather than calling sendmail again, which would forward the fetched mail right back to GMail. Since I’m using procmail for local delivery, I need the condition in my .procmailrc (above) that doesn’t forward locally delivered mail. Without that, fetched mail would be sent right back to GMail, where it would be a useless copy of the original message that had just been fetched.

And finally, in my crontab,

0,10,20,30,40,50       *       *       *       *       fetchmail -s

runs fetchmail every ten minutes, which is the fastest rate at which GMail wants to hear from a POP client.

Now my mail has a clean bill of health from SPF:

Authentication-Results: mx.google.com; spf=pass (google.com: domain of daveATschweisguth.org designates 66.127.226.140 as permitted sender) smtp.mail=daveATschweisguth.org

(@ replaced by AT to foil address scrapers.) Even if email senders or GMail tighten up the way they use SPF, my mail should continue to get through.