There are a number of configuration parameters you may want to change, depending on the requirements of your site. Most of these are set using an option in the configuration file. For example, the line O Timeout.queuereturn=5d sets option Timeout.queuereturn to the value 5d (five days).
Most of these options have appropriate defaults for most sites. However, sites having very high mail loads may find they need to tune them as appropriate for their mail load. In particular, sites experiencing a large number of small messages, many of which are delivered to many recipients, may find that they need to adjust the parameters dealing with queue priorities.
All versions of sendmail prior to 8.7 had single character option names. As of 8.7, options have long (multi-character names). Although old short names are still accepted, most new options do not have short equivalents.
This section only describes the options you are most likely to want to tweak; read section
All time intervals are set using a scaled syntax. For example, 10m represents ten minutes, whereas 2h30m represents two and a half hours. The full set of scales is:
The argument to the -q flag specifies how often a sub-daemon will run the queue. This is typically set to between fifteen minutes and one hour. RFC 1123 section 5.3.1.1 recommends that this be at least 30 minutes.
Timeouts all have option names Timeout.suboption. The recognized suboptions, their default values, and the minimum values allowed by RFC 1123 section 5.3.2 are:
For compatibility with old configuration files, if no suboption is specified, all the timeouts marked with * are set to the indicated value.
Many of the RFC 1123 minimum values may well be too short. Sendmail was designed to the RFC 822 protocols, which did not specify read timeouts; hence, versions of sendmail prior to version 8.1 did not guarantee to reply to messages promptly. In particular, a RCPT command specifying a mailing list will expand and verify the entire list; a large list on a slow system may easily take more than five minutes[12]. I recommend a one hour timeout -- since a communications failure during the RCPT phase is rare, a long timeout is not onerous and may ultimately help reduce network load and duplicated messages.
For example, the lines:
After sitting in the queue for a few days, a message will time out. This is to insure that at least the sender is aware of the inability to send a message. The timeout is typically set to five days. It is sometimes considered convenient to also send a warning message if the message is in the queue longer than a few hours (assuming you normally have good connectivity; if your messages normally took several hours to send you wouldn't want to do this because it wouldn't be an unusual event). These timeouts are set using the Timeout.queuereturn and Timeout.queuewarn options in the configuration file (previously both were set using the T option).
Since these options are global, and since you can not know a priori how long another host outside your domain will be down, a five day timeout is recommended. This allows a recipient to fix the problem even if it occurs at the beginning of a long weekend. RFC 1123 section 5.3.1.1 says that this parameter should be ``at least 4-5 days''.
The Timeout.queuewarn value can be piggybacked on the T option by indicating a time after which a warning message should be sent; the two timeouts are separated by a slash. For example, the line
By setting the ForkEachJob ( Y) option, sendmail will fork before each individual message while running the queue. This will prevent sendmail from consuming large amounts of memory, so it may be useful in memory-poor environments. However, if the ForkEachJob option is not set, sendmail will keep track of hosts that are down during a queue run, which can improve performance dramatically.
If the ForkEachJob option is set, sendmail can not use connection caching.
Every message is assigned a priority when it is first instantiated, consisting of the message size (in bytes) offset by the message class (which is determined from the Precedence: header) times the work class factor and the number of recipients times the work recipient factor. The priority is used to order the queue. Higher numbers for the priority mean that the message will be processed later when running the queue.
The message size is included so that large messages are penalized relative to small messages. The message class allows users to send high priority messages by including a Precedence: field in their message; the value of this field is looked up in the P lines of the configuration file. Since the number of recipients affects the amount of load a message presents to the system, this is also included into the priority.
The recipient and class factors can be set in the configuration file using the RecipientFactor ( y) and ClassFactor ( z) options respectively. They default to 30000 (for the recipient factor) and 1800 (for the class factor). The initial priority is:
pri = msgsize - (class times bold ClassFactor) + (nrcpt times bold RecipientFactor)(Remember, higher values for this parameter actually mean that the job will be treated with lower priority.)
The priority of a job can also be adjusted each time it is processed (that is, each time an attempt is made to deliver it) using the work time factor, set by the RetryFactor ( Z) option. This is added to the priority, so it normally decreases the precedence of the job, on the grounds that jobs that have failed many times will tend to fail again in the future. The RetryFactor option defaults to 90000.
Sendmail can be asked to queue (but not deliver) mail if the system load average gets too high using the QueueLA ( x) option. When the load average exceeds the value of the QueueLA option, the delivery mode is set to q (queue only) if the QueueFactor ( q) option divided by the difference in the current load average and the QueueLA option plus one exceeds the priority of the message -- that is, the message is queued iff:
pri > { bold QueueFactor } over { LA - { bold QueueLA } + 1 }
The
QueueFactor option defaults to 600000,
so each point of load average is worth 600000
priority points
(as described above).
For drastic cases, the RefuseLA ( X) option defines a load average at which sendmail will refuse to accept network connections. Locally generated mail (including incoming UUCP mail) is still accepted.
There are a number of delivery modes that sendmail can operate in, set by the DeliveryMode ( d) configuration option. These modes specify how quickly mail will be delivered. Legal modes are:
If you run in mode q (queue only), d (defer), or b (deliver in background) sendmail will not expand aliases and follow .forward files upon initial receipt of the mail. This speeds up the response to RCPT commands. Mode i cannot be used by the SMTP server.
The level of logging can be set for sendmail. The default using a standard configuration table is level 9. The levels are as follows:
Additionally, values above 64 are reserved for extremely verbose debugging output. No normal site would ever set these.
The modes used for files depend on what functionality you want and the level of security you require.
Sendmail can safely be made setuid to root. At the point where it is about to exec(2) a mailer, it checks to see if the userid is zero; if so, it resets the userid and groupid to a default (set by the u and g options). (This can be overridden by setting the S flag to the mailer for mailers that are trusted and must be called as root.) However, this will cause mail processing to be accounted (using sa(8)) to root rather than to the user sending the mail.
If you don't make sendmail setuid to root, it will still run but you lose a lot of functionality and a lot of privacy, since you'll have to make the queue directory world readable. You could also make sendmail setuid to some pseudo-user (e.g., create a user called sendmail and make sendmail setuid to that) which will fix the privacy problems but not the functionality issues. Also, this isn't a guarantee of security: for example, root occasionally sends mail, and the daemon often runs as root.
At Berkeley we have the alias database (/etc/aliases*) mode 644. While this is not as flexible as if the database were more 666, it avoids potential security problems with a globally writable database.
The database that sendmail actually used is represented by the two files aliases.dir and aliases.pag (both in /etc) (or aliases.db if you are running with the new Berkeley database primitives). The mode on these files should match the mode on /etc/aliases. If aliases is writable and the DBM files ( aliases.dir and aliases.pag) are not, users will be unable to reflect their desired changes through to the actual database. However, if aliases is read-only and the DBM files are writable, a slightly sophisticated user can arrange to steal mail anyway.
If your DBM files are not writable by the world or you do not have auto-rebuild enabled (with the AutoRebuildAliases option), then you must be careful to reconstruct the alias database each time you change the text version:
When processing the queue, sendmail will try to keep the last few open connections open to avoid startup and shutdown costs. This only applies to IPC connections.
When trying to open a connection the cache is first searched. If an open connection is found, it is probed to see if it is still active by sending a NOOP command. It is not an error if this fails; instead, the connection is closed and reopened.
Two parameters control the connection cache. The ConnectionCacheSize ( k) option defines the number of simultaneous open connections that will be permitted. If it is set to zero, connections will be closed as quickly as possible. The default is one. This should be set as appropriate for your system size; it will limit the amount of system resources that sendmail will use during queue runs. Never set this higher than 4.
The ConnectionCacheTimeout ( K) option specifies the maximum time that any cached connection will be permitted to idle. When the idle time exceeds this value the connection is closed. This number should be small (under ten minutes) to prevent you from grabbing too many resources from other hosts. The default is five minutes.
Control of host address lookups is set by the hosts service entry in your service switch file. If you are on a system that has built-in service switch support (e.g., Ultrix, Solaris, or DEC OSF/1) then your system is probably configured properly already. Otherwise, sendmail will consult the file /etc/service.switch, which should be created. Sendmail only uses two entries: hosts and aliases.
However, some systems (such as SunOS) will do DNS lookups regardless of the setting of the service switch entry. In particular, the system routine gethostbyname(3) is used to look up host names, and many vendor versions try some combination of DNS, NIS, and file lookup in /etc/hosts without consulting a service switch. Sendmail makes no attempt to work around this problem, and the DNS lookup will be done anyway. If you do not have a nameserver configured at all, such as at a UUCP-only site, sendmail will get a connection refused message when it tries to connect to the name server. If the hosts switch entry has the service dns listed somewhere in the list, sendmail will interpret this to mean a temporary failure and will queue the mail for later processing; otherwise, it ignores the name server data.
The same technique is used to decide whether to do MX lookups. If you want MX support, you must have dns listed as a service in the hosts switch entry.
The ResolverOptions ( I) option allows you to tweak name server options. The command line takes a series of flags as documented in resolver(3) (with the leading RES_ deleted). Each can be preceded by an optional `+' or `-'. For example, the line
Version level 1 configurations turn DNSRCH and DEFNAMES off when doing delivery lookups, but leave them on everywhere else. Version 8 of sendmail ignores them when doing canonification lookups (that is, when using $[ ... $]), and always does the search. If you don't want to do automatic name extension, don't call $[ ... $].
The search rules for $[ ... $] are somewhat different than usual. If the name being looked up has at least one dot, it always tries the unmodified name first. If that fails, it tries the reduced search path, and lastly tries the unmodified name (but only for names without a dot, since names with a dot have already been tried). This allows names such as ``utc.CS'' to match the site in Czechoslovakia rather than the site in your local Computer Science department. It also prefers A and CNAME records over MX records -- that is, if it finds an MX record it makes note of it, but keeps looking. This way, if you have a wildcard MX record matching your domain, it will not assume that all names match.
To completely turn off all name server access on systems without service switch support (such as SunOS) you will have to recompile with -DNAMED_BIND=0 and remove -lresolv from the list of libraries to be searched when linking.
Some sites mount each user's home directory from a local disk on their workstation, so that local access is fast. However, the result is that .forward file lookups are slow. In some cases, mail can even be delivered on machines inappropriately because of a file server being down. The performance can be especially bad if you run the automounter.
The ForwardPath ( J) option allows you to set a path of forward files. For example, the config file line
If you create a directory such as /var/forward, it should be mode 1777 (that is, the sticky bit should be set). Users should create the files mode 644.
On systems that have one of the system calls in the statfs(2) family (including statvfs and ustat), you can specify a minimum number of free blocks on the queue filesystem using the MinFreeBlocks ( b) option. If there are fewer than the indicated number of blocks free on the filesystem on which the queue is mounted the SMTP server will reject mail with the 452 error code. This invites the SMTP client to try again later.
Beware of setting this option too high; it can cause rejection of email when that mail would be processed without difficulty.
To avoid overflowing your system with a large message, the MaxMessageSize option can be set to set an absolute limit on the size of any one message. This will be advertised in the ESMTP dialogue and checked during message collection.
The PrivacyOptions ( p) option allows you to set certain ``privacy'' flags. Actually, many of them don't give you any extra privacy, rather just insisting that client SMTP servers use the HELO command before using certain commands or adding extra headers to indicate possible spoof attempts.
The option takes a series of flag names; the final privacy is the inclusive or of those flags. For example:
The flags are detailed in section
Normally, sendmail deletes the (envelope) sender from any list expansions. For example, if matt sends to a list that contains matt as one of the members he won't get a copy of the message. If the -m (me too) command line flag, or if the MeToo ( m) option is set in the configuration file, this behaviour is suppressed. Some sites like to run the SMTP daemon with -m.