Ever since Dreamhost moved me to a new server without warning, I’ve been trying to get my custom SpamAssassin install working the way it used to. I’ve finally succeeded, but it hasn’t been easy…
Because of the new infrastructure plan, new email accounts and shell accounts have been completely isolated. I thought that I wouldn’t need to worry about that, since I had an existing account with shell access to my email, and the change was only supposed to apply to new accounts. Unfortunately, I was completely wrong. In the most recent newsletter, Dreamhost was soliciting volunteers to move to their new servers. Less than one day later, I was having numerous issues with email and my web sites, and it dawned on me that they had moved me to new servers without any kind of notification!
After updating my DNS and changing some email client settings, everything was almost back to normal, except for my custom SpamAssassin install, which was completely broken. Getting it working again would entail a convoluted method of forwards, procmail recipes, and filters on Dreamhost’s panel. Read on for further details…
Initially, I intended to implement the process laid out by KRKeegan on his site. After my first (and hopefully last!) experience with mail loops, I came up with a different plan: all of my email aliases had pointed to my main account. I renamed my main account, and had all of my email aliases point to a new alias, which would simply forward all mail to my shell account. Later, my shell account would deliver the filtered messages to my main email account.
Upon arrival in my shell account, the .procmailrc file would pass the mail through SpamAssassin, and then (instead of simply filing the message into my Inbox, LikelySpam, or MaybeSpam folders) it would use formail to add an X-Sort: LikelySpam or X-Sort: MaybeSpam header, depending on the X-Spam-Level: header. It would then be forwarded on to my main address.
Using the “Email filters” feature on Dreamhost’s web panel, spam messages are delivered to a LikelySpam or MaybeSpam folder, if the relevant header exists. (I had to do it this way, instead of directly from the X-Spam-Level: header, because Dreamhost’s Email filters feature won’t allow the use of asterisks, which is how the spam score is expressed in the X-Spam-Level: header)
My final challenge was to get Bayesian training to work again. Utilizing the instructions on Apache’s web site, I was able to set up a cron job to fetch messages from my LearnAsSpam folder, feed them through sa-learn, and delete them from the server. (But first, I had to install fetchmail, since my shell account server lacks a system-wide install of it)
It’s been a learning experience, for sure. I’m not upset that Dreamhost made the infrastructure changes that they did, but I am extremely frustrated with the fashion it was implemented. I do give props to support, who gave relatively prompt (and helpful) responses to my numerous inquiries over the past few weeks.
Tags: dreamhost