The -d0.1 (a.k.a. -d0) debugging switch previously prevented sendmail from forking and detaching itself, but that function has been moved to the -d99.100 debugging switch. The -d0.1 debugging switch now just tells sendmail to print information about its version:

Version 8.8.4
Compiled with:   LOG MATCHGECOS NAMED_BIND NDBM NEWDB NETINET NETUNIX
                 NIS
SYSTEM IDENTITY (after readcf):
            (short domain name) $w = here
        (canonical domain name) $j = here.US.EDU
               (subdomain name) $m = US.EDU
                    (node name) $k = here

The Version is the current version of sendmail. Note that for Sun the number may look like SMI-8.7.5.

The Compiled with: lists the compile-time definitions that where specified when sendmail is compiled. All the available definitions are listed in Table 18.3 in Section 18.8, "Alphabetized Reference".

The SYSTEM IDENTITY shows the value assigned to four important macros. The meaning of each macro is contained in Table 31.7 in Section 31.10, "Alphabetized Reference".

The -d0.4 debugging switch tells sendmail to print several additional lines of information:

Version 8.8.4
Compiled with:   LOG MATCHGECOS NAMED_BIND NDBM NEWDB NETINET NETUNIX
                 NIS
canonical name: here.US.EDU                            additional
 UUCP nodename: here                                   additional
        a.k.a.: [123.45.67.89]                         additional
============ SYSTEM IDENTITY (after readcf) ============
            (short domain name) $w = here
        (canonical domain name) $j = here.US.EDU
               (subdomain name) $m = US.EDU
                    (node name) $k = here
========================================================

To find the canonical name of the local host, sendmail calls gethostname(). If that call fails, the name localhost is used. The hostname is then looked up with the internal routine sm_gethostbyname(), which gathers additional information (such as other names and addresses for the machine) and fixes several bugs in some operating system's versions of the gethostby... routines. Next the canonical name for the local host is looked up. For operating systems that normally support switched services, the name is looked up as specified. For systems that specify switched services in the configuration file's ServiceSwitchFile option (see Section 34.8.61, ServiceSwitchFile), switched services are not used because the configuration file has not been read yet. (This canonicalization process can be traced with the -61.10 debugging switch.) If the canonical is found and that name contains a dot, sendmail saves the part of the name to the right of the leftmost dot as the domain name in the $m macro (see Section 31.10.24, $m). It also appends the part of the name to the left of the leftmost dot to the class w (see Section 32.5.8, $=w). If the canonical name doesn't contain a dot, the $m macro is undefined, and the whole name is appended to the class w.

In addition, sendmail also sets the $k macro (see Section 31.10.21, $k) to be the correct UUCP name for the machine. It uses uname(3), if available, to find that name (see Section 18.8.51, TRUST-POPEN); otherwise, it uses the same strategy as for class w above.

Then sendmail lists any other names or addresses (this latter in square brackets) that it found. If it finds any, it prints the name prefixed by a.k.a.: and appends each to the class w. The aliases listed are only those found using gethostbyname(3). To see each entry as it is added to the class w, use the -d37.8 debugging switch.

Finally, sendmail scans the network hardware to find any other names associated with interfaces. If the ioctl(2) call to get that information fails, the -d0.4 debugging switch causes sendmail to print that failure:

SIOGIFCONF failed:  reason here

If any are found, each is printed with an a.k.a.: prefix and added to the class macro w.

The -d0.10 debugging switch causes sendmail to print all the operating system specific definitions that were used to compile your specific version of sendmail. This output prints after the "Compiled with:" information described above:

OS Defines: HASFLOCK HASGETUSERSHELL HASINITGROUPS HASLSTAT
                HASSETREUID HASSETSID HASSETVBUF HASUNAME IDENTPROTO
                IP_SRCROUTE
Kernel symbols: /vmunix
   Config file: /etc/sendmail.cf
  Proc Id file: /etc/sendmail.pid

The OS Defines are described in Table 18.3 in Section 18.8. Most are automatically determined during compilation; others are specified in Makefile.

The Kernel symbols is the name of file that is accessed to determine the load average. It is automatically defined correctly when conf.c is compiled. The location of the configuration file and the process identifier file are defined in the Makefile and conf.h in the sendmail source (see Section 18.8.34, PATH...).

The -d0.15 debugging switch causes sendmail to display how it interpreted its delivery agent definitions. The clarity and completeness of the delivery agent information vary with the version of sendmail. See the =M rule-testing command (Section 38.4.2, "Show Delivery Agents with =M") for an example of this output.

When sendmail scans the network hardware to find other names for the local host, it uses only those names that are new. Each new name was printed by the -d0.4 debugging switch above. To see every name that sendmail finds, new and old alike, use the -d0.20 debugging switch:

128.32.201.55                                        already found
127.0.0.1                                            found new
        a.k.a.: [127.0.0.1]

Ordinarily, if the UUCP name for the local host cannot be found (if uname(3) fails), sendmail silently uses the leftmost component of the canonical name as the UUCP name. To see whether uname(3) failed - and, if so why - you can use the -d0.22 debugging switch:

uname failed (reason for failure here)

The -d0.40 debugging switch causes sendmail to announce that it is about to scan for network interfaces:

scanning for interface specific names, ifc_len=64
        a.k.a.: [127.0.0.1]

The ifc_len is the size in bytes of the configuration list returned by the kernel.

The -d0.44 debugging switch causes sendmail to prefix certain lists of strings that it prints with the address in memory of each string and an equal sign. With this debugging level, part of the output produced by the -d21.12 debugging switch would look like this:

--- rule fails
---trying rule:
        0009ec68=@
        0009ec78=$*
--- rule fails

This debugging level can be useful to the programmer who wishes to modify the sendmail source. It might, for example, be helpful in designing more efficient string storage.

The -d0.90 debugging switch causes sendmail to display its internal interpretations of the first 10 rewriting rules it took from the configuration file. The rule sets are printed in numeric order, rather than in the order in which they appeared in the configuration file. The rewriting rules are printed under each rule set (but these are in the order in which they appeared in the configuration file). Rule sets that are declared but lack rewriting rules are not printed. Note that defined macros in the RHS are expanded (the value used) when the configuration file is parsed. Also note that expressions like $+ may be printed as control characters (e.g., ^A) under older versions of sendmail.

The preferred way to view individual rule sets is with the -bt rule-testing mode's =S command (see Section 38.4.1, "Show Rules in a Rule Set with =S").

Although there are many kinds of information that one might like to trace about the sender of an email message, sendmail provides the means to trace only one of them. The -d1.1 (a.k.a. -d1) debugging switch causes sendmail to print its interpretation of whom the message is from (the name of the sender as it was used in the envelope):

From person = "sender"

Here, sender is the user portion of the mail address of the sender. This output is most useful when combined with the -f command-line switch (which sets the name of the sender from the command line; see Section 36.7.21, -f and -r).

The -d1.5 debugging switch causes additional information about the sender to be printed. That output looks like this:

main: QDONTSEND output of printaddr() here (see Section 37.3.1, "The Output Produced by printaddr()")

The QDONTSEND means that the sender is not a recipient and so should not get a copy of the message. That is followed by the output of the printaddr() routine.

Ordinarily, sendmail exits silently when it is done (unless an error causes an error message to be printed). The -d2.1 (a.k.a. -d2) debugging switch causes sendmail to print three useful values when it exits. The message it prints looks like this:

====finis: stat num e_id=qid e_flags=flags

The num is the final value of the sendmail program's global ExitStat variable. It is usually updated to contain the latest error value as defined in <sysexits.h>. See Section 36.5, "sendmail's exit() Status" for a detailed description of the possible exit values.

The qid is either the queue identifier (such as SAA24069) or the NOQUEUE if the message was never assigned an identifier (such as if it was never queued).

The flags is a hexadecimal representation of the possible envelope flags followed by a text representation of those flags in angle brackets with the leading EF_ removed, for example,

201003<OLDSTYLE,INQUEUE,GLOBALERRS,HAS_DF>

These are the envelope flags that were in effect with the current envelope when sendmail exited. The possible values are shown in Table 37.3.

Table 37.3: Hexadecimal Envelope Flags

Text	Hex	Description
EF_OLDSTYLE	0000001	Use spaces (not commas) in headers
EF_INQUEUE	0000002	This message is fully queued
EF_NO_BODY_RETN	0000004	Omit message body on error
EF_CLRQUEUE	0000008	Disk copy is no longer needed
EF_SENDRECEIPT	0000010	Send a return receipt
EF_FATALERRS	0000020	Fatal errors occurred
EF_KEEPQUEUE	0000040	Keep queue files always
EF_RESPONSE	0000080	This is an error or return receipt
EF_RESENT	0000100	This message is being forwarded
EF_VRFYONLY	0000200	Verify only (don't expand aliases)
EF_WARNING	0000400	Warning message has been sent
EF_QUEUERUN	0000800	This envelope is from queue
EF_GLOBALERRS	0001000	Treat errors as global
EF_PM_NOTIFY	0002000	Send return mail to postmaster
EF_METOO	0004000	Send to me too
EF_LOGSENDER	0008000	Need to log the sender
EF_NORECEIPT	0010000	Suppress all return-receipts
EF_HAS8BIT	0020000	At least one 8-bit character in body
EF_NL_NOT_EOL	0040000	Don't accept raw newline as end-of-line
EF_CRLF_NOT_EOL	0080000	Don't accept carriage-return/line-feed as end-of-line
EF_RET_PARAM	0100000	SMTP RCPT command had RET argument
EF_HAS_DF	0200000	Set when df file is instantiated
EF_IS_MIME	0400000	Really is a MIME message
EF_DONT_MIME	0800000	This message is not MIME-able

For example, if the message were fully queued and required a DSN return receipt, the flags would print as

e_flags=12<INQUEUE,SENDRECEIPT>

Note that this line of output is also produced by the -d13.1, -d40.3, and -d50.1 debugging switches but under different circumstances.

The -d2.9 debugging switch tells sendmail to display the properties of each open file descriptor. That output is produced by the dumpfd() routine, and each line of output is for a single file descriptor:

num: fl=flags mode=mode type stats

Here, the num is the number of the open file descriptor. Note that descriptors 0, 1, and 2 are usually tied to the standard input, output, and error output.

The flags is a hexadecimal representation of the state flags associated with a file descriptor. F_GETFL is used with ioctl(2) to fetch each, and all are described in <sys/fcntlcom.h>.

The mode is printed in octal and is the st_mode associated with an fstat(2) of the file descriptor. The type examines the file type portion of the st_mode and prints SOCK for a socket, CHR: for a character special device, BLK: for a block special device, FIFO: for a first-in-first-out file, DIR: for a directory, LNK: for a symbolic link, and nothing otherwise (e.g., nothing if it is a file).

The stats are printed for all but the socket. They look like this:

dev=major/minor ino=inum nlink=nlink u/gid=uid/gid size=bytes

Here the dev= shows the major and minor device numbers for the device that the file descriptor is associated with. The inum is the inode number on the disk (if there is one) and nlink is the number of hard links to the file on disk. The uid/gid shows the user and group ownership associated with the file descriptor. The size is the number of bytes in a file, and 0 for almost everything else.

For a socket, the stats part of each line looks like this:

[addr]/port-> host

Here, addr is the IP address of the local end of the socket. If the connection is of type AF_INET, the port number of the connection is also shown as /port. The host is the hostname, as returned by getpeername(3), of the connecting host. If any of these cannot be found, the error string associated with errno is printed parenthetically in its place.

The -d7.9, -d40.9, and -d46.9 debugging switches also print a line like this for specific file descriptors. Also if sendmail is run with the -d10.100 switch, or if sendmail fails to open a tf queue file (see Section 23.2.6, "The Temporary qf Rewrite Image: tf"), or if sendmail exited because of too many open files, it will syslog all its open file descriptors within this format.

The sendmail program queues mail, rather than delivering it, if the load average (number of processes in the run queue) exceeds the value set by the QueueLA (x) option (see Section 34.8.50, QueueLA (x)). Exceeding that value also prevents messages that are already in the queue from being delivered (prevents a queue run). If the load average becomes higher than the value of the RefuseLA (X) option (see Section 34.8.54, RefuseLA (X)), sendmail rejects incoming SMTP connections until the load average drops.

The -d3.1 debugging switch (a.k.a. -d3) causes sendmail to print the load average found by its internal getla() routine each time that routine is called:

getla: la

Here, la is the current load average printed as an integer. If sendmail was compiled with LA_TYPE==LA_ZERO (see Section 18.8.14, LA-TYPE), the following will be printed to show that your sendmail binary completely lacks load averaging support:

getla: ZERO

The -d3.1 debugging switch also causes sendmail to print any errors it encounters while obtaining the load average.

getla: open(/dev/kmem): error

Here, /dev/kmem is the device that is used to access kernel memory. The error is the system error that caused the failure, such as "Permission denied" if sendmail is not properly sgid to the group kmem.

getla: nlist(unix): error

The nlist(3) function extracts a list of symbols from an executable binary (among them the symbol for the load average). The binary that it extracts is the kernel whose pathname is unix (such as /vmunix for SunOS 4.x). Here, the error is the reason nlist(3) failed. One possibility is that you booted from a nonstandard kernel name (such as /vmunix.new) and the expected file didn't exist:

getla: nlist(unix, la) ==> 0

If the expected kernel exists (unix) but the machine was booted from a different kernel, the symbol representing the load average may not be found. In that instance, la is the name of the kernel variable that sendmail was trying to find.

The load average that sendmail uses is averaged over the last minute. Internally, the kernel keeps track of three load averages. In addition to the last minute, it also tracks the last 5 and 15 minutes. The -d3.5 debugging switch causes V8 sendmail to print the load average over the last minute:

getla: averun = 1min

The -d3.15 debugging switch causes V8 sendmail to print all three load averages:

getla: averun = 1min, 5min, 15min

Here, the three load averages are printed either in integer or in floating point, depending on the setting of LA_TYPE (see Section 18.8.14).

The nlist(3) routine (described above) provides the offset into the kernel file where the value of the load average is found. The -d3.20 debugging switch causes that offset to be displayed:

getla: symbol address = offset

Here, the offset is printed in hexadecimal. The load average is read by seeking in the kernel file and reading it. If the seek or read fails, the -d3.1 debugging switch causes sendmail to print:

getla: seek or read: error

This can indicate a wrong or corrupted kernel image.

The internal routine shouldqueue() is called just before a mail message is delivered to recipients. That routine determines whether mail will be delivered or queued on the basis of the current load average and message priority. Upon entry it prints:

shouldqueue: CurrentLA=load, pri=priority

If the CurrentLA is less than the limit set by the QueueLA (x) option (see Section 34.8.50), sendmail prints:

FALSE (CurrentLA < QueueLA)

Then the calculation described in Section 34.8.49, QueueFactor (q) for the QueueFactor (q) option is performed using the pri priority. The result is printed as one of the following, where TRUE represents a zero result and FALSE represents a nonzero result:

TRUE (by calculation)
FALSE (by calculation)

The MinFreeBlocks (b) option (see Section 34.8.40, MinFreeBlocks (b)) defines the minimum number of disk blocks that must be reserved on the queue disk. If an incoming SMTP message will fill the disk beyond this minimum, the message is rejected.

The -d4.80 debugging switch [1] traces the enoughspace() routine in conf.c. That routine examines the disk space and allows or disallows incoming mail.

[1] No -d4.1 (a.k.a. -d4) information is available.

enoughspace: no threshold

This debugging output says that no limit was defined with the MinFreeBlocks (b) option.

enoughspace: bavail=haveblocks need=needblocks

This debugging output shows that the number of blocks free (available) on the disk is haveblocks and that the number of blocks required by incoming mail is needblocks. Note that haveblocks will always be -1 if sendmail was compiled with SFS_TYPE set to SFS_NONE (see Section 18.8.40, SFS-TYPE).

enoughspace failure: min=boption need=needblocks

If the required number of blocks (needblocks) exceeds the minimum reserved as defined by the MinFreeBlocks (b) option (boption), use of the disk is disallowed.

Throughout its many possible levels of forks and children, sendmail must keep track of timeouts - the maximum amount of time it should wait for an event to occur. For example, a child must not wait forever for an SMTP greeting message, because the program at the other end may never provide that message (because it died or is just too busy).

To keep track of which child should be notified at which time, sendmail maintains an internal queue of events. The sendmail program uses the SIGALARM signal and the alarm(2) system call to set the interval it waits to next check its queue of events for timeouts. That interval (called a tick) is the period of the timeout itself, or if the timeout is scheduled for the pr