Sendmail Installation and Operation Guide
SMM:08-23
The information returned by this protocol is at most as trustworthy as the host providing it OR
the organization operating the host. For example, a PC in an open lab has few if any controls
on it to prevent a user from having this protocol return any identifier the user wants. Like-
wise, if the host has been compromised the information returned may be completely erro-
neous and misleading.
The Identification Protocol is not intended as an authorization or access control protocol. At
best, it provides some additional auditing information with respect to TCP connections. At
worst, it can provide misleading, incorrect, or maliciously incorrect information.
The use of the information returned by this protocol for other than auditing is strongly dis-
couraged. Specifically, using Identification Protocol information to make access control deci-
sions - either as the primary method (i.e., no other checks) or as an adjunct to other methods
may result in a weakening of normal host security.
An Identification server may reveal information about users, entities, objects or processes
which might normally be considered private. An Identification server provides service which
is a rough analog of the CallerID services provided by some phone companies and many of
the same privacy considerations and arguments that apply to the CallerID service apply to
Identification. If you wouldn't run a "finger" server due to privacy considerations you may
not want to run this protocol.
In some cases your system may not work properly with IDENT support due to a bug in the TCP/IP
implementation. The symptoms will be that for some hosts the SMTP connection will be closed
almost immediately. If this is true or if you do not want to use IDENT, you should set the IDENT
timeout to zero; this will disable the IDENT protocol.
3. ARGUMENTS
The complete list of arguments to sendmail is described in detail in Appendix A. Some important
arguments are described here.
3.1. Queue Interval
The amount of time between forking a process to run through the queue is defined by the -q
flag. If you run with delivery mode set to i or b this can be relatively large, since it will only be rel-
evant when a host that was down comes back up. If you run in q mode it should be relatively short,
since it defines the maximum amount of time that a message may sit in the queue. (See also the
MinQueueAge option.)
RFC 1123 section 5.3.1.1 says that this value should be at least 30 minutes (although that
probably doesn't make sense if you use ``queue-only'' mode).
Notice: the meaning of the interval time depends on whether normal queue runners or persis-
tent queue runners are used. For the former, it is the time between subsequent starts of a queue run.
For the latter, it is the time sendmail waits after a persistent queue runner has finished its work to
start the next one. Hence for persistent queue runners this interval should be very low, typically no
more than two minutes.
3.2. Daemon Mode
If you allow incoming mail over an IPC connection, you should have a daemon running. This
should be set by your /etc/rc file using the -bd flag. The -bd flag and the -q flag may be combined
in one call:
/usr/sbin/sendmail -bd -q30m
An alternative approach is to invoke sendmail from inetd(8) (use the -bs -Am flags to ask
sendmail to speak SMTP on its standard input and output and to run as MTA). This works and
allows you to wrap sendmail in a TCP wrapper program, but may be a bit slower since the