The problem: First of all, Courier is a piece of shit. The various parts of it have broken in various ways over the years (authd hanging for no apparent reason or suddenly eating a ton of memory, stuff like that). Not only that, but they decided that vpopmail wasn’t worth supporting anymore, so their latest release of courier-authlib simply doesn’t handle vpopmail anymore. (don’t ask me why, can’t find any details on it).
Second of all, it would be cool to give our users the ability to create their own custom mail filters on our server. Stuff that you can do in thunderbird or through webmail, so they can setup their mailbox filters and vacation messages and whatever without me having to help them. (well…. we’ll see about that). Needless to say we could do that by giving them access to the .qmail files, but those are way out of their league. Not only that, it would be a security nightmare. So to solve that, we’re trying the Sieve disaster. I mean language… or something.

Getting rid of Courier is really simple. Simply pull the harddisk out of your server and shake it a few times, then step on it and throw it out of the window (while still standing on top of it of course). If you did it properly you should now be wondering why the hell you follow instructions without thinking. However, if you do have a brain, you might want to shutdown the courier-imap* and pop* services and remove them from your disk. Tada.
Personally I replaced the pop, imap and auth services with Dovecot. If you’re running qmail like you’re supposed to this is pretty easy. Check out this page by John Simpson for details on that. Instructions for vpopmail included. (thanks again John!)

Now for the interesting part. Getting Sieve to work. I decided to get the latest shiny version from their hg repository, but feel free to take the latest stable version instead.

Now we still need to enable it. Make sure your /etc/dovecot.conf has a section like this:

Easy. This should make the /usr/libexec/dovecot/deliver program able to verify the account information of a requested user against the vpopmail database and it instructs the local delivery part to use the sieve plugin. (which I’ve configured some paths for).
However, next part literally took me hours to figure out. I wanted to use the Dovecot LDA only for my test email account. So I created a .qmail file for my user – according to their wiki :

According to their wiki, this should be the correct way to invoke the deliver program. So I send a test mail to benv-test@benv.junerules.com …. nothing happens. Nothing in logs, nothing.
Oh that’s a lie, the error log says:

Of course it doesn’t work yet, I haven’t put a sieve filter in place yet. So I put a simple reject filter there so I know it works when it does
This is the contents of a file ~vpopmail/domains/benv.junerules.com/benv/.sieve/dovecot.sieve. Corresponding with the dovecot.conf plugin settings.

I send another mail. Same stuff in the logs. Mhm… more debugging would be great guys. I have no idea if it loads a sieve filter, from what directory or if it does anything at all! GRRRr.
After a lot of cursing and throwing with plants and cats and hammers, I went through the mailing archives from the John’s qmail-patch list and found a snippet from someone else that set up something similar. Apparently the way to invoke the deliver program is different. Because I use the qmail extension addresses, benv-test@benv.junerules.com was given as user. However, vpopmail only knows about benv@benv.junerules.com, so it failed. Blegh.
So for now I decided to use the solution offered by the mailinglist:

A little explanation on the environment variables. Normally when I send a message to benv-test@benv.junerules.com they look like this:

The DTLINE rewrite isn’t strictly necessary but looks a bit nicer in the logs. However, the EXT@USER part should not contain all the extensions since they won’t resolve to a vpopmail user.
With the rewritten .qmail file I send another test email. Here’s the log:

Woohoo, it rejected!
So Sieve works. Next thing to do is to get ManageSieve up and running and test it with thunderbird and some sieve addons
But that’s a rant for later, my eyes are collapsing.

As a side story, since we moved our junerules.com domain from our very kind previous host to our own Xenbro machine, the amount of spam we receive plummeted. Apparently not because they stopped spamming on the domain though. I’m sure our previous host is glad he doesn’t have to deal with all the attention and traffic anymore .
The main reason for this spam drop seems to be spamdyke. I’m sure you have your own opinion about how nice or acceptable it is to run graylisting and reverse DNS checking and all that, but my opinion is that if you have a badly configured mailserver (read: windows zombie machine) you can die in a fire for all I care. Fix your mailserver and then I’ll accept your mail.
Too bad for the few properly configured mailservers out there that now have to try twice to get through the graylisting…. then again, it’s a small price to pay.

Anyway, to get rid of assholes trying to bruteforce their way into my ssh daemon I run fail2ban, which lets you try to get in a few times and then blocks your IP for a week. That’s how much I like them. So I decided to add a new filter to fail2ban, which gets rid of asshole mailservers that will fail their next attempts anyway. Those are the mailservers that spamdyke denies with the following errors:

• DENIED_RDNS_MISSING – in other words, the mailserver doesn’t have a reverse DNS entry. You can’t be serious, that has to be a zombie.
• DENIED_IP_IN_CC_RDNS – means the mailserver probably has a dynamic IP address from their local ISP. Mostly zombies. Sorry for the 2 mailservers our there that are legitimate that mail like this. I’ll whitelist you whenever I see complaints.
• DENIED_RDNS_RESOLVE – means the reverse DNS does not resolve to the IP address it connected from. Get lost. However, this one should be used with care, because if the DNS resolver fails for whatever reason spamdyke will also issue this. So make a real good consideration if you want to use this in the fail2ban filter.

Since above failures will keep coming back if they retry, I block these asshole servers for a week.
Here’s my /etc/fail2ban/filter.d/spamdyke.conf:
Fail2ban spamdyke filter - Version 0.1 - SHA: 1ee23545d87998d0314d2683eb8f2a099cf9fca9

Simply put it in /etc/fail2ban/filter.d and edit /etc/fail2ban/jail.local and add something like this:

Then reload fail2ban:

After enabling it about 12 hours ago, this is the result:

Simply amazing. We’ll end up blocking half the internet. Oh well, it’s only the bad part of internet anyway.

So what things are missing in the vanilla Qmail 1.03 package?

• IPv6 support
• A ton of antispam features like SPF, DomainKeys, MFCHECK, etc
• Authentication support
• Filter support for stuff like Spamassassin, ClamAV, /dev/null
• Virtual domains

Probably more, but these are things I care about. Some of these points are not entirely true, for instance you could add filter support by mangling the .qmail files for all users, but these are things you want centralized so all things have to pass the filter, not for only a few accounts.
In order to fix the missing features I use a few things.
First of all: John M. Simpson’s combined patch. This patch fixes more than half of the list. It’s a collection of smaller patches all rolled together in a nice patch that cleanly applies to qmail 1.0.3 as supplied by D.J. Bernstein. Thanks a lot to Mr Simpson! His pages also have a lot of notes and scripts on how to get qmail up and running, and how to run the services from daemontools. You might want to check them out.
Next, I use vpopmail to handle the virtual domains problem. Together with qmailadmin they make the virtual domains thing very easy.

Anyway, that is all old stuff. New stuff is having Qmail working correctly using IPv6.
It’s easy to get it up and running, basically just compile qmail as usual and patch ucspi-tcp using Fefe’s IPv6 patch. Make a few new qmail-smtp services for the IPv6 enabled addressses and go!
While this does work for receiving mail, it fails for a few things in the combined patch – like SPF checking.
You will run into stuff like:

Obviously this is a lie, but at least it’s dealt with gracefully. However, you want SPF checking for the IPv6 address!
Fortunately, Brandon Turner has patched this with a patch that applies to Qmail 1.0.3 when already patched with John’s patch. Enough patches for you?
After recompiling and restarting your services you will see that it works now. Thanks Brandon!

What does Slackware have to do with this?
Nothing, I just like the way it runs the qmail services :-p