D. J. Bernstein
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,
[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,
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
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.
Starting with qmail 1.03,
it is easy to put together
precompiled var-qmail packages,
for sendmail compatibility.
Split log analysis
tools no longer require that you keep qmail's entire log.
They store crucial information in a table on disk.