The future of qmail

This page answers the most frequent questions about qmail's path into the 21st century. My apologies if your favorite topic isn't listed below.

[Speed] Wide-area QMTP support

The bottleneck in mailing list delivery today is SMTP latency. It typically takes more than ten seconds to transfer a message to another Internet host through SMTP. My mail transfer protocol, QMTP, is much faster, but how can qmail tell whether a remote host supports it? Answer: encode the information into the remote host's MX record. A future version of qmail-remote will support this. My target is 100 million remote deliveries per day on a 16MB machine.

[Speed] Asynchronous compressed journaling

Unlike most MTAs, qmail guarantees that messages will not be lost in system crashes. It always saves messages carefully to the queue disk, relying on certain guarantees provided by the UNIX filesystem. However, there's no reason that qmail's activity record has to be stored in the same place as its queue. I plan to reduce qmail's disk I/O by feeding new mail through a separate journaling process that saves messages in compressed form; qmail-send will rebuild the queue from the compressed journal when it starts. My target is 40 million separate messages per day with a standard IDE disk. This technology will be released first as a separate package, zeroseek.

[Speed] Faster DNS lookups

The standard BIND resolver library accounts for a huge chunk of the space taken by each qmail-remote process. A future version of qmail will support a new, much smaller DNS library. This library has been released first as part of a separate package, djbdns.

The future of mailing list management

Dynamic subscription agents

Why should users have to deal with dozens of different mailing list subscription mechanisms? My new dynasub package will accept subscription requests from local users and negotiate subscriptions with remote mailing lists. It will automatically set up a local sublist for each remote list, to speed delivery and protect user privacy.

The future is here!

Zero administration for null clients

Starting with qmail 1.03, it's easy to centralize queue management in a cluster of machines. Clients run mini-qmail to pass all mail to a central server.

More forwarding options

The new fastforward package provides convenient support for user-controlled per-domain forwarding tables and sysadmin-controlled global forwarding tables. It includes compatibility tools for /etc/aliases and :include: files.

Faster installation

Starting with qmail 1.03, it is easy to put together precompiled var-qmail packages, including dot-forward and fastforward for sendmail compatibility.

Split log analysis

The qmailanalog tools no longer require that you keep qmail's entire log. They store crucial information in a table on disk.