Handling bulk email in Qmail using multiple queues
I have a webhosting company, Talesa. One of our clients has a mailing list set up. (This is an opt-in mailing list.) Over time it's grown to have thousands of recipients and they send out messages several times a day. The majority of the list is delivered in about 5 minutes; way to go qmail.
The problem with all of this is that any message sent out while qmail is doing its mailing-list duty takes about 5 minutes to get through. No big deal right ? Maybe not, but why should a mailing list clog up the queue for other messages, when it's not a big deal if the mailing list messages take 20 minutes to go out?
What can I do to solve this ? First, I change /var/qmail/control/concurrencyremote to 80. The list goes out faster, but regular emails are still getting held up. On further investigation, it looks like what's happening is there are a few major 'free' email providers out there who are holding connections open with us. This quickly takes up all our available qmail-remote processes. Once all 80 of your qmail-remote slots are taken up qmail waits for them to timeout.
qmail has no notion of message priority. Even if you mark the message as bulk, qmail will show no bias and will treat all messages equally. So, what do we do ? Set up another server ? Not if we don't need to.
The solution is in making a separate qmail installations. The idea being that each installation will have its own queue and a glut of messages in one queue, won't affect the other.
In FreeBSD I add
QMAIL_PREFIX=/usr/qmail-bulk
to the Makefile. Or if you're doing this by hand, edit the conf-qmail file. I chose /usr/qmail-bulk to differentiate it from the /usr/qmail installation. Doesn't qmail live in /var/qmail ? Good point, but when you're using FreeBSD, the /var you set up when you installed the system can often seem plenty big at the time, but can quickly become inadequate.
Now that you've got your new qmail installation, there's a few things left to do.
- update your tcpserver script to listen on an alternate IP. If you don't have an extra IP available, you could have it listen on an alternate port and have the primary qmail installation forward mail to that using smtproutes.
- update the /var/qmail/rc script. Calling /var/qmail-bulk/rc stop will not only stop your bulk qmail instance, but it will also stop your main one. So, the rc script needs to stop and start both qmail instances.
I manage the mailing lists through ezmlm. Why ? because I'm a masochist. At any rate, if domain.com had a mailing list. It would be handled through lists.domain.com. All I need to do is add lists.domain.com to:
/var/qmail-bulk/control/
locals
rcpthosts
and I need to update the mx records to point to the alternate IP.
Common problems
- when you're updating your tcpserver file. Usually, it's set to listen on all IPs using '0' as the host. You'll need to change that to a specific IP before you'll be able to start your alternate qmail instance.
- make sure that you can contact all the server's IPs internally and externally. For some reason the default netmask (255.0.0.0) meant that I could reach that IP externally, but I couldn't communicate with it from on the server.
- remove the virtualdomains config from the main qmail installation otherwise if your mailing list commands are issued through smtp on the main server the messages will be put in the wrong queue.
- if you're using ezmlm, you may need to recompile it to use the alternate qmail installation.
Other recommendations
- set your concurrencyremote to a nice low number like 20. No point in slowing down the whole email server.
- check to see that things are working as they should by doing tail -f /var/log/mailog | grep status
This should produce output like:
Aug 14 07:15:59 server qmail: 1187100959.346850 status: local 2/20 remote 3/80
Aug 14 07:15:59 server qmail: 1187100959.349790 status: local 1/20 remote 20/20
we can see that the main queue is at 3/80 and the bulk queue is at 20/20. Just where we want it.
Questions and Comments are always welcome.
Luke