1. s/qmail ids and limitations

s/qmail's tasks are separated to different users and groups in the Unix system.

1.1 s/qmail Unix default users

These names and uids can however be freely chosen to meet your system requirements.

1.2 s/qmail Unix default groups

sqmail makes use of following Unix groups:

Again - as above - those default values are matter of change.

1.3 s/qmail ids configuration files

The s/qmail ids in the Unix system follow the idea of Generalized ids (GUID and GGID).
However, with some care, you can adjust the names as well as the ids to your local conventions:

• conf-users: User names (except for 'root') in addition with
• conf-groups: Group names (except for 'root') and together with
• conf-ids: User names and uids together with group names and gids.

1.3.1 conf-users

Note: The user accounts will be by default created with no valid shell, thus can not be used for login. I recommend to use a dedicated Unix user for administrative purpose, eg. sqmaster and with assigned secondary group sqmail.

1.3.2 conf-groups

1.3.3 conf-ids

Note: For the alias and the queue user, the last token denotes the (relative) directory path.

1.4 s/qmail ids setup-script

In order to make changes effective, you need to run the script:

• package/ids

which will raise the respective user and groups automatically for *BSD or Linux systems. Other Unix OS may require to set up those accounts manually. Once they exist, the script respects your settings and will leave them untouched.

Now changes in the conf-XX become effective for the s/qmail sources in case you recompile the binaries.

1.5 s/qmail limitations

s/qmail behaves as several users in the Unix OS. Thus, it posses a set of limitions originating from the OS default user settings:

• The user might be limited by the ulimit command. This is rather unlikely.
• The user is limited by quota settings. This however, concerns the s/qmail queue only, since this unses the only variable file space.
• Intrinsic limits by the operating system's kernel, like the number of file descriptors. In some Linux systems this number is restricted to 1024. On busy systems, this limit might easily exaggerated regarding the user qmail-send. Raising this limit is possible, but requires per-user settings depending on the OS.
• Limits on the spawning of qmail-local and qmail-remote concurrent instances (see man qmail-limits), which however is configurable.
• The number of available sockets is limited per IP address. Roughly more than concurrent 50.000 IP connections per IP address are not possible. Greetdelay may be inferior to that limit.

The resources of the s/qmail daemons might be restricted by means of the softlimit program as part of Daemontools. By aware, that memory settings might cause an abend (signal 11) of the respective daemons, once the daemon requests more memory.

1.5.1 Performance improvements

s/qmail is limited by

• I/O operations; perhaps in addition by virus and spam scanners,
• computation, in particular the TLS handshake,
• network resources; TCP sockets,
• the number of SYSCALLS,
• the number file and directory synchronizations.

The configuration files

• conf-spawn
• conf-split

provide the basic settings for improvements. Given the number of directories in conf-split their population at any time should be less then 1000 files which corresponds roughly to √N where N is the number of emails per day.

Most OS provide the possibility to put transient though persistent data on a RAM disk. Use this for log data and AV scanner artifacts.
Use SSD disks to improve the throughput of the s/qmail queue. In case s/qmail In addition, the filesystem can be mounted 'noatime'. Regarding network resources you can attach several IPv4/IPv6 addresses to qmail-smtpd and in addition binding qmail-remote to different IP addresses per domain; in particular setting up a particular Bounce IP address.

s/qmail starting with version 4.3 applies now for qmail-remote, qmail-dksign, and qmail-dverify a buffered I/O resulting in a dramatically reduction of Syscalls and thus throughput improvements.

1.5.2 BigToDo and Ext-ToDo

s/sqmail comes by default with two none-vanilla standard extensions:

1. The queue directory todo is now splitted in serveral directories given by conf-spltt allowing very many files in state 'todo' to stat more efficient.
2. An additional process called qmail-todo pioneered by Andre Oppermann for his qmail-ldap fork. This makes s/qmail responsive even under high load and avoids what is called the 'Silly Qmail Syndrom'.

The interaction between the qmail daemon processes while running has been drawn by Andre in the following diagram (which I shamelessly stole):