Table of Contents for

sendmail, 4th Edition

Print version, compilation, and interface information Debug command-line switch

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.14.1
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 can look like SMI-8.7.5 or 8.14.1+Sun.

The Compiled with: lists the compile-time definitions that were specified when sendmail was compiled. All the available definitions are listed in Table 3-2 on page 105.

The SYSTEM IDENTITY shows the value assigned to four important macros. The meaning of each macro is shown in Table 21-7 on page 798.

Our name and aliases Debug command-line switch

The -d0.4 debugging switch tells sendmail to print several lines of information in addition to those printed by -d0.1:

Version 8.14.1
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 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 (ServiceSwitchFile on page 1088), switched services are not used because the configuration file has not been read yet. (This canonicalization process can be traced with the -d61.10 debugging switch.) If the canonical name 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 sendmail macro ($m on page 833). It also appends the part of the name to the left of the leftmost dot to the class w ($=w on page 876). 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 sendmail macro ($k on page 831) to be the correct UUCP name for the machine. It uses uname(3), if available, to find that name. Otherwise, it uses the same strategy as for class $=w.

Then sendmail lists any other name, or address (in square brackets), that it found. If it finds any, it prints the found item prefixed by an a.k.a.: and adds each found item 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 $=w.

Operating system defines Debug command-line switch

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 earlier:

OS Defines: HASFCHOWN HASFCHMOD HASFLOCK HASGETUSERSHELL
            HASINITGROUPS HASLSTAT HASNICE HASRANDOM HASRRESVPORT
            HASSETREUID HASSETSID HASSETVBUF HASUNAME HASWAITPID IDENTPROTO
            IP_SRCROUTE SAFENFSPATHCONF USE_DOUBLE_FORK
 Conf file: /etc/mail/submit.cf (default for MSP)
 Conf file: /etc/mail/sendmail.cf (default for MTA)
  Pid file: /var/run/sendmail.pid (default)

The OS Defines are described in Table 3-2 on page 105. Most are automatically determined during compilation; others are specified in Makefile.

A Kernel symbols: line can also print on your machine. If so, it will show the name of the file (such as /dev/ksyms) that is accessed to determine the load average. It is automatically defined correctly when conf.c is compiled.

The location of the configuration files and the process identifier file is defined in the Makefile and conf.h in the sendmail source (_PATH... on page 131).

Print library (libsm) defines Debug command-line switch

The -d0.12 debugging switch, in addition to the information displayed by the -d0.10 debugging switch, causes the list of the sendmail library (libsm) macros that were defined at compile time to be displayed:

libsm Defines: SM_CONF_BROKEN_STRTOD SM_CONF_GETOPT SM_CONF_SETITIMER
               SM_CONF_SHM SM_CONF_STDDEF_H SM_CONF_UID_GID SM_HEAP_CHECK

Print _FFR defines Debug command-line switch

The -d0.13 debugging switch, in addition to the information displayed by the -d0.12 debugging switch, causes the list of _FFR additions that were defined at compile time to be displayed:

FFR Defines: _FFR_NO_PIPE

Unless you define such additions yourself, chances are slim that any will be printed with this debugging switch.

Dump delivery agents Debug command-line switch

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 (Show Delivery Agents with =M on page 307) for an example of this output.

Print network address of each interface Debug command-line switch

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 described earlier. 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]

End with finis( ) Debug command-line switch

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 number e_id=qid e_flags=flags

The number 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 sendmail’s exit( ) Status on page 228 for a detailed description of the possible exit values.

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

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 15-5.

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.

Show file descriptors with dumpfd( ) Debug command-line switch

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:

number: fl=flags mode=mode type stats

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

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/fcntl.h> on most systems.

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 named pipe, 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=user-id/group-id 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 u/gid shows the user and group ownership associated with the file descriptor. The bytes is the number of bytes in a file, and zero 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 (surrounded in square braces) of the local end of the socket. If the connection is of type AF_INET or AF_INET6, 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 such as 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 (The Temporary qf Rewrite Image: tf on page 400) or if sendmail exited because of too many open files, it will syslog all its open file descriptors within this format.

Trace enoughspace( ) Debug command-line switch

The MinFreeBlocks option (MinFreeBlocks on page 1057) 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^[225] traces the enoughspace( ) routine in conf.c. That routine examines the disk space and prints the following if the MinFreeBlocks option (MinFreeBlocks on page 1057) was less than or equal to zero, or if the message’s size is less than or equal to zero:

enoughdiskspace: no threshold

Show failed mail Debug command-line switch

Mail can fail for a wide variety of reasons. The way that sendmail handles errors is determined by the setting of the ErrorMode option (ErrorMode on page 1028) in the configuration file. The -d6.1 (a.k.a. -d6) debugging switch causes sendmail to print the error-handling mode that is in effect at the time it first begins to handle failed mail:

savemail, errorMode = char, id = qid, ExitStat = errornum
e_from= ← output of printaddr(  ) here (§15.3 on page 533)

Here, char is either p for print errors; m for mail-back errors; w for write-back errors; e for special Berknet processing; or q for “don’t print anything” (all of which are described under the ErrorMode option in ErrorMode on page 1028). The qid is the queue identifier (such as g7PEf0Bv027517). The errornum is the number of the error that caused the message to fail (as defined in <sysexits.h>). And e_from= uses printaddr( ) to print details about the sender’s address.

If the error-processing mode is m (for mail back) and the -d6.1 debugging switch is in effect, sendmail prints details about how the message is being returned to the sender:

***Return To Sender: msg=reason, depth=number, e=addr, returnq=
 ← output of printaddr(  ) here (§15.3 on page 533)

Here, reason is a quoted string of text that explains why the mail failed. This can be an SMTP reply string. The number is zero for normal delivery and one for error delivery. The addr is the location in memory of the information about the current envelope. Finally, sendmail calls printaddr( ) to print the details of the queue of recipients (returnq=) for the current message.

DNS name resolution Debug command-line switch

Name resolution is the process of determining a machine’s IP address based on its fully qualified domain name. This is done by using the Domain Name System (DNS). The process that sendmail uses to resolve a name is described in How sendmail Uses DNS on page 325.

When sendmail finds that a hostname is really an MX record, it attempts to look up the address (which can be an A or AAAA record) for the host that handles mail receipt. That request can fail for a variety of reasons. If the -d8.1 (a.k.a. -d8) debugging switch is specified, sendmail produces the following message:

getmxrr: res_search(host) failed (errno=errornum, h_errno=herrornum
)

Here, host is the hostname that was looked up, errornum is the system error number (if any) from <errno.h>, and herrornum is the resolver-specific error number from <netdb.h>, as shown in Table 15-6.

Call to getcanonname(3) Debug command-line switch

The routine dns_getcanonname( ) in domain.c of the sendmail source converts a hostname to a fully qualified domain name. This routine is called only if DNS is used to look up hostnames, as determined by the ResolverOptions option (ResolverOptions on page 1080) and the ServiceSwitchFile option (ServiceSwitchFile on page 1088). If it is, dns_getcanonname( ) can be called from three places: during startup to get the values for $w, $j, and $m (-d0.4 on page 542); when a host is looked up via the $[ and $] canonify operators (Canonicalize Hostname: $[ and $] on page 668); or when a host is looked up using the host database map (host on page 910).

The -d8.2 debugging switch shows the hostname before it is fully qualified with this call:

dns_getcanonname(host, flag)

If the flag is nonzero, calls to the getmxrr( ) routine (which looks up MX records) are also traced. On entry to that routine, sendmail will print:

getmxrr(host, droplocalhost=bool)

The host is the hostname whose MX records are being looked up. The bool, if nonzero, means that all MX records that are less preferred than the local host (as determined by $=w) will be discarded. If zero, they will be retained.

The -d8.2 debugging switch also causes sendmail to show the result of processing the ResolverOptions option’s settings (ResolverOptions on page 1080) while reading the configuration file:

_res.options = hex, HasWildcardMX = 1 or 0

The hex is a hexadecimal representation of the state structure’s options variable as described in <resolv.h>. The value of HasWildcardMX is determined by its prefix (+ or −) when listed with the ResolverOptions option.

Trace dropped local hostnames Debug command-line switch

If a hostname is dropped because bool (above) is nonzero, the -d8.3 switch causes sendmail to print the following:

found localhost (host) in MX list, pref=pref

The host is the hostname that is being dropped. The pref is the numerical preference associated with the MX record.

Hostname being tried in getcanonname(3) Debug command-line switch

The -d8.5 debugging switch causes the getcanonname(3) routine to print the host name it is trying to fully qualify. It shows the name with the local domain appended, without the local domain appended, and at each step in between. Each try is printed as:

dns_getcanonname: trying host.domain (type)

Here, the type is the type of lookup and is either A, AAAA, or MX. (Prior to V8.12, the type could also include ANY.)

Yes/no response to -d8.5 Debug command-line switch

The -d8.7 debugging switch causes sendmail to print a yes or no response to each of the “trying” lines printed by −8.5. “Yes” means that the host could successfully be fully canonicalized. A yes answer prints just this:

YES

If the host could not be canonicalized, a more complex answer is printed:

NO: errno=errornum, h_errno=herrornum

The errornum is the system error number (if any) from <errno.h>, and herrornum is the resolver-specific error from <netdb.h>, as shown in Table 15-6.

Resolver debugging Debug command-line switch

The -d8.8 debugging switch causes the resolver library to be put into debugging mode (if that mode was included when that library was compiled). The ResolverOptions option (ResolverOptions on page 1080) +DEBUG also turns on this debugging mode. But be aware that turning on +DEBUG will cause a large number of screens full of output to be produced by the resolver library for every DNS lookup.

If the name server returns an answer to an MX lookup, and if the answer is not an MX record or an error, sendmail will skip that host. The -d8.8 debugging switch (or the resolver library being in debug mode) then causes sendmail to print the following:

unexpected answer type wrongtype, size bytes

The wrongtype is an integer that can be found in <arpa/nameser.h >.

Trace delivery Debug command-line switch

The -d11.1 (a.k.a. -d11) debugging switch is used to trace message delivery. It must be run with the -v command-line switch, or no output will be produced.

First, for each delivery agent the following is printed:

openmailer: argv

Here, argv is the A= array for the delivery agent, with macros expanded and printed.

Second, the status of remote hosts is cached internally. Before connecting to a remote host, sendmail checks its cache to see whether that host is down. If it is, it skips connecting to that host. If the -d11.1 debugging switch is also specified, the status of the down host is printed as:

openmailer: output of mci_dump(  ) here

The output of mci_dump( ) looks like this:

MCI@memaddr: flags=mci_flags<flag,flag,...>,
errno=mci_errno, herrno=mci_herrno, exitstat=mci_exitstat, state=mci_state,
     pid=mci_pid,
maxsize=mci_maxsize, phase=mci_phase, mailer=mci_mailer,
status=mci_status, rstatus=mci+rstatus,
host=mci_host, lastuse=mci_lastuse

The meaning of each mci_ item in this output is described in Table 15-7.

Table 15-8 shows what the individual flag bits in mci_flags mean, and the human-readable flags text that corresponds to each bit. Those text items are shown with the leading source MCIF_ prefix removed.

After checking to see whether the host is down, sendmail attempts to connect to it for network SMTP mail. If that connect fails, the -d11.1 debugging switch causes the following to be printed:

openmailer: makeconnection => stat=exitstatus, errno=errno

Here, exitstatus is a numerical representation of the reason for the failure, as documented in <sysexits.h>, and errno is the system-level reason for the error, as documented in <errno.h>.

Other errors, such as failure to establish a pipe(2), or failure to fork(2), cause the following to be printed:

openmailer: NULL

This message (although it contains no information) signals that a more descriptive error message was logged with syslog(3) (Log with syslog on page 513).

Show the user-id running as during delivery Debug command-line switch

To perform delivery, sendmail often has to set its uid to something other than root’s. The logic behind that process is described in Delivery to Files on page 466. The -d11.2 debugging switch tells sendmail to print the real and effective user-ids that it is running under during delivery:

openmailer: running as r/euid=real-user-id/effective-user-id

Also, the -d11.2 debugging switch causes sendmail to print any error response that might be produced by a delivery agent:

giveresponse: stat=status, e->e_message=what

Here, status is the number of the error that caused delivery to fail (or succeed if it is 0) as defined in <sysexits.h>. The what is either the error message produced by the delivery agent, or <NULL> if the delivery agent was silent.

Show mapping of relative host Debug command-line switch

In the SMTP RCPT command, sendmail is required to express the recipient’s address relative to the local host. For domain addresses, this simply means that the address should be RFC2821-compliant.

The -d12.1 (a.k.a. -d12) debugging switch causes sendmail to print the address as it appeared before it was made relative:

remotename(addr)

If the addr is for the sender or recipient and is being processed from a queue file, nothing more is printed, and the addr is processed by canonify rule set 3. If the delivery agent for the recipient has the F=C flag set (F=C on page 768) and the recipient address lacks a domain part, the domain of the sender is appended, and the result is processed by the canonify rule set 3 again. Sender/recipient-specific rule sets are then applied (1 and S= for the sender, or 2 and R= for the recipient). Next, the final rule set 4 is applied, and any sendmail macros in the result are expanded. Finally, the fully qualified and relative address is printed as:

remotename => `addr'

Show delivery Debug command-line switch

The -d13.1 (a.k.a. -d13) debugging switch causes sendmail to display information about the recipients of each mail message as it is being delivered. The -d13.1 debugging switch tells sendmail to print the mode of delivery and then the recipient information:

SENDALL: mode dmode, id=qid, e_from output of printaddr(  ) here (§15.3 on page
533)
        e_flags = envelope flags here
        sendqueue:
output of printaddr(  ) here (§15.3 on page 533)

Here, dmode is one of the delivery modes shown in Table 15-9. The qid is the queue message identifier (such as g7PI04TK027759). The address of the sender (e_from) is dumped by using the printaddr( ) routine. Then the envelope flags (e_flags) are dumped as described in Table 15-5 on page 545. Next, information about all the recipients (sendqueue:) is printed by using the printaddr( ) routine.

Finally, the -d13.1 debugging switch causes sendmail to print a message every time it splits an envelope in two:

sendall: split orig into new

Here, orig is the original queue message identifier for the original envelope (such as g7PKuBWE027877) and new is the identifier for the new envelope, the near identical clone of the first. Envelopes need to split if they have different owners.

Show resolving delivery agent: parseaddr( ) Debug command-line switch

The -d20.1 (a.k.a. -d20) debugging switch causes sendmail to print each recipient address before it is rewritten by the canonify rule set 3 and the parse rule set 0:

--parseaddr(addr)

Here, addr is the recipient address before it is rewritten and before any aliasing has been performed on it.

The -d20.1 debugging switch also causes sendmail to print information about problems that might exist in recipient addresses. If an address contains any control or whitespace character that is not an isspace(3) character, sendmail prints the following message and skips that address:

parseaddr-->bad address

If an address is empty (that is, if it is composed entirely of an RFC2822-style comment), sendmail prints the following and skips that address:

parseaddr-->NULL

After the recipient address has been rewritten by the canonify rule set 3 and the parse rule set 0, and if a delivery agent was successfully selected, sendmail prints the result using the printaddr( ) routine.

Trace rewriting rules Debug command-line switch

The -d21.1 (a.k.a. -d21) debugging switch causes sendmail to print each step that it takes in rewriting addresses with rules. The -d21.1 debugging switch causes output to be produced that is identical to the output produced by the -bt command-line switch (Overview on page 299):

rewrite: rule set name or number      input: address
rewrite: rule set name or number    returns: address

First, the address (workspace) is displayed for the rule set whose name or number is shown before rewriting, and second, the address is shown after rewriting.

Because rules are recursive by nature, they can sometimes cause infinite loops (Rewrite Once Prefix: $: on page 662). When a rule loops more than 100 times, the following error is issued:

Infinite loop in rule set name or number, rule rule number

If the -d21.1 debugging switch was also invoked, the preceding error is followed by:

workspace: state of rewritten address, so far, is shown here

Trace $& macros Debug command-line switch

The -d21.2 debugging switch tells sendmail to show the current value of any deferred-expansion macro (one that was declared with the $& prefix). Each such macro that is encountered in processing a rule prints as:

rewrite: LHS $&char => "value"
rewrite: RHS $&char => "value"
rewrite: LHS $&name => "value"   ← V8.7 and above
rewrite: RHS $&name => "value"   ← V8.7 and above

The char is the single-character name of the macro, the name is either a multicharacter macro name or a single-character name, and the value is its current value. If that particular macro lacks a value, it will print as (NULL). The LHS refers to the lefthand side of the rule, and the RHS corresponds to the righthand side. Deferred-expansion macros are described in Use Value As Is with $& on page 793.

Trace tokenizing an address: prescan( ) Debug command-line switch

Processing of rules requires that all addresses be divided into tokens. The -d22.1 (a.k.a. -d22) debugging switch causes sendmail to print the various steps it takes in tokenizing an address.

In addition to tokenizing, the prescan( ) routine also normalizes addresses. That is, it removes RFC2822-style comments and recognizes quoted strings. Be aware that rules are also viewed as addresses and processed by prescan( ) when the configuration file is being read.

The -d22.1 debugging switch tells sendmail to complain if the first token in the address it is parsing turns out to be nothing:

prescan: null leading token

This can happen if an address (or rule) contains only RFC2822-style comments in parentheses.

Show address before prescan Debug command-line switch

The -d22.11 debugging switch causes the address to be printed as it appears before any tokenizing or normalization:

prescan: address

Show address after prescan Debug command-line switch

The -d22.12 debugging switch causes the address to be printed as it appears after all tokenizing and normalization:

prescan=  => address

Trace “sendtolist” Debug command-line switch

Each recipient address for a mail message is added one by one to an internal list of recipients. The -d25.1 (a.k.a. -d25) debugging switch causes sendmail to print each address as it is added to this list:

sendto: list
   ctladdr= output of printaddr( ) here (§15.3 on page 533)

After each is added, those that have selected a delivery agent with the F=A (F=A on page 767) and F=w (F=w on page 781) flags set are further processed by aliasing and by reading the user’s ~/.forward file. Each new address that results from this processing is added to the list, and any duplicates are discarded.

Trace recipient queueing Debug command-line switch

The -d26.1 (a.k.a. -d26) debugging switch causes sendmail to print the addresses of recipients as they are added to the send queue, which is an internal list of addresses that sendmail uses to sort and remove duplicates from the recipient addresses for a mail message.

On entry to the recipient( ) routine, the -d26.1 debugging switch causes sendmail to print the raw address (as it appears before adding it to the send queue):

recipient (level): output of printaddr(  ) here  (§15.3 on page 533)

An address can be the result of alias expansion. Because the process of aliasing (including :include: and .forward files) can be recursive, it is possible to get too many alias expansions. The level shows the number of alias expansions so far. If that number exceeds the value set by the MaxAliasRecursion option (MaxAliasRecursion on page 1044), sendmail issues this warning:

aliasing/forwarding loop broken (level aliases deep; maximum max)

Next, sendmail compares the new address to others that are already in the send queue. If it finds a duplicate, it prints the following message and skips the new address:

addr in sendq: output of printaddr(  ) here (§15.3 on page 533)

Here, addr is the duplicate address. Information about that address is produced with the printaddr( ) routine.

Trace aliasing Debug command-line switch

The -d27.1 (a.k.a. -d27) debugging switch causes sendmail to print each step it takes when processing local addresses through aliasing. First, sendmail prints the addresses being aliased:

alias(addr)

Here, addr is the address (usually a local username) that is about to be aliased. Note that it can already be the result of previous aliasing. If the addr can be aliased, its transformation is printed as:

addr (host, user) aliased to newaddr

Here, addr is the address before aliasing, and the newaddr is the new address that resulted from successful aliasing. The host and user are the hostname and username from the recipient part of the envelope. If the addr cannot be aliased, nothing is printed.

During initialization, if the aliases database cannot be opened, the -d27.1 debugging switch causes sendmail to print:

Can't open aliasfile

Here, aliasfile is the full pathname of the aliases(5) file, as declared by the AliasFile option (AliasFile on page 970) or implied with the service-switch file set by the ServiceSwitchFile option (ServiceSwitchFile on page 1088).

If the failure was due to a faulty map declaration, sendmail logs the following error:

setalias: unknown alias class dbtype

If the map is not allowed to provide alias services, sendmail logs this error:

setalias: map class dbtype can't handle aliases

If sendmail is trying to create a database file and it can’t (usually when it is run with the -bi command-line switch or run as newaliases), the -d27.1 debugging switch causes the following error to be printed:

Can't create database for filename: reason here

A self-destructive alias can cause a dangerous loop to occur. For example, the following two aliases can lead to a loop on the host mailhost:

jake:           Jake_Bair
Jake_Bair:      jake@mailhost

The -d27.1 debugging switch causes the following message to be printed when sendmail tests an address to see whether it loops:

self_reference(addr)
        ... no self ref                     ← if it didn't loop
        ... cannot break loop for "addr"     ← if it's unbreakable

An alias loop is unbreakable if no local username can be found in the list of aliases.

The -d27.1 debugging switch also causes sendmail to print a warning if it cannot open an alias file for rebuilding (the AutoRebuildAliases option, AutoRebuildAliases on page 978):

Can't open file:  reason here
newaliases: cannot open file:  reason here

Here, the error might be caused by the file simply not existing (as would be the case if it was NFS-mounted on a down host) or an I/O error (as would be the case if it was a bad disk):

warning: cannot lock file:  reason here

Failure to lock can be caused by system errors or by the file being read-only. Note that maintaining an aliases file under revision control can cause a read-only copy to exist, resulting in the following error:

Can't create database for file:  reason here
Cannot create database for alias file file

This error indicates that the output file (the dbm(3) or db(3) file) could not be created or written.

The -d27.1 debugging switch also causes sendmail to print the following message when it is attempting to read the user’s ~/.forward file:

forward(user)

If the user has no home directory listed in the passwd(5) file, sendmail issues the following message with a syslog(3) level of LOG_CRIT:

forward: no home

Include file, self reference, error on home Debug command-line switch

The -d27.2 debugging switch causes each :include: and ~/.forward file name to be printed before each is opened for reading:

include(file)

The -d27.2 debugging switch also causes additional information to be printed for the alias loop check described earlier:

self_reference(addr)
        ... getpwnam(user)...found      ← if in passwd file
        ... getpwnam(user)...failed     ← otherwise

The -d27.2 debugging switch also causes sendmail to print a message every time it sleeps while waiting for the aliases database to be rebuilt:

aliaswait: sleeping for secs seconds

Also, when processing the ~/.forward file, sendmail might experience a temporary inability to read it (such as when an NFS server is down). In that case the -d27.2 debugging switch causes the following message to be printed:

forward: transient error on home

Here the message will be queued and tried again later.

Forwarding path and alias wait Debug command-line switch

The -d27.3 debugging switch causes each path for a possible ~/.forward file to be printed before it is tried:

forward: trying file

Here, file is each file in the path of files declared by the ForwardPath option (ForwardPath on page 1034).

The -d27.3 debugging switch also causes sendmail to trace its wait for another alias rebuild to complete (Rebuild the Alias Database on page 478). First sendmail prints the database type (such as hash) and filename for which it will wait:

aliaswait(dbtype:file)

If the database is not rebuildable (as would be the case with a network database type, such as nis, nis+, or hesiod), the -d27.3 debugging switch causes the following to be printed:

aliaswait: not rebuildable

If the file specified doesn’t exist, the -d27.3 debugging switch prints:

aliaswait: no source file

The -d27.3 debugging switch also causes sendmail to print an error message if there was a read error while processing an :include: or ~/.forward file:

include: read error: reason here

Print not safe Debug command-line switch

A ~/.forward file must be owned by the user or by root. If it is not, it is considered unsafe, and sendmail ignores it. The -d27.4 debugging switch causes sendmail to print a message describing any such file it finds unsafe:

include: not safe (uid=user-id)

Note that a file is considered unsafe if, among other things, it lacks all read permissions.

The -d27.4 debugging switch also causes sendmail to print information about an :include: file beyond that printed with -d27.2:

include(file)                                ← printed with -d27.2
   ruid=real-user-id euid=effective-user-id       ← printed with -d27.4

This shows the real user-id (the ruid=) and effective user-id (the euid=) of the currently running sendmail.

The -d27.4 debugging switch causes sendmail to print an error if an :include: or ~/.forward file cannot be opened for reading:

include: open: reason here

Trace aliasing with printaddr( ) Debug command-line switch

The -d27.5 debugging switch tells sendmail to print several addresses with printaddr( ) (Interpret the Output on page 533) as each one is handled.

When an address is aliased to another, the original needs to be marked as one that shouldn’t be delivered. The QS_DONTSEND here means just that:

alias: QS_DONTSEND output of printaddr(  ) here (§15.3 on page 533)

If there was a self-reference, the retained address is printed like this:

sendtolist: QS_SELFREF output of printaddr(  ) here (§15.3 on page 533)

If the original (before the test for a self-reference) is not the same as the retained address, the original must be marked for nondelivery:

sendtolist: QS_DONTSEND output of printaddr(  ) here (§15.3 on page 533)

If an address resulted from an :include: or ~/.forward file, it will have a controlling user associated with it. That controlling user’s address needs to be marked for nondelivery:

include: QS_DONTSEND output of printaddr(  ) here (§15.3 on page 533)

Show setting up an alias map Debug command-line switch

The -d27.8 debugging switch tells sendmail to print the string passed to its internal setalias( ) routine:

setalias(what)

Here, what is one of the items listed with the AliasFile option (AliasFile on page 970) such as /etc/mail/aliases, or implied with the service-switch file and the ServiceSwitchFile option (ServiceSwitchFile on page 1088).

Show user-id/group-id changes with :include: reads Debug command-line switch

The -d27.9 debugging switch causes sendmail to trace the setting and resetting of its user-id and group-id identities when processing :include: and ~/.forward files. First, an additional line is printed below the output of the -d27.2 and -d27.4 debugging switches:

include(file)                             ← printed with -d27.2
   ruid=real-user-id euid=effective-user-id    ← printed with -d27.4
include: old uid = real-user-id/effective-user-id

The second and third lines contain the same information. After the new line is printed, sendmail might or might not change its identity depending on the nature of a :include: or ~/.forward file and that file’s controlling user. Regardless of whether it changed, sendmail prints:

include: new uid = real-user-id/effective-user-id

After sendmail has finished processing an :include: or ~/.forward file, it resets its user-id and group-id back to their original values and displays the result:

include: reset uid = real-user-id/effective-user-id

Trace user database transactions Debug command-line switch

The sendmail program can be compiled to use the user database (userdb on page 942) by defining USERDB in the Makefile (USERDB on page 150). If an address is selected by the parse rule set 0 for delivery by a delivery agent with the F=l flag set, and if it remains un-aliased even if the F=A flag is set and if the F=5 (F=5 on page 764) delivery agent flag is set, it is looked up in the user database. The -d28.1 (a.k.a. -d28) debugging switch is used to watch the interaction between sendmail and the user database:

udbexpand(addr)

Here, addr is the address being looked up.

The sender is looked up in a similar fashion. The intent in this case is to correct information such as the return address:

udbmatch(login, what)

Here, login is the login name of the sender and what is the mailname for sender lookups. If the lookup is via hesiod, sendmail will print the same information, like this:

hes_udb_get(login, what)

If the sender is found in the database, sendmail prints:

udbmatch =  => login@defaulthost

Here, login can be a new login name. The defaulthost is either the sitewide host for all reply mail as defined in the user database, or the default destination host for a particular user.

In the event that a db(3)-style user database fails to open, the -d28.1 debugging switch displays the following error message:

dbopen(database): reason for failure here

Special rewrite of local recipient Debug command-line switch

With a level 2 or greater configuration file (see the V configuration command in The V Configuration Command on page 580), V8 sendmail passes the user part ($u) of local recipient addresses through the localaddr rule set 5 as a hook to select a new delivery agent. If the F=5 flag (F=5 on page 764) is set for the delivery agent, the localaddr rule set 5 is called after all aliasing (including the ~/.forward file). The -d29.1 (a.k.a. -d29) debugging switch causes the address to be printed as it appears before the localaddr rule set 5 rewrite:

maplocaluser: output of printaddr(  ) here (§15.3 on page 533)

Information about the address is printed with the printaddr( ) routine. The output of maplocaluser( ) becomes the input to recipient( ), so the result of rewriting can be seen by using the -d26.1 debugging switch (-d26.1 on page 555) in combination with this one.

Trace fuzzy matching Debug command-line switch

Fuzzy matching is the attempt to match a local recipient name to one of the names in the GECOS field of the passwd(5) file (or NIS map). The -d29.4 debugging switch causes the process of fuzzy matching to be traced:

finduser(name)

Here, name is an address in the form of a local user address, without the host part. The name is first looked up in the passwd(5) file on the assumption that it is a login name. If it is found, sendmail prints:

found (non-fuzzy)

If sendmail was compiled with hesiod support, all numeric login names will not work properly, resulting in the following:

failed (numeric input)

If the name is looked up and not found, the entire passwd(5) is searched to see whether name appears in any of the GECOS fields. This search is done only if MATCHGECOS (MATCHGECOS on page 120) was defined when sendmail was compiled and if the MatchGECOS option (MatchGECOS on page 1043) is true. If MATCHGECOS was undefined, the search ends and the not-found name causes the mail to bounce. If the MatchGECOS option is false, sendmail bounces the message and prints the following:

not found (fuzzy disabled)

If the MatchGECOS option is true, the GECOS fields are searched. But before the search starts, any underscore characters (and the character defined by the BlankSub option, BlankSub on page 980) that appear in name are converted to spaces. Then, in turn, each GECOS field has the full name extracted (everything following the first comma, semicolon, or percent is truncated off, including that character), and any "&" (ampersand) characters found are converted to the login name. The two are then compared in a case-insensitive fashion. If they are identical, sendmail prints:

fuzzy matches found GECOS field here

If all GECOS fields are compared and no match is found, sendmail bounces the message and prints the following:

no fuzzy match found

There is no debugging flag to watch each comparison.

Trace processing of headers Debug command-line switch

Header lines (Overview on page 1120) from the configuration file and from mail messages are processed by the chompheader( ) routine before they are included in any mail message. That routine parses each header line to save critical information, to check for validity, and to replace default values with new values.

The -d31.2 debugging switch^[226] shows that sendmail is about to check whether it should replace a From: or Resent-From: header with the one defined by the H configuration command. If the header line is not read from the configuration file and if sendmail is not processing the queue, the following test is made:

comparing header from (header) against default (address or name)

The value of the From: or Resent-From: header is compared to the sender’s address and to the sender’s name. If it is the same as either one, the address is replaced.

Watch header assembly for output Debug command-line switch

When sendmail bounces a mail message, it needs to create headers that probably didn’t exist before. It uses the putheader( ) routine to create them. The -d34.1 (a.k.a. -d34) debugging switch causes sendmail to print the following on entry to that routine:

--- putheader, mailer = agent  ---

Here, agent is the symbolic name of the delivery agent that will deliver the bounced message.

Trace header generation and skipping Debug command-line switch

Each header line created for the bounced message is displayed with two leading spaces. For example:

--- putheader, mailer = *file* ---
  Return-Path: you

Then certain headers are excluded from the bounced mail message header. Those with the H_CTE flag set (H_CTE Header Flag (V8.7 and Later) on page 1140) and either the MCIF_CVT8TO7 or MCIF_INMIME mci flag set will have the text:

(skipped (content-transfer-encoding))

appended and that header will be skipped (excluded).

Any header that has both the H_CHECK and H_ACHECK flags set and doesn’t have identical delivery agent flags set for itself and its cached connection information will also be skipped:

(skipped)

All re-sent headers (those marked with H_RESENT) are also skipped:

(skipped (resent))

Return-receipt headers are also skipped:

(skipped (receipt))

If a Bcc: header (Bcc: on page 1152) is being skipped, this is printed:

(skipped -- bcc)

Finally, valueless headers are also skipped with this message:

(skipped -- null value)

Any headers that survive this skipping process are included in the eventually delivered bounced message. Note that MIME headers are not generated or displayed here.

Macro values defined Debug command-line switch

The -d35.9 debugging switch^[227] causes sendmail to print each macro as it is defined. The output looks like this:

define(name as "value")

Here, the name is the macro’s name, and the value is the value (text) assigned to the macro. If the macro already has a value assigned to it, sendmail prints:

redefine(name as "value")

Trace setting of options Debug command-line switch

Options can be set on the command line or in the configuration file. The -d37.1 (a.k.a. -d37) debugging switch allows you to watch each option being defined. As each is processed, this message is first printed, without a trailing newline:

setoption: name (char).sub =val

Here, name is the option’s multicharacter name, char is its single-character equivalent (or a hexadecimal value if it is non-ASCII), and sub is the subvalue for that option if there was one. Finally, val is the value being given to that option. If the option has already been set from the command line and is thus prohibited from being set in the configuration file, sendmail prints:

(ignored)

A newline is then printed, and the job is done. If defining the option is permitted, sendmail next checks to see whether it is safe (Options That Are Safe on page 951). If it is not, sendmail prints:

(unsafe)

If it is unsafe, sendmail checks to see whether it should relinquish its current privileges. If so, it prints:

(Resetting uid)

A newline is then printed, and the option has been defined.

The -d37.1 debugging switch also shows the modifier flags set for each DaemonPortOptions option. For example, consider the following:

setoption DaemonPortOptions (O)=Name=MTA
Daemon MTA flags:
setoption DaemonPortOptions (O)=Port=587, Name=MSA, M=E
Daemon MSA flags: NOETRN

The first setting of the DaemonPortOptions option sets no modifier flags, so the line following it shows no flags. The second setting of the DaemonPortOptions option sets the M=E modifier flag. The line following it shows that flag means to disallow ETRN. See DaemonPortOptions on page 993 for the meaning of the various possible modifier flags.

Trace adding of words to a class Debug command-line switch

The adding of words to a class (C or F configuration commands) can be traced with the -d37.8 debugging switch. Each word is printed like this:

setclass(name, text)

The text is added to the class whose symbolic name is name. Class names can be single-character or multicharacter (Class Configuration Commands on page 854).

Show database map opens and failures Debug command-line switch

Most database maps are declared directly with the K configuration command (The K Configuration Command on page 882). Others are declared internally by sendmail, such as the host and alias maps. The -d38.2 debugging switch (there is no -d38.1 information) first shows database maps being initialized:

map_init(dbtype:name, file, pass)

Here, dbtype is one of the internal database types allowed by sendmail, such as host, and dequote (The K Configuration Command on page 882, the K configuration command). The name is either the name you gave to the database map with the K configuration command, or one assigned internally by sendmail (such as aliases.files). The file is either a literal NULL, or the name of the database file (such as /etc/mail/aliases). And pass is a flag that tells sendmail whether it should open the database, rebuild the database, or do neither.

Next, the -d38.2 debugging switch causes sendmail to show each database map as it is about to be opened. The output that is produced will look like one of the following lines:

bt_map_open(name, file, mode)
hash_map_open(name, file, mode)
hes_map_open(name, file, mode)
impl_map_open(name, file, mode)
ldap_map_open(name, mode)
ndbm_map_open(name, file, mode)
ni_map_open(name, file, mode)
nis_map_open(name, file, mode)
nisplus_map_open(name, file, mode)
stab_map_open(name, file, mode)
switch_map_open(name, file, mode)
text_map_open(name, file, mode)
user_map_open(name, mode)

In all of the previous lines, the mode is a decimal representation of the file permissions that are used during the open. The name prefixing each line corresponds to the database type. For example, impl corresponds to the implicit database type.

The -d38.2 debugging switch also causes sendmail to display the NIS domain that was used if one was specified for the nisplus database type:

nisplus_map_open(file): using domain ypdomain

The -d38.2 debugging switch also allows other silent errors to be printed about some open failures. Under NIS+, lookups are performed by named columns (as in the case of the password database, the columns are named passwd, shell, and so on):

nisplus_map_open(name): cannot find key column colname
nisplus_map_open(name): cannot find column colname

Text files that are used as maps must be declared with a filename that is an absolute path (begins with a / character, thus forming a fully qualified pathname), that exists, and that is a regular file. If there is a problem, one of the following is logged (even if -d38.2 is not specified):

text_map_open: filename required
text_map_open(file): filename must be fully qualified
text_map_open(name): cannot stat file
text_map_open(name): file is not a file

Text files should be syntactically correct. The delimiting character, char, will print either as a single character or as the phrase (whitespace). Note that the third line in the following example will be reported only when the -d38.2 debugging switch is used:

text_map_open(file): -k should specify a number, not badtext
text_map_open(file): -v should specify a number, not badtext
text_map_open(file): delimiter = char

Show passes Debug command-line switch

The sendmail program initializes maps in passes so that it can open a map for reading or rebuild. That is, pass 0 opens it for reading only, and passes 1 and 2 open it for updating. This gives sendmail the opportunity to detect optional maps. The -d38.3 debugging switch causes sendmail to print wrong pass every time it skips rebuilding because the pass is inappropriate:

map_init(dbtype:name, file, pass) ← from -d38.2
wrong pass

The -d38.3 debugging switch also causes sendmail to print a failure message if an implicit database type does not exist:

impl_map_open(name, file, mode)   ← from -d38.2
no map file

Show result of database map open Debug command-line switch

When rebuilding the aliases files, each database file is rebuilt even if its source file has not changed. The -d38.4 debugging switch shows the success or failure of each open:

map_init(dbtype:name, file, pass)  ← from -d38.2
     dbtype:name file  valid or  invalid

The status is valid if the open succeeded; otherwise, it is invalid.

The -d38.4 debugging switch also shows each map being looked up in a switch database type (switch on page 938):

switch_map_open(name, file, mode)  ← from -d38.2
        map_stack[index] = dbtype:name

If the name was not declared in a K configuration command, the following error is printed:

Switch map dbtype: unknown member map name

Trace database map closings and appends Debug command-line switch

The -d38.9 debugging switch traces map closures for maps that can be closed:

ndbm_map_close(name, file, flags)
db_map_close(name, file, flags)
impl_map_close(name, file, flags)
ph_map_close(name): pmap-ph_fastclose=num
prog_map_lookup(name) failed (errno) -- closing
seq_map_close(name)

Here, the name is either the name you gave to the map with the K configuration command, or one assigned internally by sendmail (such as aliases.files). The file is the filename on disk that contains the database. The flags describe the specific features of a map. They are printed in hexadecimal, and the meanings of the values printed are listed in Table 15-10.

In addition to tracing map closures, the -d38.9 debugging switch traces map appends allowed by the MF_APPEND flag (-A on page 886) as specified when the database is declared by the K configuration command:

ndbm_map_store append=new
db_map_store append=new

Here, new is the new value appended to the old. Because this property is used for alias files, the new and old values have a comma inserted between them.

Trace NIS search for @:@ Debug command-line switch

The NIS alias map needs to contain an @:@ entry to indicate that it is fully updated and ready for reading. But because HP-UX omits the @:@, it is useful only as a check to see whether the NIS map exists. The -d38.10 debugging switch causes the result of this check to be printed as:

nis_map_open: yp_match(@, domain, nisdb)

Here, domain is the NIS domain, and nisdb is usually mail.aliases (but it can be redefined in your configuration file; see AliasFile on page 970). If the database map is not marked as optional (-o on page 889), the following error will be printed:

Cannot bind to map nisdb in domain domain:  reason  here

The -d38.10 debugging switch also traces the NIS+ open’s check for a valid table:

nisplus_map_open: nisplusdb.domain is not a table

Essentially, this says that the NIS+ database map nisplusdb (in the domain shown) does not exist. The error is printed even if the -o (optional) database switch (-o on page 889) is present.

Trace database map stores Debug command-line switch

The -d38.12 debugging switch shows values being stored in maps that support updates:

db_map_store(name, key, value)
ndbm_map_store(name, key, value)
seq_map_store(name, key, value)

Here, the name is either the name you gave to the database map with the K configuration command, or a name assigned internally by sendmail (such as aliases.files). The key is the key for the new value that is being stored, and the value is the value being assigned to that key.

Trace switched map finds Debug command-line switch

A switched map is one that, either as the result of a service-switch file or because of sendmail’s internal logic, causes lookups to follow a select path. For example, Sun’s Solaris 2 nsswitch.conf might specify that aliases be looked up in the order files, then nis:

switch_map_open(name, file, mode)  ← from -d38.2
switch_map_find => nummaps
                dbtype
                ...

First the number of database maps found is printed with nummaps, and then the database type for each map found in the list is printed, such as files, or nis.

Trace database map lookups Debug command-line switch

The -d38.20 debugging switch traces many different map lookups. The getcanonname( ) routine looks up a hostname and tries to canonify it:

getcanonname(host), trying dbtype
getcanonname(host), found
getcanonname(host), failed, stat=error

Here, host is the hostname that is being looked up, and dbtype is one of files, nis, nisplus, dns, or netinfo. If the canonical name is not found, the error shows one of the errors listed in <sysexits.h>. The process of canonifying the name is handled by calling special subroutines based on the dbtype:

text_getcanonname(host)                 ← dbtype is files
nis_getcanonname(host)                  ← dbtype is nis
nisplus_getcanonname(host), qbuf=query     ← dbtype is nisplus
dns_getcanonname(host, flag)              ← dbtype is dns, printed with -d8.2
ni_getcanonname(host)                   ← dbtype is netinfo

The nisplus_getcanonname( ) routine is far more verbose than the other. In addition to the preceding information, the -d38.20 switch also prints:

nisplus_getcanonname(host), got count entries, all but first ignored
nisplus_getcanonname(host), found in directory "nisdir"
nisplus_getcanonname(host), found result
nisplus_getcanonname(host), failed, status=nsistatus, nsw_stat=errno

The -d38.20 debugging switch also traces general lookups in various kinds of databases. Again note that nisplus is more verbose than the others:

ndbm_map_lookup(name, key)
db_map_lookup(name, key)
nis_map_lookup(name, key)
nisplus_map_lookup(name, key)
qbuf=query
nisplus_map_lookup(key), got count entries, additional entries ignored
nisplus_map_lookup(key), found value
nisplus_map_lookup(key), failed
hes_map_lookup(name, key)
ni_map_lookup(name, key)
stab_lookup(name, key)
impl_map_lookup(name, key)
user_map_lookup(name, key)
prog_map_lookup(name, key)
prog_map_lookup(name): empty answer
seq_map_lookup(name, key)

Here, the name is either the name you gave to the database map with the K configuration command, or one assigned internally by sendmail (such as aliases.files). The key is the item being looked up. The file is the pathname of the file that contains the database.

Trace safefile( ) Debug command-line switch

The V8 sendmail program tries to be extra careful about file permissions, and the key to checking them is the internal safefile( ) function. The -d44.4 debugging switch^[228] prints the parameters passed to the safefile( ) function:

safefile(fname, uid=uid, gid=gid, flags=sff_flags, mode=wantmode)

Here, the file named fname is being checked to determine whether the user identified by the uid, with the group gid, is allowed to find or use the file. The range of checking is determined by the hexadecimal sff_flags, described in Table 15-11. Where a file’s permissions are required, the mode printed in wantmode will be used.

If both the SFF_NOPATHCHECK flag and the SFF_SAFEDIRPATH flags are clear (are 0), sendmail examines each component of the path leading to the file. If any component of the path is rejected, the -d44.4 debugging switch causes sendmail to print:

[dir fname]  reason for the rejection here

A path component can fail because stat(2) failed. If the user-id is 0 for root, a warning is logged if a component is found to be group- or world-writable. For example:

hash map "Alias0": unsafe map file /etc/mail/aliases.db: World-writable directory

For each component in the path, safefile( ) checks to verify that this user has permission to search the directory. If the SFF_ROOTOK flag is not set (is clear), root (user-id 0) access is special-cased in that all directory components must be world-searchable.

Otherwise, the path component is accepted if it is owned by the user-id and has the user search bit set, or if its group is the same as group-id and has the group search bit set. If NO_GROUP_SET is undefined when sendmail is compiled (NO_GROUP_SET on page 130) and the DontInitGroups option (DontInitGroups on page 1023) is not set, each group to which user-id belongs is also checked. Otherwise, the directory must be world-searchable.

If the fname could not be checked with stat(2), the -d44.4 debugging switch causes the reason to be printed:

reason for failure here

If the file does not exist, it might need to be created. If so, sendmail checks to be sure that the user-id has write permission. The result is printed with the -d44.4 debugging switch like this:

[final dir fname uid user-id mode wantmode ]  error  here

If the file exists and if symbolic links are supported, the file is rejected if it is a symbolic link and if the SFF_NOSLINK flag is set. If the -d44.4 debugging switch is specified, this error is printed:

[slink mode mode]    EPERM

If the SFF_REGONLY flag is set, the file must be a regular file. If it is not, it is rejected, and -d44.4 causes the following to be printed:

[non-reg mode mode]    EPERM

If wantmode has the write bits set, and the existing file has any execute bits set, the file is rejected and -d44.4 causes the following to be printed:

[exec bits mode]    EPERM

If the file has more than one link, the file is rejected and -d44.4 causes the following to be printed:

[link count nlinks]    EPERM

If the SFF_SETUIDOK flag is specified, if SUID_ROOT_FILES_OK (SUID_ROOT_FILES_OK on page 146) was defined when sendmail was compiled,^[229] if the file exists, if it has the set-user-id bit set in the mode but no execute bits set in the mode, and if it is not owned by root, sendmail performs subsequent checks under the set-user-id and set-group-id identities of the existing file. A similar process occurs with the set-group-id bit. Sendmail then prints:

[uid new_uid, stat filemode, mode wantmode ]

If access is finally allowed, sendmail concludes with:

OK

Otherwise, it concludes with:

EACCES

Trace writable( ) Debug command-line switch

The -d44.5 debugging switch displays the values passed to sendmail’s internal writable( ) routine. This routine nearly duplicates the function of the access(3) call^[230] but does it much more safely and allows checks to be made under the identity of the controlling user:

writable(fname, sff_flags)

Here, the fname is the full pathname of the file being checked. The sff_flags are documented in Table 15-11 earlier. Success or failure is described under -d44.4.

Trace calls to the check_ rule sets Debug command-line switch

Beginning with V8.8, sendmail calls rule sets whose names begin with check_ (The Local_check_ Rule Sets on page 252) to filter incoming and outgoing mail, to accept or reject connections, and to decide on actions, such as allowing STARTTSL. The -d48.2 debugging switch^[231] can be used to display the workspace being passed to each such rule set:

rscheck(ruleset, left, right)

The ruleset is the name of the named rule set being called. If right is missing, it prints as NULL, and the workspace passed to the rule set is:

left

If right is present, the workspace is:

left $| right

Here, the $| in the workspace is the $| operator.

Trace checkcompat( ) Debug command-line switch

The checkcompat( ) routine inside conf.c can be tuned to solve many problems (see Appendix C on page 1248). The default -d49.1 (a.k.a. 49) debugging switch inside it prints the arguments that were passed to it:

checkcompat(to=recipient, from=sender)

When designing your own checkcompat( ), you should only use the -d49 category to trace it.

Show disconnect from controlling TTY Debug command-line switch

When sendmail runs as a daemon, it must disconnect itself from the terminal device that is used to run it. This prevents keyboard signals from killing it and prevents it from hanging (on a dial-in line waiting for carrier detect, for example).

The -d52.1 (a.k.a. -d52) debugging switch shows sendmail disconnecting from the controlling terminal device:

disconnect: In fd Out fd, e=addr

For both its input and output connections, the fd is a decimal representation of the file descriptor number. The addr is a hexadecimal representation of the address that contains the envelope information. If the LogLevel option (LogLevel on page 1040) is greater than 71, sendmail syslog(3)s the following message to show that it has disconnected:

in background, pid=pid

Here, pid is the process identification number of the child process (the daemon).

Prevent disconnect from controlling TTY Debug command-line switch

The -d52.100 debugging switch prevents sendmail from disconnecting from its controlling terminal device. To show that it is skipping the disconnect, it prints:

don't

This debugging switch is useful for debugging the daemon. Note that this -d52.100 prevents the detach but allows the daemon to fork(2). This differs from the behavior of the -d99.100 debugging switch (-d99.100 on page 574).

Trace database map lookups inside rewrite( ) Debug command-line switch

Rules defined by the R configuration command are rewritten by sendmail’s internal rewrite( ) subroutine. The $[ and $( lookup operators cause sendmail to look up keys in database maps.

If sendmail is running in deferred mode (DeliveryMode on page 1004), it might skip some database map lookups because they might take time to complete (as with DNS, NIS, etc.). The -d60.1 (a.k.a. -d60) debugging switch causes sendmail to print that it is skipping the lookup:

map_lookup(dbtype, key) => DEFERRED

Here, dbtype is the database map type, such as dequote or host. The key is the information being looked up.

If running in something other than deferred mode, sendmail performs the lookup. If the lookup fails (if key is not found), sendmail prints:

map_lookup(dbtype, key) => NOT FOUND (stat)

Here, stat is the number of the error that caused the failure. If it is 0, the lookup failed merely because the key was not found. Otherwise, it corresponds to the error numbers in <sysexits.h>. Then, if stat is the special value 75 (for EX_TEMPFAIL), sendmail also prints:

map_lookup(dbtype, key) tempfail: errno=err

Here, err is the error number that corresponds to the errors listed in <errno.h>.

If the key is successfully found, sendmail prints:

map_lookup(dbtype, key) => replacement  value here (stat)

Note that the replacement value will be whatever value was defined by the -a database switch (-a on page 887) when the K configuration command defined the database map.

Prevent backgrounding the daemon Debug command-line switch

The -d99.100 debugging switch^[232] prevents the sendmail daemon from forking and putting itself into the background. This leaves the running daemon connected to your terminal so that you can see other debugging output. For example:

# /usr/sbin/sendmail -bd -d99.100 -d9.30

This allows you to watch the daemon perform RFC1413 identification queries when SMTP connections are made. See also -d52.100, which prevents sendmail from disconnecting from its controlling terminal device, or the -bD command-line switch (-bD on page 233), which does both.