Xblog

I did some more tweaking, and concluded that my best moves were the following tweaks:

• Reduce the # of slave processes for the MTA to 2.
• Set up an explicit access rule for jslopez@xman.org that causes an immediate rejection and a nice little “don’t be an idiot and bounce forged return path’s” public service message.
• Get the accept queue depth as deep as possible for the slave processes.
• Reject any messages without a proper e-mail address in the FROM: envelope.

The killer solution was Google Apps for Domains though. I have registered for the service, updated my MX records, and once that information propagates through the Internets all my domain’s e-mail will get routed to Gmail, which has exactly one registered account: jslopez@xman.org. Gmail is configured to route any e-mails to an unknown address to my mail server. The net effect is that all this backscatter will get swallowed by the Gmail black hole, and everything else will remain outside the event horizon and hopefully get delivered to my mail server at something approaching the speed of light.

The other lesson learned from this is that openldap is slow, so one shouldn’t using it for accessing one’s MTA configuration. I intend to set up a cron job that will periodically dump the contents of LDAP in to files and then have postfix just read those files directly. This should prove to be infinitely more scalable and efficient, at the cost of updates being somewhat delayed.

So, what did I break? Nothing much… just my mail server (which happens to be shared by some half dozen other people, and collectively probably about 30-40 users). I decided it was time to emerge everything up to the latest and greatest packages, and that included Cyrus. It turns out that as part of that upgrade, Cyrus switched to a new version of Sleepycat’sOracle’s BerkeleyDB. Somehow developers still haven’t figured out a smooth way to handle the transition, so of course Cyrus wouldn’t start up. No Cyrus, no mail delivery (you can see where this is going right?).

The first thing I learned: the procedure to “fix” things when this happens. The steps are:

1. Stop Cyrus
2. Back up your Cyrus data (/var/cyrus in my case)
3. Run db_recover in your Cyrus data directory (again, /var/cyrus)
4. Run db_recover in your Cyrus data directory’s “db” directory (/var/cyrus/db)
5. Delete any vestigial environment files (__db*) in both places
6. Truncate any log files in either place (log00000*)
7. Start Cyrus again

These direction lack an obvious indicator of what to do when Cyrus still fails, still complaining about not being able to recover the databases at this point. It turns out that most of the db’s in /var/cyrus can be lost with minimal impact. The one key one that you don’t want to lose is the “mailboxes.db”. That database is built as a Cyrus proprietary skiplist, not a BerkeleyDB file, so no problems there.

As I was bringing things back, I realized that there are some nice USE flags that have been added to Gentoo’s packages that I wasn’t using. The biggest one being adding support for IMAP IDLE. This will hopefully reduce the level of polling that IMAP clients need to do with the server, thereby reducing load.

I also came across some new spamassassin plugins. In particular, I liked this plugin that uses Google’s SafeBrowsing API to build a URL blacklist for Spam Assassin. There were also some new filters to spot messages sent by botnets and to do basic fuzzy OCR on messages. Anything that reduces the spam I get each day is a good thing in my book, so I was delighted to find this. So far, I am seeing a significant reduction in the spam that I’m getting, although it is premature to say what kind of impact these additions are really having.

I also had to get my keyboard fixed on my laptop, and Google’s famous Tech Stop folks just did a quick shell swap for me. This was great and all, but udev, in its infinite wisdom, recognized that my network adaptors were new and different from the ones I’d had before. This is what Windows does, and it is great if you are plugging in to docking stations or external networking devices, etc., but it is a PITA if you already have everything nicely set up for your existing devices names. It turns out though that it is trivial (in the Linux sense) to fix: just remove the salient lines about the old network devices from /etc/udev/rules.d/70-persistent-net.rules. This experience actually taught me a lot about how udev works and it seems like a wonderful combination of simplicity and sophistication. Not perfect for everyone, but clearly better than the old devfs system.