Efficiency

Answer: Decide how many deliveries you want to allow at once. Put that number into /var/qmail/control/concurrencyremote and restart qmail.

Make sure you set the ``descriptors'' or ``openfiles'' resource limit to at least double the concurrency plus 5, and the ``maxproc'' resource limit (if your system has one) to at least the concurrency plus 4. Otherwise qmail will unnecessarily defer deliveries whenever a big burst of mail shows up.

Note that qmail also imposes a compile-time concurrency limit, 120 by default. You can change this in conf-spawn at compile time.

Answer: Yes. qmail-send stores message retry times in a priority queue (using 8 bytes of RAM per queued message---for example, 0.8MB if you have a gigantic queue of 100000 messages) so that it can rapidly find the next message that needs to be delivered.

qmail's queue directories are split into 23 subdirectories, so the operating system's namei() searching takes negligible time even when there are thousands of queued messages.

The main limit on queue size is disk space. Each message uses one inode under the qmailq user, a few inodes under the qmails user, and several blocks of data depending on the message size. (If you want to limit the queue size, simply put an inode quota on the qmailq user.)

Answer: Yes. qmail has three backoff features:

• Each message is automatically retried on a quadratic schedule, with longer and longer intervals between delivery attempts.
• If a remote host does not respond to two connection attempts (separated by at least two minutes with no intervening successful connections), qmail automatically leaves the host alone for an hour. At the end of the hour it ``slow-starts,'' allowing one connection through to see whether the host is up.
• Some mailers opportunistically bombard a host with deferred messages as soon as the host comes back online. qmail does not do this. Each message waits until the appropriate retry time.