Table of Contents for

sendmail, 4th Edition

The Sleepycat DB library was previously called the new BSD db library. Some versions of Unix come with this library preinstalled. If your version does not, or if you already have the db library installed but it is not version 2.0 or higher, you should upgrade now. If you lack db support, you should consider installing it now.

The Sleepycat DB library supports btree, extended linear hashing, and fixed and variable-length records. It also includes transactional support, database recovery, online backups, and separate access to locking, logging, and shared memory caching subsystems. In short, this is an extremely valuable library to possess, and it greatly improves the sendmail program’s handling of aliases and map files.

This library is so key to sendmail that Build automatically includes support for it if it finds a libdb.a or libdb.so library in its search paths. All you have to do is download, compile, and install that library.

The db(3) source is available from http://www.oracle.com/database/berkeley-db/. But note that Sleepycat DB V4.1.0 through V4.1.24 does not work with V8.12.6 and earlier versions of sendmail. For later sendmail versions, see the file RELEASE_NOTES.

The sendmail/README file contains important information, and you should read that file before installing the db library.

The powerful rules in the sendmail configuration file are a good defense against spam. One method of making these rules more flexible is to add the ability to use regular expressions with the regex library. Use of the regex library is covered in regex on page 932.

If your operating system currently lacks regular expression support, you can search for a replacement on the Web. If you install your own regular expression library, avoid including the file regex.h from your standard /usr/include. If you do, sendmail will likely fail and dump core. Instead, be sure to include the regex.h from the distribution you downloaded.

Add fallback alias techniques Tune with confMAPDEF

Ordinarily, sendmail will first look for a service-switch file (ServiceSwitchFile on page 1088) to see how it should look up its aliases. If it finds one, and if the service term aliases is listed in that file, it uses the techniques listed following that term to look up its aliases. In the absence of a service switch, or if the service switch could not be opened, sendmail’s fallback position is to use the technique called files to look up its aliases.

This AUTO_NIS_ALIASES definition, when specified during compilation, also causes sendmail to automatically add the technique nis if NIS was defined or nis+ if NISPLUS was defined:

APPENDDEF(`confMAPDEF', `-DNIS -DAUTO_NIS_ALIASES')
APPENDDEF(`confMAPDEF', `-DNISPLUS -DAUTO_NIS_ALIASES')

The first line causes the fallback list of techniques to become files and then nis, and the second causes it to become files and then nisplus. Note that AUTO_NIS_ALIASES is not defined in any devtools/OS files distributed with sendmail.

If you are running a precompiled sendmail binary, you can use the -d0.10 debugging command-line switch (-d0.10 on page 543) to determine whether AUTO_NIS_ALIASES support is defined (if it appears in the list, it is defined).

Use old-style signal handling Port, edit sendmail/conf.h

Old BSD-based versions of Unix, such as SunOS 4.0.x and BSD 4.3, used the signal(2) and sigsetmask(2) calls to set and release signals. Modern versions of Unix use the sigaction(2) and sigprocmask(2) pair of routines. For all currently supported systems, BSD_3 is already correctly defined in the devtools/OS files or in sendmail/conf.h. You should need to define BSD_3 if you are porting to a previously unsupported, old BSD-based system:

APPENDDEF(`confENVDEF', `-DBSD4_3')

When porting to a new system, you can test with the preceding confENVDEF statement and, if successful, put a permanent porting entry into sendmail/conf.h. New ports should be reported to sendmail@sendmail.org so that they can be folded into future releases.

Compile for BSD 4.4 Unix Port, edit sendmail/conf.h

BSD_4 will automatically be defined when sendmail is built under the BSD 4.4 release of Unix. You will need to redefine this only if you are porting to a new operating system that is based on BSD 4.4. See the previous section for details on how to perform such a port.

Timeout for inbound SMTP DATA phase Tune with confENVDEF

Prior to V8.10, sendmail wrapped the SMTP DATA phase of sending email in a very long timeout. That timeout was calculated once, at the start of the DATA exchange, with the following formula:

timeout = size_of_message_in_bytes / 16
if timeout < 600
        then timeout = 600
timeout = timeout + ( number_of_recipients * 300 )

Thus, a 1,000-byte message to one recipient would have a total of 362 seconds in which to complete its SMTP DATA send phase. But a 1,000-byte message to 10 recipients would have 3,062 seconds for each recipient. Thus, under this formula, bulk email (the type of mail one would want to timeout quickly) would instead get the most generous timeouts.

Beginning with V8.10, sendmail uses a fixed window of time during which the SMTP DATA phase must show some progress. That window size is defined at compile time with this DATA_PROGRESS_TIMEOUT compile-time macro. The default is 300 seconds, which should be just right for most sites. If you need to change this timeout, you can do so in your Build m4 file like this:

APPENDDEF(`confENVDEF', `-DDATA_PROGRESS_TIMEOUT=600')

Here, we double the timeout from 5 to 10 minutes. Before changing this timeout, however, you should run with your standard timeout and monitor the logs for messages such as this:

451 4.4.1 timeout writing message to host

If such warnings are frequent, and if mail to host predictably fails, you might need to increase this timeout a bit and experiment again. Wholesale increases are discouraged because slow receiving hosts are usually slow only during the busy times of the day.

Enable use of dns databases Tune with confMAPDEF

DNS stands for the Domain Name System protocol. DNS provides access to information about hostnames and addresses. DNS is covered fully in Chapter 9 on page 321.

This DNSMAP compile-time macro, when defined with V8.12 sendmail and above, allows you to look up host and address information inside your configuration file using the dns database map type (dns on page 905). You enable the dns database map type in your Build m4 file like this:

APPENDDEF(`conf_sendmail_MAPDEF', `-DDNSMAP=1')

This definition will silently fail if you do not also define NAMED_BIND (NAMED_BIND on page 124) to include general DNS support inside sendmail. Normally, NAMED_BIND is defined by default, so that should not be a problem.

If you wish to use the enhdnsbl feature (FEATURE(enhdnsbl) on page 263) for improved spam screening, you must define this DNSMAP compile-time macro when building sendmail.

If you are running a precompiled sendmail binary, you can use the -d0.1 debugging command-line switch (-d0.1 on page 542) to determine whether DNSMAP support is included (if it appears in the list, support is included).

Support Delivery Status Notification Tune with confENVDEF

Delivery Status Notification (DSN) replaces certain SMTP error codes and the Return-Receipt-To: header (Return-Receipt-To: on page 1165) as a means of handling multiple delivery status requests and problems. DSN is an improvement over earlier mechanisms for returning delivery status information. It can, for example, supply different status information for each recipient when multiple recipients are specified. It can also be used to generate return receipts on a per-recipient basis. DSN status is returned in the MIME encapsulated portion of a mail message’s body.

DSN is defined in RFC1891, RFC1892, RFC1893, and RFC1894. If you wish to exclude DSN support (not recommended), you can turn it off with a line such as the following in your Build m4 file:

APPENDDEF(`confENVDEF', `-DDSN=0')
                               ↑
                     turn off DSN support

There is no debugging command-line switch to determine whether DSN was defined for a precompiled version of sendmail. Instead, you must run sendmail with the -bs command-line switch and issue the EHLO SMTP command. If the following line shows up, it was defined:

250-DSN

If this line does not appear, check to see whether noreceipts is defined for the PrivacyOptions option (PrivacyOptions=noreceipts on page 1068). If it was, you will have to undefine it for this line to appear. Otherwise, if this line does not appear, you will have to get either a new version of sendmail from your vendor, or open source sendmail and build it yourself.

Enable use of the EGD daemon Port with confENVDEF

EGD, which stands for Entropy Gathering Daemon, is a persistent daemon that provides pseudorandom numbers via a Unix socket. Obtaining this daemon and configuring for its use are described in EGD on page 204. To allow code to be included inside sendmail so that it can use this EGD daemon, you must define this EGD compile-time macro:

APPENDDEF(`confENVDEF', `-DEGD=1')

This definition is needed only on machines that lack /dev/urandom. If you are running a precompiled sendmail binary, you can use the -d0.1 debugging command-line switch (-d0.1 on page 542) to determine whether EGD support is included (if it appears in the list, support is included).

Correct conflicts on sys_errlist Port, edit sendmail/conf.h

Some systems define a type for sys_errlist[ ] that differs from the internal declaration made by sendmail. In such instances, you will get a warning about sys_errlist being redefined when you compile. Such warnings are usually harmless, but they are unattractive. To eliminate them, add the following to your Build m4 file:

APPENDDEF(`confENVDEF', `-DERRLIST_PREDEFINED')

When porting to a new system, you can test with the preceding confENVDEF build macro statement and, if successful, put a permanent porting entry into sendmail/conf.h. New ports should be reported to sendmail@sendmail.org so that they can be folded into future releases.

Quick reuse of pids Port, edit sendmail/conf.h

The sendmail program forks to do its job. Each child process has its own process ID number (pid) which it uses when creating queue filenames. Ordinarily, the uniqueness of each pid prevents any two children from creating identical queue names during any one-second interval. But on fast machines with short pid ranges, there is a risk that one client might exit and another might start within one second, and the second client will be issued the same pid as the first.

On such machines, the FAST_PID_RECYCLE compile-time macro is defined to prevent just such a collision of pid numbers. In general, this compile-time macro is correctly defined for all currently supported architectures. You will need to define it yourself only if you are porting sendmail to a new system. New ports should be reported to sendmail@sendmail.org so that they can be folded into future releases.

If you are running a precompiled sendmail binary, you can use the -d0.10 debugging command-line switch (-d0.10 on page 543) to determine whether FAST_PID_RECYCLE support is defined (if it appears in the list, it is defined).

Try using future features Tune with confENVDEF

Inside the sendmail code are pieces of new code, which can add new features, options, macros, and the like, that might appear in V8.13 and above versions of sendmail. You can include any of these new pieces of code by defining one of the following _FFR (For Future Release) m4 Build macros when building sendmail:

APPENDDEF(`conf_sendmail_ENVDEF', `-D_FFR_what''    ← affects sendmail only
APPENDDEF(`conf_makemap_ENVDEF', `-D_FFR_what')     ← affects makemap only
APPENDDEF(`confENVDEF', `-D_FFR_what')              ← affects all programs

Here, what describes the appropriate future item that you want to include (as found in the source). Consider the following example:

APPENDDEF(`confENVDEF', `-D_FFR_QUARANTINE=1')

Here, the _FFR_QUARANTINE m4 Build macro is defined so that the sendmail and mailstats programs can support queue quarantining of messages.

If you are running a precompiled binary of sendmail, you can determine whether any of the _FFR macros were defined when sendmail was compiled by using the -d0.13 debugging switch (-d0.13 on page 544):

% /usr/sbin/sendmail -d0.13 -bt
Version 8.14.1
 Compiled with: DNSMAP LOG MAP_REGEX MILTER MIME7TO8 MIME8TO7 NAMED_BIND
etc ...
  FFR Defines: _FFR_QUARANTINE          ← note
etc ...

Note that by running any of the sendmail suite of programs with an FFR defined, you are, in effect, acting as a guinea pig for the sendmail development team. You will be utilizing new features in production and, by doing so, can uncover bugs that will help solidify the code before it is released to the public. If you elect to do this, and if mail delivery breaks, first install a clean (non-_FFR) version of sendmail to determine whether the _FFR was responsible. If it turns out to be responsible, describe the problem in detail, include your mc configuration file (not your cf file) and any log messages of relevance, and send that information to sendmail-bugs@sendmail.org.

The type of fork to use Port, edit sendmail/conf.h

The sendmail program forks often to do its job in the most efficient way possible. Prior to V8.8, sendmail used vfork(2) whenever possible. Beginning with V8.8, sendmail now defaults to fork(2).^[52] You should have to redefine FORK only when porting to a new system or when you are certain that vfork(2) is, indeed, faster on your system and is reliable. To add it to sendmail (and other programs that use FORK), place a line such as the following in your Build m4 file:

APPENDDEF(`confENVDEF', `-DFORK=vfork')

You can test with the preceding confENVDEF statement and, if successful, put a permanent porting entry into sendmail/conf.h. New ports should be reported to sendmail@sendmail.org so that they can be folded into future releases.

Has specific system-call support Port, edit sendmail/conf.h

Macros that begin with HAS tell sendmail whether your system supports (has) certain system-library routines or variables. In general, you should need to define or undefine the compile-time macros shown in Table 3-3 only if you are porting sendmail to a new system. In that instance, you should also read sendmail/README for the latest information and pitfalls.

Each of these is turned on or off with an assignment of 1 or 0:

APPENDDEF(`confENVDEF', `-DHASSETSID=1')      ← turn on
APPENDDEF(`confENVDEF', `-DHASSETSID=0')      ← turn off

“Turning on” tells sendmail that your site has support for this system call (setsid(2) in this instance). “Turning off” tells sendmail to work around the lack of that support. When porting to a new system, you can test with one of the preceding confENVDEF statements and, if successful, put a permanent porting entry into sendmail/conf.h.

If you are running a precompiled binary of sendmail, you can use the -d0.10 debugging switch (-d0.10 on page 543) to determine whether any of these are defined (each is defined that appears in the list). New ports should be reported to sendmail@sendmail.org so that they can be folded into future releases.

Support hesiod database maps Tune with confMAPDEF

Named after the eighth-century B.C.E.^[53] Greek poet Hesiod, the hesiod system is a network information system developed as Project Athena. Information that is shared among many machines on a network can be accessed by each machine using a common set of library routines. Files that are commonly represented in this form are the passwd(4) and aliases(4) files used by sendmail. The hesiod system is patterned after the Internet DNS and uses BIND source.

The HESIOD compile-time macro is used to enable use of the hesiod system. This macro is defined as zero (no hesiod) for all operating systems that are currently supported. To enable hesiod, add the following line to your Build m4 file:

APPENDDEF(`confMAPDEF', `-DHESIOD')

If HESIOD is defined when sendmail is built, support is included to look up aliases via the hesiod interface. Support is also included to declare and use hesiod class maps (The type on page 882) with the K configuration command. Support is also included to use hesiod with the User Database if USERDB is also defined.

Documentation and source are available from HESIOD:

ftp://athena-dist.mit.edu/pub/ATHENA/hesiod/

If you are running a precompiled sendmail binary, you can use the -d0.1 debugging command-line switch (-d0.1 on page 542) to determine whether HESIOD support is included (if it appears in the list, support is included).

Use hesiod hes_getmailhost( ) Tune with confENVDEF

The MIT distribution of hesiod supports the hes_getmailhost(3) call for looking up a user’s post office. If your site is running MIT’s hesiod, you should define this. If you are running DEC’s hesiod, you should not:

APPENDDEF(`confENVDEF', `-DHES_GETMAILHOST')

HES_GETMAILHOST is, by default, not defined. If you need it, you must define it in your Build m4 file.

If you are running a precompiled sendmail binary, you can use the -d0.1 debugging command-line switch (-d0.1 on page 542) to determine whether HES_GETMAILHOST support is included (if it appears in the list, support is included).

See Timeout.ident in Timeout.ident (V8.6 and later) on page 1104 port

Defining IDENTPROTO neither includes nor excludes RFC1413 code. All it does is change the default value for the Timeout.ident option (Timeout.ident (V8.6 and later) on page 1104):

APPENDDEF(`confENVDEF', `-DIDENTPROTO=0')     ← set Timeout.ident=0 by default
APPENDDEF(`confENVDEF', `-DIDENTPROTO=1')     ← set Timeout.ident=30 by default

If you are running a precompiled sendmail binary, you can use the -d0.10 debugging command-line switch (-d0.10 on page 543) to determine whether IDENTPROTO support is defined (if it appears in the list, it is set to 1). New ports should be reported to sendmail@sendmail.org so that they can be folded into future releases.

Add IP source-routing to $_ Tune with confENVDEF

Mail is normally transported over networks with TCP/IP. At the IP layer, packets are usually constructed to be point-to-point—from one host to another. IP packets can also be constructed to contain source-routing information—from one host, through a second, then to a final host.

Although such source routing (when used) is generally legitimate, it can also be used to generate fraudulent mail. V8.7 and above sendmail attempt to extract source-routing information from the initial connection’s IP information. If any is found, sendmail adds that information to the $_ defined macro ($_ on page 801) for use in the Received: header (Received: on page 1162). The $_ defined macro is usually used like this:

Received: from $s ($_) ...

where $_ will contain information such as the following when IP source-routing information is found:

IP source-routing information
             ↓
 user@host.domain [!@hostC@hostB:hostA]
  ↑
 RFC1413 identd information

IP source-routing information is presented inside square brackets. If routing is strict, the information is prefixed with an exclamation mark. The format of the information is made to resemble that of source-route addressing (see also the DontPruneRoutes option, DontPruneRoutes on page 1024). In this example, the IP packets will go first to hostC, then to hostB, and finally to hostA.

The inclusion of code to support this reporting is determined by the IP_SRCROUTE definition in your Build m4 file:

APPENDDEF(`confENVDEF', `-DIP_SRCROUTE=1')     ← turn on support
APPENDDEF(`confENVDEF', `-DIP_SRCROUTE=0')     ← turn off support

It is predefined correctly for all supported systems in sendmail/conf.h. If you wish to disable this, you can. But in general, you should need to redefine it only if you are porting sendmail to a completely new system. Be sure to read sendmail/README for the latest information about IP_SRCROUTE.

If you are running a precompiled sendmail binary, you can use the -d0.10 debugging command-line switch (-d0.10 on page 543) to determine whether IP_SRCROUTE support is defined (if it appears in the list, it is defined).

Things that can be broken Port, edit sendmail/conf.h

Not all versions of Unix are equal. Some implement important library routines in ways that are considered broken. For sendmail to work properly on such systems, it needs to know at compile time whether it is being built on such a broken system. The compile-time macros that convey this information to sendmail are listed and described in Table 3-4.

Usually, you will not have to define any of these compile-time macros unless you are porting sendmail to a completely new system.

If you are running a precompiled sendmail, you can use the -d0.10 debugging command-line switch (-d0.10 on page 543) to determine whether any are supported (each is supported that appears in the list). New ports should be reported to sendmail@sendmail.org so that they can be folded into future releases.

Define your load-average support Port, edit sendmail/conf.h

The load average is the average number of blocked processes (processes that are runnable but not able to run because of a lack of resources) over the last minute. The sendmail program can vary its behavior appropriately as the load average changes. Thresholds for change are defined by the options shown in Table 24-9 in Controlling Machine Load .

The method that is used to get the current load average from the operating system varies widely. This LA_TYPE definition determines which method to use. It is correctly defined inside sendmail/conf.h for all currently supported operating systems. Porting sendmail to a new system might require that you define LA_TYPE yourself. The possible values and their meanings are shown in Table 3-5.

The LA_INT, LA_SHORT, LA_FLOAT, and LA_READKSYM settings require additional tuning. For these, additional definitions are used, as shown in Table 3-6.

New ports should be reported to sendmail@sendmail.org so that they can be folded into future releases.

Enable use of ldap databases Tune with confMAPDEF

LDAP stands for Lightweight Directory Access Protocol. LDAP provides lightweight access to the X.500 directory and is defined in RFC1777 and RFC1778.

The software and documentation for LDAP are available as open source from the following site:

http://www.openldap.org/                     ← The OpenLDAP Project

The software is also available commercially from Netscape, Inc.

To enable use of ldap database maps (-q on page 912) in your configuration file, enabled this LDAPMAP compile-time macro in your Build m4 file:

APPENDDEF(`confMAPDEF', `-DLDAPMAP')

If you are running a precompiled sendmail binary, you can use the -d0.10 debugging command-line switch (-d0.10 on page 543) to determine whether LDAPMAP support is defined (if it appears in the list, it is defined).

Perform logging Port, edit sendmail/conf.h

If defined, LOG enables sendmail to use the syslog(3) facility to log error messages and other useful information that is often important for security and debugging. Logging and syslog(3) are described in Chapter 14 on page 508. Defining LOG should be considered mandatory, and LOG should be turned off only if you have a well-thought-out reason for doing so. LOG cannot be turned off in your Build m4 file. Instead, you must edit sendmail/conf.h directly and undefine it by commenting it out:

/* # define LOG           1          /* enable logging -- don't turn off */
 ↑
comment out to remove support

The LOG compile-time macro requires that your system support syslog(3). If you lack syslog(3), consider porting it to your system.

Defining LOG is meaningless unless the LogLevel option (LogLevel on page 1040) is also nonzero. Fortunately, this is usually the case because the default is 9. See also SYSLOG_BUFSIZE (SYSLOG_BUFSIZE on page 147) for a way to tune syslog(3)’s buffer size if necessary.

If you are running a precompiled sendmail binary, you can use the -d0.1 debugging command-line switch (-d0.1 on page 542) to determine whether LOG support is included (if it appears in the list, support is included). New ports should be reported to sendmail@sendmail.org so that they can be folded into future releases.

Support fuzzy name matching Tune with confENVDEF

Defining MATCHGECOS causes code to be included inside sendmail for support of limited fuzzy name matching. This process is described under the MatchGECOS option (MatchGECOS on page 1043). This MATCHGECOS compile-time macro is normally defined as true by default. If you want to turn it off, use an expression such as this in your Build m4 file:

APPENDDEF(`conf_sendmail_ENVDEF', `-DMATCHGECOS=0')
                                                ↑
                             disable fuzzy name matching inside sendmail

If you are running a precompiled sendmail binary, you can use the -d0.1 debugging command-line switch (-d0.1 on page 542) to determine whether MATCHGECOS support is included (if it appears in the list, support is included).

Redefine maximums Port, edit specific files

When porting sendmail to a new system or tuning it for special needs, you might need to adjust one of sendmail’s predefined maximums. These cannot be tuned in your Build m4 file. Instead, each needs to be changed in the file indicated by the third column of Table 3-7. In general, maximums should never be changed in either direction without first examining the code for possible side effects. Check to see if any minimums are required or if any warnings about maximums are evident in the code or in a README file. Some of these limits are defined by RFC, and should not be changed from the standard set by the appropriate RFC.

Also see QUEUESEGSIZE (QUEUESEGSIZE on page 136) and SYSLOG_BUFSIZE (SYSLOG_BUFSIZE on page 147) for a discussion of two other definitions that affect sizes.

Note that there are no debugging switches for displaying compiled maximums. If you are running a binary distribution and a maximum is of concern, you should get the source and build sendmail yourself.

Beginning with V8.12, sendmail offers several macros that slow down sendmail to prevent certain types of attacks. They are listed in Table 3-8, which also shows their default settings. Unlike the MAX... compile-time macros shown in Table 3-7, these can be tuned as part of your Build m4 file. For example, to change the maximum number of NOOP SMTP commands that can be received before sendmail slows itself down defensively, you can add the following line to your Build m4 file:

APPENDDEF(`conf_sendmail_ENVDEF', `-DMAXNOOPCOMMANDS=30')
                                                     ↑
                                   increase from the default of 20

If any of these SMTP-limiting compile-time macros are defined with a zero value, the corresponding check is disabled. There is no debugging command-line switch to display defaults with a precompiled sendmail. If you need to change any of these default settings, you must download and build sendmail yourself.

Specify memory allocation size Tune, edit sendmail/conf.h

When sendmail reads lines of text from the configuration file or from qf queue files, it calls an internal routine named fgetfolded( ). That routine is initially passed a buffer of size MAXLINE into which to fit the read line. If the line is longer than MAXLINE, the sendmail program dynamically increases the space required to hold the line by MEMCHUNKSIZE.

When collecting the headers of a mail message, sendmail also begins with a buffer sized to MAXLINE. If a header arrives that is larger than MAXLINE characters, sendmail will increase the size of its buffer by MEMCHUNKSIZE as many times as is necessary to fully contain that header’s data up to but not exceeding the value of the MaxHeadersLength option (MaxHeadersLength on page 1045).

The default value assigned to MEMCHUNKSIZE is 1,024 bytes. If you need to change that value (for example, to port to a new system’s strange malloc(3) requirements or for performance reasons), you must edit sendmail/conf.h:

# define MEMCHUNKSIZE   1024            /* chunk size for memory allocation */
                        ↑
         change this to your new value

There is no debugging command-line switch to display this size for a precompiled sendmail. If this size is of concern, you must either discuss it with your vendor or download and build open source sendmail.

Enable the X configuration command (V8.11 and above) Tune with confENVDEF

The MILTER compile-time macro turns on support for the V8.12 X configuration command, and is covered completely in Pre-V8.13 Enable with -DMILTER on page 1170.

Support MIME 7-to-8-bit conversion Tune with confENVDEF

V8.8 sendmail and above contain the internal ability to convert messages that were converted into either quoted-printable or base64 (EightBitMode on page 1025) back into their original 8-bit form. The decision to make this conversion is based on the F=9 delivery agent flag (F=9 on page 765).

Defining MIME7TO8 to a value of 1 causes support for conversion to be included in sendmail. It is defined as 1 by default. To disable the inclusion of conversion code, add a line such as the following to your Build m4 file:

APPENDDEF(`confENVDEF', `-DMIME7TO8=0')
                                    ↑
                              exclude support

If you are running a precompiled sendmail binary, you can use the -d0.1 debugging command-line switch (-d0.1 on page 542) to determine whether MIME7TO8 support is included (if it appears in the list, support is included).

Support MIME 8- to 7-bit conversion Tune with confENVDEF

V8 sendmail contains the internal ability to convert 8-bit MIME message content into 7-bit MIME so that mail can be transported through non-8-bit gateways. The methods used and the circumstances required to trigger conversion are described under the EightBitMode option (EightBitMode on page 1025).

Defining MIME8TO7 to a value of 1 causes support for conversion to be included in sendmail. It is defined as 1 by default. To disable the inclusion of conversion code, add a line like the following to your Build m4 file:

APPENDDEF(`confENVDEF', `-DMIME8TO7=0')
                                    ↑
                         exclude support

One side effect of defining MIME8TO7 to 0 is that it causes all MIME support to also be excluded. Unless you have a compelling reason to do otherwise, we recommend that MIME8TO7 remain enabled.

If you are running a precompiled sendmail binary, you can use the -d0.1 debugging command-line switch (-d0.1 on page 542) to determine whether MIME8TO7 support is included (if it appears in the list, support is included).

Support DNS name resolution Tune with confENVDEF

The sendmail program automatically takes advantage of DNS lookups or MX records to resolve addresses and canonical hostnames. If your site is a UUCP-only site (or is otherwise not connected to the Internet) and does not run named(8) locally, you should probably disable NAMED_BIND:

APPENDDEF(`confENVDEF', `-DNAMED_BIND=0')
                                      ↑
                           disable DNS lookups

If you are running a precompiled sendmail binary, you can use the -d0.1 debugging command-line switch (-d0.1 on page 542) to determine whether NAMED_BIND support is included (if it appears in the list, support is included).

Add support for IRIX nsd maps (V8.10 and above) Tune with confMAPDEF

The nsd class of map implements an interface to the Unified Name Service supplied under IRIX 6.5 and above. This class of map is described in detail in -z on page 929. If you wish support for this class to be included when you compile sendmail, declare MAP_NSD in your Build m4 file like this:

APPENDDEF(`confMAPDEF', `-DMAP_NSD')

If you are running a precompiled sendmail binary, you can use the -d0.10 debugging command-line switch (-d0.10 on page 543) to determine whether MAP_NSD support is defined (if it appears in the list, it is defined).

Use regular expression maps (V8.9 and above) Tune with confMAPDEF

It might be desirable to match addresses to regular expressions in rule sets. One way to do this is with the regex class of database map (sequence on page 935). If such support is desirable, you can enable inclusion by declaring MAP_REGEX in your Build m4 file like this:

APPENDDEF(`confMAPDEF', `-DMAP_REGEX')

But just defining MAP_REGEX does not guarantee that sendmail will compile with support for it. If you get one of the following errors, or something similar, your C-language library lacks support for the required POSIX regular expression library routines:

undefined reference to 'regcomp'
or
pattern-compile-error: : Operation not applicable
or
ld: Undefined symbol
   _regexec
   _regcomp
   _regerror

If you lack the needed library support, see The regex Library on page 104 for instructions on how to download and install regex libraries.

If you are running a precompiled sendmail binary, you can use the -d0.10 debugging command-line switch (-d0.10 on page 543) to determine if MAP_REGEX support is defined (if it appears in the list, it is defined).

Support Unix ndbm(3) databases Tune with confMAPDEF

The ndbm(3) form of database uses two files (.pag and .dir) for each database. Databases cannot be shared by different architectures across a network. If you intend to support aliasing in an efficient manner, you should at least define this NDBM (or NEWDB, described next) in your Build m4 file:

APPENDDEF(`confMAPDEF', `-DNDBM')

The ndbm(3) routines are used primarily to look up aliases. They can also be used to declare dbm-type maps (The type on page 882) with the K configuration command.

Library routines to support ndbm(3) are available with most modern commercial versions of Unix. You might have to specify library support with an -lndbm in the confLIBS line of your Build m4 file. If you are running a precompiled sendmail binary, you can use the -d0.1 debugging command-line switch (-d0.1 on page 542) to determine whether NDBM support is included (if it appears in the list, support is included).

If, when you build sendmail, you get an error something like this:

"map.c", line 23: syntax error at or near variable name "README"

you are using a defectively installed db library. Versions of the db package from 2.0 through 2.3.1 can interfere with ndbm, unless precautionary steps are taken. Read the file sendmail/README for a description of how to correct this problem.

Something amiss with your OS? Port with confENVDEF

The sendmail program requires certain C-language library routines to exist. If any are missing from your library, define the macro listed in Table 3-9 that seems to fill your needs, and sendmail will try to emulate that need.

Each macro is defined with confENVDEF in your Build m4 file by setting it to a value of 1 (NEEDPUTENV is an exception in that 1 or 2 can be used):

APPENDDEF(`confENVDEF', `-DNEEDFSYNC=1')

Note that these are correctly defined for all currently supported systems. You should need to redefine them only if you are porting sendmail to a completely new system.

If you are running a precompiled sendmail binary, you can use the -d0.10 debugging command-line switch (-d0.10 on page 543) to determine whether NEEDFSYNC support is defined (if it appears in the list, it is defined). New ports should be reported to sendmail@sendmail.org so that they can be folded into future releases.

Define for network support Tune with confENVDEF

Beginning with V8.10, sendmail is designed to support six kinds of network sockets, as listed in Table 3-10. Currently, NETNS and NETX25 are accepted but not implemented.

Stubs are included in the source code for any programmer who is interested in implementing NETNS or NETX25. In general, the others are already declared appropriately for your system. Should you desire to change one, you can do so in your Build m4 file. The following, for example, removes support for IPv4 from sendmail:

APPENDDEF(`confENVDEF', `-DNETINET=0')

Defining network support only causes the code for that network to be included in sendmail. The network serviced by a particular invocation of sendmail is selected with the Family parameter of the DaemonPortOptions option (DaemonPortOptions on page 993). In the absence of an option declaration, IPv4 (for NETINET) is used as the default.

If you are running a precompiled sendmail binary, you can use the -d0.1 debugging command-line switch (-d0.1 on page 542) to determine which network types are supported (if any appear in the list, support is included).

Support NeXT netinfo(3) databases Tune with confMAPDEF

The netinfo(3) form of database is supplied with the NeXT, NeXTSTeP, OpenStep, Darwin, Mac OS 10.0, and Mac OS X operating systems. It is a network information service that provides file contents such as aliases and passwd, and locations such as the location of the sendmail.cf file. If you are running on a NeXT or under NeXTSTeP, this NETINFO will automatically be defined in your operating system’s devtools/OS file. If you also define AUTO_NETINFO_ALIASES, NETINFO will automatically be used to resolve aliases. Otherwise, you will need to enable that use by declaring netinfo: in an alias declaration or by including netinfo in your service switch file (The aliases(5) File’s Location on page 461).

The netinfo(3) databases can also be used to declare netinfo type maps (The type on page 882) with the K configuration command.

If you are running a precompiled sendmail binary, you can use the -d0.1 debugging command-line switch (-d0.1 on page 542) to determine whether NETINFO support is included (if it appears in the list, support is included).

Support Berkeley db(3) databases Tune with confMAPDEF

The db(3) form of database uses a single file and can be shared by different architectures. If you intend to support aliasing in an efficient manner, you should at least define this NEWDB (or the NDBM described earlier) in your Build m4 file. The db(3) routines are used to look up aliases and are the routines used by the User Database (userdb on page 942). They can also be used to declare hash and btree type maps (The type on page 882) with the K configuration command.

The db(3) libraries have overcome many of the limitations of the earlier ndbm(3) libraries. If possible, you should get and install the db(3) libraries before you build sendmail (see The Sleepycat DB Library on page 104 for a guide to downloading these libraries).

If you are running a precompiled sendmail binary, you can use the -d0.1 debugging command-line switch (-d0.1 on page 542) to determine whether NEWDB support is included (if it appears in the list, support is included).

Support for nis database maps Tune with confMAPDEF

NIS stands for Network Information Services. If you intend to have sendmail support nis (formerly Yellow Pages) maps, you need to define NIS with a line such as the following in your Build m4 file:

APPENDDEF(`confMAPDEF', `-DNIS')

If NIS is defined, the AliasFile option can be specified as:

OAnis:mail.aliases                ← V8.6
O AliasFile=nis:mail.aliases      ← V8.7 and above (if no service-switch file)

See AliasFile on page 970 for more details about the AliasFile option. See ServiceSwitchFile on page 1088 for a description of the ServiceSwitchFile option and its effect on nis aliases. Be aware that the preceding AliasFile option declaration will override the lack of an nis entry in the service-switch file.

NDBM also needs to be defined to allow sendmail to rebuild its alias files for use by nis:

APPENDDEF(`confMAPDEF', `-DNIS -DNDBM')

For this to work, the path of the alias file needs to contain the substring:

/yp/

A typical /var/yp/Makefile will contain a line such as this:

/usr/lib/sendmail -bi -oA$(YPDBDIR)/$(DOM)/mail.aliases

Here, $(YPDBDIR)/ is usually /var/yp/, so the substring is found. When the substring /yp/ is found, sendmail augments the aliases database with two special entries that are needed by nis:

YP_LAST_MODIFIED
YP_MASTER_NAME

These allow the newly built aliases file to be successfully distributed for use by nis clients. Without these entries you will see an error such as the following when pushing your nis maps:

Status received from ypxfr on nisslave:
        Failed - no local order number in map - use -f flag to ypxfr.

The solution here is to rebuild sendmail with both NDBM and NIS defined.

Defining NIS also causes support to be included for declaring and using nis-type maps (The type on page 882) with the K configuration command.

Note that defining NIS without also defining NAMED_BIND will cause delivery to MX records to mysteriously fail.

If you are running a precompiled sendmail binary, you can use the -d0.1 debugging command-line switch (-d0.1 on page 542) to determine whether NIS support is included (if it appears in the list, support is included).

Support for nisplus database maps Tune with confMAPDEF

If you intend to have sendmail support nisplus maps, you need to define NISPLUS in your Build m4 file (the use of nisplus aliases and other maps is determined by the /etc/nsswitch.conf file):

APPENDDEF(`confMAPDEF', `-DNISPLUS')

If NISPLUS is defined, the AliasFile option can be used to override the setting of the /etc/nsswitch.conf file:

O AliasFile=nisplus:mail.aliases      ← V8.7 and above

Here, nisplus aliases will be used even if the /etc/nsswitch.conf file excludes them.

See Alphabetized Options on page 970 for details about the AliasFile option. Note that NISPLUS is new beginning with V8.7 and is not supported under earlier versions of sendmail.

With NISPLUS defined, support is also included to declare and use nisplus-type maps (The type on page 882) with the K configuration command.

If you are running a precompiled sendmail binary, you can use the -d0.1 debugging command-line switch (-d0.1 on page 542) to determine whether NISPLUS support is included (if it appears in the list, support is included).

Lack ftruncate(2) support Port, edit sendmail/conf.h

Beginning with V8.10, sendmail uses the ftruncate(2) system call to truncate NDBM-style aliases database files before rebuilding them. This avoids a potential race condition that could yield false results when one sendmail reads the database at the precise moment another sendmail starts to rebuild.

Also, when sendmail delivers mail directly to a file, an error can occur while writing that can leave the file in an inconsistent state. Beginning with V8.10, sendmail truncates the file to its original length if an error occurs while writing.

Another, less serious, race condition can exist when sendmail writes one of its Host Status files, as defined by the HostStatusDirectory option (HostStatusDirectory on page 1037). If ftruncate(2) is available, sendmail truncates each file before writing new information.

Finally, note that when a MILTER program rewrites the message body, sendmail must truncate the df file before writing the new text.

For all currently supported systems that lack ftruncate(2), this NOFTRUNCATE compile-time macro is correctly defined. You will need only to define it when porting sendmail to a completely new system.

If you are running a precompiled sendmail binary, you can use the -d0.10 debugging command-line switch (-d0.10 on page 543) to determine whether NOFTRUNCATE support is defined (if it appears in the list, it is defined). New ports should be reported to sendmail@sendmail.org so that they can be folded into future releases.

Prevent multigroup file access Port, edit sendmail/conf.h

When checking files and directories for group read and write permissions, sendmail checks the group of the controlling user. On systems that allow a user to belong to one group at a time, failure stops here with the check for that one group. On systems that allow users to belong to many groups at once, failure causes sendmail to check the other groups to which the controlling user might belong. It finds the list of groups by calling getgrgid(3).

If your system lacks the getgrgid(3) call or doesn’t need it, you should exclude this code by defining NO_GROUP_SET in sendmail/conf.h. NO_GROUP_SET causes the code containing the call to getgrgid(3) to be excluded from sendmail. Be aware that excluding getgrgid(3) support on systems that need it can cause delivery to files to fail in mysterious ways.

If you are running a precompiled version of sendmail, be aware that there is no debugging switch that can tell you what the setting of NO_GROUP_SET was set to at compile time.

Note that NO_GROUP_SET affects only inclusion of the getgrgid(3) system call. See the DontInitGroups option (DontInitGroups on page 1023) for a means to exclude the getgrgid(3) and initgroups(3) system calls by means of your configuration file.

New ports should be reported to sendmail@sendmail.org so that they can be folded into future releases.

Exclude “From " line support Tune with confENVDEF

Under Unix, a file of many mail messages normally has one message separated from another by a blank line and then a line that begins with the five characters "From" (four letters and a space). On such systems, sendmail saves important information from such lines for later use.

On non-Unix machines (VMS or NT) the conventions are different, so you won’t want sendmail to treat such lines as special. Similarly, if your Unix site has converted entirely away from this convention (with mhs or the like), you might not want this special treatment.

To disable special treatment of "From" lines, define the NOTUNIX compile-time macro in your Build m4 file:

APPENDDEF(`confENVDEF', `-DNOTUNIX')

Defining NOTUNIX causes the code for eatfrom( ) to be excluded from sendmail. The -d30.2 debugging switch can be used to watch eatfrom( ) and to determine whether NOTUNIX was declared when compiling sendmail.

Hardcoded paths inside sendmail Tune with confENVDEF

Only a few pathnames are hardcoded into sendmail. The most obvious is its configuration file because that file lists the locations of nearly all other files. For various reasons, a few other file locations are also hardcoded. Here, we describe those that you can change. Note that the general form for all such changes uses the confENVDEF declaration in your Build m4 file:

APPENDDEF(`confENVDEF', `-D_PATH...=\"/new/path/filename\"')

The new path must be surrounded by backslashed quotation marks so that the compiler will correctly interpret it as a string.

If your version of Unix is one that does not have a prior default (see the sendmail/conf.h file), you can give sendmail one by defining the _PATH_VENDOR_CF too:

APPENDDEF(`confENVDEF', `-D_PATH_VENDOR_CF=\"/src/tests/test.cf\"')
APPENDDEF(`confENVDEF', `-DUSE_VENDOR_CF_PATH')

Beginning with V8.12 sendmail, any changes to _PATH_VENDOR_CF will not be detected if you just recompile sendmail. Instead, you need to recompile the library in libsm first:

%cd libsm
%./Build -c -f yoursite.m4
...
%cd ../sendmail
%./Build -c -f yoursite.m4

There is no debugging flag that will display the defaults for these file locations. If any are of concern, you should build sendmail yourself.

Support for PH maps Tune with confMAPDEF

Prior to V8.10 sendmail, redirecting email with a ph server required running the phquery program. Beginning with V8.10 sendmail, a new database class called ph has been added that allows sendmail to perform direct ph queries. The use of ph maps is described in ph on page 930. To enable such maps, you can add a line such as the following to your Build m4 file:

APPENDDEF(`confMAPDEF', `-DPH_MAP')

If you are running a precompiled sendmail binary, you can use the -d0.10 debugging command-line switch (-d0.10 on page 543) to determine whether PH_MAP support is defined (if it appears in the list, it is defined).

Make sendmail picky about HELO Tune with confENVDEF

The SMTP HELO command is used to introduce the calling machine to the receiving machine. The form of that command is:

HELO calling hostname here

Note that HELO and EHLO are equivalent in this regard. Ordinarily, sendmail doesn’t care what the calling host calls itself. All sendmail cares about is that this name is the canonical name of a machine. If you care whether the HELO hostname matches the real hostname of the calling machine, you can add a line such as the following to your Build m4 file:

APPENDDEF(`confENVDEF', `-DPICKY_HELO_CHECK')

With PICKY_HELO_CHECK defined, a mismatch (other than the local machine calling itself localhost) will cause the following warning to be logged:

Host realname claimed to be heloname

Note that this check is ordinarily turned off because a large number of hosts on the Internet use a name that is different from their canonical name.^[54]

Enable PIPELINING SMTP extension Tune with confENVDEF

RFC2920 defines an SMTP extension called “pipelining.” With pipelining, SMTP commands and replies do not have to be synchronized. To illustrate, consider the following example of a normal (not pipelined) SMTP dialog, in which the server machine’s half of the dialog is shown in bold font and the client machine’s dialog is not:

220 your.host ESMTP Sendmail 8.14.1/8.14.1; Thu, 14 Dec 2007 08:12:44 −0700 (MST)
HELO some.domain.com
250 your.host.domain Hello some.domain.com [123.45.67.8], pleased to meet you
MAIL FROM: <friend@some.domain.com>
250 2.1.0 <friend@some.domain.com>... Sender ok
RCPT TO: <bcx@your.host>
250 2.1.5 <bcx@your.host>... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
                                                   ← message sent, end with a dot
.
250 2.0.0 g1GFCigc025138 Message accepted for delivery
QUIT
221 2.0.0 your.host closing connection

The important point to notice about this SMTP conversation is that it is synchronous. The client machine always waits for a reply from the server before sending its next command. For example, in the preceding dialog it waits for the 220 before sending the HELO command, and then waits for the 250 before sending the MAIL command.

Pipelining allows the commands of the client machine to be sent without waiting for the replies from the server machine.^[55] The same dialog as before, but with pipelining enabled, might look like the following (again the server is shown in bold font):

220 your.host ESMTP Sendmail 8.14.1/8.14.1; Thu, 14 Dec 2007 08:12:44 −0700 (MST)
EHLO some.domain.com
250-your.host.domain Hello some.domain.com [123.45.67.8], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING                            ← note this keyword
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-DELIVERBY
250 HELP
MAIL FROM: <friend@some.domain.com>
RCPT TO: <bcx@your.host>
DATA
250 2.1.0 <friend@some.domain.com>... Sender ok
250 2.1.5 <bcx@your.host>... Recipient ok
354 Enter mail, end with "." on a line by itself
               ← message sent, end with a dot
.
250 2.0.0 g1GFCigc025138 Message accepted for delivery
QUIT
221 2.0.0 your.host closing connection

In the preceding dialog, notice that the client issued the EHLO command instead of the HELO command, as in the first example. One result of issuing the EHLO command is that the server lists all the SMTP extensions it supports. Note that the list shows the PIPELINING keyword. When this keyword is listed in response to the EHLO command, the client is thereafter allowed to issue selected commands without waiting for a reply from the server.

In our second earlier example, the client issued the MAIL, RCPT, and DATA commands before waiting for a reply. Because pipelining requires DATA to wait, the client waits for replies after issuing that command. The three replies are also grouped together. The first 250 refers to the MAIL command. The second 250 refers to the RCPT command. And the final 354 reply refers to the DATA command.

When there are many recipients to a mail message, pipelining can increase the transmission rate of that message. It is otherwise a benign enhancement to SMTP. Pipelining is turned on by default. If for any reason you wish to turn off that extension, you can do so with a Build m4 file command such as this:

APPENDDEF(`conf_sendmail_ENVDEF', `-DPIPELINING=0')
                                                ↑
                                   to turn off pipelining

The srv_features rule set (srv_features on page 708) allows you to turn off PIPELINING on a selective basis using the access database.

If you are running a precompiled sendmail binary, you can use the -d0.10 debugging command-line switch (-d0.10 on page 543) to determine whether PIPELINING support is defined (if it appears in the list, it is defined).

Size of prescan( ) buffer Tune, edit sendmail/conf.h

Whenever an address^[56] is tokenized, it is stored in a single buffer, one token following the next with a zero-value byte separating them. The size of this buffer is defined by PSBUFSIZ. The default size is defined in sendmail/conf.h as (MAXNAME + MAXATOM).

In general, this definition should never be changed. If you start getting warning messages such as:

Address too long

look elsewhere (such as rule sets) for the cause. You should consider changing the size of PSBUFSIZ only as a last resort, and then do so with extreme care.

Enable queueing (prior to V8.12) Tune, edit sendmail/conf.h

If sendmail cannot immediately deliver a mail message, it places that message in a queue to await another try. Prior to V8.12, the QUEUE definition caused queue-handling code to be included in sendmail. As of V8.12, the QUEUE compile-time macro has been removed, and queue-handling code is always included in sendmail.

If queueing is not enabled and you need to queue, sendmail prints the following message and either bounces or discards the message:

dropenvelope: queueup

A word to the wise: always define QUEUE. Even if you have only a pure UUCP machine, mail can fail (for a reason such as a full disk). Without queueing, such mail will bounce when instead it should be queued for a later try.

The default is to always define QUEUE if NETINET or NETISO is defined; otherwise, QUEUE is undefined. There is no debugging flag to show whether QUEUE is defined, but the -bp switch (Printing the Queue on page 422) can be used to determine whether it is supported.

Amount to grow queue work list Tune, edit sendmail/conf.h

During a queue run, sendmail holds information in memory about all the files being processed. It does this so that it can sort them by priority for delivery. Beginning with V8.7 sendmail, there is no limit (other than consuming all memory, or setting the MaxQueueRunSize option, MaxQueueRunSize on page 1050) on how many queued messages can be processed during any queue run. Prior to V8.7, that number was fixed by the constant QUEUESIZE. QUEUESIZE has been retired and replaced with QUEUESEGSIZE, which is defined in sendmail/conf.h as:

# define QUEUESEGSIZE   1000            /* increment for queue size */

It should be changed only if your queue continually contains a huge number of messages. If you notice many messages such as this being logged:

grew WorkList for...

you might need to modify QUEUESEGSIZE. Doing so requires that you edit sendmail/conf.h and recompile.

QUEUESEGSIZE can be traced with the -d41 debugging switch (The Syntax of -d on page 530).

Support fsync( ) for directory updates Port

Some versions of Unix or implementations of disk I/O do not support immediate updates of directories when the data on them changes. The ReiserFS and Ext2fs filesystems are two such implementations. Linux is one such operating system. For these, this REQUIRES_DIR_FSYNC compile-time macro is set to true, which causes sendmail to fsync(2) the directory every time it is updated.

In the event you need to port sendmail to a new operating system or to a new filesystem, you might need to set this compile-time macro to true. The way you set it to true looks like this:

APPENDDEF(`confENVDEF', `-DREQUIRES_DIR_FSYNC')

New ports should be reported to sendmail@sendmail.org so that they can be folded into future releases.

Note that beginning with V8.13, sendmail allows the directory fsync(2) to be turned off at runtime (even if turned on using this macro). See the RequiresDirFsync option in RequiresDirFsync on page 1082.

Support SMTP AUTH RFC2554 (V8.10 and above) Tune with confENVDEF

As of V8.10 sendmail, support for SMTP AUTH can be included by defining this SASL compile-time macro. SMTP AUTH is defined in RFC2554. For V8.10 and above, sendmail provides that support using the SASL mechanism (see Support SMTP AUTH on page 183 for complete instructions).

To enable support for SMTP AUTH, define this SALS macro in your Build m4 file like this:

APPENDDEF(`confENVDEF', `-DSASL')

If you are running a precompiled sendmail binary, you can use the -d0.10 debugging command-line switch (-d0.10 on page 543) to determine whether SASL support is defined (if it appears in the list, it is defined).

Note that prior to V8.14, if sendmail was linked against a library that initialized Cyrus-SASL before sendmail initialized it (such as libnss-ldap), SMTP AUTH could fail. Beginning with V8.14 a workaround for this flaw has been included so that such a failure can no longer occur.

Support scanf(3) with the F command Tune with confENVDEF

The F configuration command (The F Class Command on page 857) allows the specification of a scanf(3)-style string to aid in parsing files (scanf(3) variations on page 858). This ability is enabled at compile time by default. If you don’t need it, you can exclude its support with the following line in your Build m4 file:

APPENDDEF(`confENVDEF', `-DSCANF=0')
                                 ↑
                           disable scanf(3)

The scanf(3) function is used only in reading files into a class with the F configuration command.

If you are running a precompiled sendmail binary, you can use the -d0.1 debugging command-line switch (-d0.1 on page 542) to determine whether SCANF support is included (if it appears in the list, support is included).

Support SecureWare C2 security package Port, edit sendmail/conf.h

Some implementations of Unix support a higher level of security called C2. In general, such sites are governmental or industrial where security is of high concern. SecureWare™ is a commercial add-on available for many architectures, most notably SCO Unix.

Now that SCO has split into two new companies, SecureWare is no longer available. This SECUREWARE compile-time macro has been retained, however, because those sites that have already installed it will use this macro.

If sendmail is built with this SECUREWARE compile-time macro defined, it will perform delivery under the identity of the luid of the recipient. In general, this SECUREWARE compile-time macro is correctly defined for those systems that are known to use it.

If you are running a precompiled version of sendmail, you can determine whether SECUREWARE was included by using the -d0.10 debugging switch (-d0.1 on page 542) (if it appears in the list, support was included).

How to determine free disk space Port, edit sendmail/conf.h

The sendmail program can temporarily fail incoming mail messages if they are too large for the queueing disk. This ability is enabled by giving a positive, nonzero size to the MinFreeBlocks option (Milter.macros.envrcpt on page 1055). The method sendmail uses to measure the free space on a disk varies from system to system. This SFS_TYPE compile-time macro defines which of several methods sendmail will use. Those available are shown in Table 3-11.

In general, SFS_TYPE is correctly defined for all supported systems. You should need to modify it only if you are porting to a new system. To do so, you will need to edit sendmail/conf.h (include/sm/conf.h beginning with V8.12).

You can use the -d4.80 debugging switch (-d4.80 on page 547) to watch sendmail check for enough disk space. The only way to tell whether a precompiled version of sendmail has this ability is by setting the MinFreeBlocks option to a positive value and watching the -d4.80 output. If bavail= in that output is always −1, no matter what, your support was defined as SFS_NONE.

New ports should be reported to sendmail@sendmail.org so that they can be folded into future releases.

Support for the fair share scheduler Port, edit sendmail/conf.h

On ConvexOS, version 1 of the fair share scheduler allows resource allocations to be fine-tuned for each user. If this SHARE_V1 compile-time macro is defined, sendmail will perform final delivery using the recipient’s resource limitations.

In general, this SHARE_V1 compile-time macro is correctly defined for systems that can use it, and is not defined for others. You should need to define it only when porting sendmail to a completely new architecture.

If you are running a precompiled sendmail binary, you can use the -d0.10 debugging switch (-d0.1 on page 542) to determine whether SHARE_V1 is defined (if it appears in the list, support is included). New ports should be reported to sendmail@sendmail.org so that they can be folded into future releases.

sendmail porting settings (V8.12 and above) Port with confENVDEF

Beginning with V8.12, the per-operating-system compile-time macros were removed from the sendmail/conf.h file, and were moved into the include/sm/conf.h file. In addition to moving them, they were also all prefixed with the characters SM_.

These compile-time macros are most certainly defined correctly for your operating system. In the rare event you are porting sendmail to a new operating system, you might need to tune these on a selective basis:

Memory-leak detection (V8.12 and above) Port with confENVDEF

The libsm library in the sendmail source distribution offers a way to provide memory leak detection and error checking that overlays the usual malloc(3), realloc(3), and free(3) C-language library routines. To disable extra checking, define SM_HEAP_CHECK as zero:

APPENDDEF(`confENVDEF', `-DSM_HEAP_CHECK=0')

If you choose to enable extra checking, it will not be turned on by default. Instead you will need to turn it on and off with special debugging command-line switches (we cover this soon). To enable extra checking, define SM_HEAP_CHECK as 1:

APPENDDEF(`confENVDEF', `-DSM_HEAP_CHECK=1')

Once extra checking has been included in your sendmail code, you can turn it on and off with debugging command-line switches. The category is sm_check_heap, and there are four meaningful levels:

# /usr/sbin/sendmail -dsm_check_heap.level ...

The four meaningful values for level are shown in Table 3-12.

The -dsm_check_heap command-line switch is most useful when porting sendmail to a new machine. It can also be valuable when adding new functions to sendmail or to its companion programs.

To see whether this compile-time macro is defined with your sendmail binary, use the -d0.12 debugging command-line switch.

Use shared memory (V8.12 and above) Port with confENVDEF

Beginning with V8.12, sendmail includes limited support for the use of shared memory. Shared memory is a region of memory maintained by the operating system so that an arbitrary number of programs can have common access to that memory.

The sendmail program forks a copy of itself every time it processes a queue. Because V8.9 and above sendmail support multiple queues, it is likely that a separate sendmail invocation will be processing each queue. Each queue processor knows the contents of each queue—specifically, the number of messages that are in its queue at any given time. A convenient place to store that information is in shared memory.

When you run V8.12 and above sendmail with the -bP command-line switch (Print the Number of Messages in the Queue on page 425), sendmail reads shared memory to gather a count of the number of messages in each queue.

Shared memory is turned on by default for some operating systems and off for others. If you run sendmail with the -bP command-line switch and get the following error, you might need to define this SM_CONF_SHM compile-time macro:

Data unavailable without shared memory support

If you need to enable shared memory, you can do so by placing a line such as the following in your Build m4 file:

APPENDDEF(`conf_sendmail_ENVDEF', `-DSM_CONF_SHM=1')
                                                 ↑
                                                                   to turn on shared
memory support

Note that just turning on SM_CONF_SHM is not enough. To actually use that shared memory you also need to set a value for the SharedMemoryKey option. To set this option in your configuration file, you could add a line such as the following to your mc configuration file:

define(`confSHARED_MEMORY_KEY',`13521')

Note that if you run multiple queue-processing daemons, each should be executed with a unique shared-memory key. One way to do that might look like the following two entries in an rc boot file:

/usr/bin/sendmail -q1h -OQueueDir=/var/spool/slowq -OSharedMemoryKey=11111
/usr/bin/sendmail -q5m -OQueueDir=/var/spool/fastq -OSharedMemoryKey=22222

To see whether this compile-time macro is defined with your sendmail binary, use the -d0.12 debugging command-line switch.

Enable ldap_initialize(3) (V8.13 and above) Tune with confENVDEF

When sendmail is built with LDAPMAP defined (LDAPMAP on page 119) LDAP database maps will be available for use. If the LDAP library contains an ldap_initialize(3) routine, and if this SM_CONF_LDAP_INITIALIZE macro is defined, ldap_initialize(3) will be called if your LDAP server supports direct use of URIs.

Note that LDAP URIs can still be used even if SM_CONF_LDAP_INITIALIZE is not set, but the scheme:// in (scheme://host:port/...) will be ignored. Therefore, if SM_CONF_LDAP_INITIALIZE is not available, the scheme ldap:// is always used, and the schemes ldaps:// and ldapi://, if used, may result in an error.

For most LDAP libraries, SM_CONF_LDAP_INITIALIZE will be set properly for you.^[57] But in the event it is improperly set, you may define it with the following and then rebuild sendmail:

APPENDDEF(`conf_libsm_ENVDEF', `-DSM_CONF_LDAP_INITIALIZE' )

Enable SMTP (prior to V8.12) Tune with confENVDEF

Prior to V8.12, if you were running sendmail as a daemon, you needed to define SMTP to enable mail transfers. If you didn’t intend to run sendmail as a daemon, SMTP did not need to be defined. The default was that SMTP was automatically defined if either NETINET or NETISO was defined; otherwise, SMTP was undefined.

Beginning with V8.12, the SMTP compile-time macro has been deprecated and removed. It is now impossible to exclude SMTP support from sendmail.

If a precompiled sendmail lacks SMTP support, an attempt to use sendmail’s -bs command-line switch will result in this fatal error:

I don't speak SMTP

SMTP activity can be watched with the -v command-line switch (-v on page 249).

Enable remote debugging Debug with confENVDEF

The sendmail program allows the developer to turn on debugging and to print the queue from any remote site. This capability is useful for solving occasional problems but opens a potentially wide security hole.

In general, SMTPDEBUG should always be undefined. Later, when you become more expert with sendmail, you might want to have a standby version of sendmail ready (one with SMTPDEBUG defined), just in case you need it.

There is no debugging switch that will let you know whether a precompiled version of sendmail had this defined. Instead, you must run sendmail with -bs, then issue the SHOWQ SMTP command. If that command displays the mail queue, that precompiled sendmail was built with SMTPDEBUG defined, and so you should not use it!

Default for obsolete F=L flag Don’t change

Each delivery agent that is defined in the configuration file may or may not have an L= (line length) equate (L= on page 745). If that equate is missing, or if the value assigned to it is less than or equal to zero, and if the F=L delivery agent flag (F=L on page 775) is set, the default value that is used becomes the value of SMTPLINELIM. Otherwise, the default value is 0. This logic is there to support old configuration files that use F=L in place of the newer L=.

The default for SMTPLINELIM is 990 (defined in RFC821), and that value should not be changed. Rather, if you need a different line-length limit for a particular delivery agent, you should use the L= equate when defining it.

Enable use of socket database-map type (V8.13 and above) Tune with confMAPDEF

The SOCKETMAP compile-time macro enables use of the new socket database-map type (Alphabetized Database-Map Types). You define SOCKETMAP inside your Build m4 file with a line like this:

APPENDDEF(`confMAPDEF', `-DSOCKETMAP')

If you use a vendor-supplied sendmail program, you may check to see whether it includes SOCKETMAP support by running a command like the following:

% /usr/sbin/sendmail -bt -d0.4 < /dev/null | grep SOCKETMAP

If a line of text containing SOCKETMAP is printed in response, you indeed have support for SOCKETMAP. If not, you will either need to contact your vender or download and build open source sendmail.

Adapt/exclude process title support Port, edit sendmail/conf.h

Whenever a program first begins to run, Unix provides it with two arrays of information: its command-line arguments, and the environment under which it was run. When you run ps(1) to see what processes are doing, ps prints the command line that was used to run each program.

To provide more useful information (such as current status or host connected to), sendmail saves its command line and environment, then periodically uses that system space to display its status. This ability provides a valuable tool for monitoring what each invocation of sendmail is doing.

The method to display this information is correctly defined in sendmail/conf.c (include/sm/conf.h with V8.12 and above) for all supported systems. In the rare event that you need to port sendmail to another system, you can do so by defining SPT_TYPE in sendmail/conf.h. The values that can be assigned to this SPT_TYPE are listed in Table 3-13.

If you set SPT_TYPE to SPT_REUSEARGV, you will also have to define SPT_PADCHAR, the character used to pad the process title. If the SPT_PADCHAR compile-time macro is undefined, the space character is used to pad.

New ports should be reported to sendmail@sendmail.org so that they can be folded into future releases.

Enable stream encryption (V8.11 and above) Tune with confENVDEF

This STARTTLS compile-time macro was first introduced with V8.11 sendmail. STARTTLS, and the subject of stream encryption that it is used for, are covered completely in STARTTLS on page 202. Also see the TLS_NO_RSA macro (TLS_NO_RSA on page 148).

Allow root delivery to files Debug with confENVDEF

When delivering to files, sendmail runs as the controlling user unless the suid or sgid bits of the file are set. If they are set, sendmail runs as the owner of the file. A question arises when such files are root-owned. Ordinarily, writing to suid and sgid root-owned files as root is disallowed.

If, for some reason, your site needs to allow delivery to suid and sgid root-owned files with sendmail running as root, you can enable this behavior by adding a line such as the following to your Build m4 file:

APPENDDEF(`confENVDEF', `-DSUID_ROOT_FILES_OK')

But be aware that you might open serious security holes on your system if you do this. We recommend that SUID_ROOT_FILES_OK never be defined, except as a temporary debugging technique.

If you define this compile-time macro, you will need to rebuild both libsm and sendmail for it to have an effect.

If you are running a precompiled sendmail binary, you can use the -d0.1 debugging command-line switch (-d0.1 on page 542) to determine whether SUID_ROOT_FILES_OK support is included (if it appears in the list, support is included).

Limit syslog(3) buffer size Port, edit sendmail/conf.h

The sendmail program logs errors, information, and debugging messages using the syslog(3) facility. By default, sendmail uses a 1,024-byte buffer to assemble each message before dispatching it, but some systems don’t accept a buffer this big. For such systems, you can reduce the size of that buffer by defining SYSLOG_BUFSIZE with a new size:^[58]

APPENDDEF(`confENVDEF', `-DSYSLOG_BUFSIZE=512')
                                          ↑
                                                                  reduce syslog(3)'s
buffer size

First, note that SYSLOG_BUFSIZE is correctly set in sendmail/conf.h (include/sm/conf.h beginning with V8.12) and for all the supported versions of Unix. Second, note that setting the buffer to fewer than 256 bytes causes sendmail to log many more smaller messages (each item of information on a separate syslog(3) line). If SYSLOG_BUFSIZE is less than 89, some logging information will be lost.

SYSLOG_BUFSIZE has an effect only if sendmail was compiled with LOG defined (LOG on page 120). If you are running a precompiled version of sendmail, there is no way to determine the setting of SYSLOG_BUFSIZE.

New ports should be reported to sendmail@sendmail.org so that they can be folded into future releases.

Support SysV-derived machines Port, edit sendmail/conf.h

If you are compiling sendmail on a SysVR4-derived machine, you should define SYSTEM5. This automatically causes the correct SysV support to be included. For all systems that require SYSTEM5 to be defined, it is already correctly defined in sendmail/conf.h (include/sm/conf.h beginning with V8.12).

If you suspect that you need to define SYSTEM5 when porting to a new system, you should also investigate SYS5SIGNALS and SYS5SETPGRP in sendmail/conf.h (include/sm/conf.h beginning with V8.12) and sendmail/README. If you are running a precompiled version of sendmail, you can use the -d0.10 debugging command-line switch (-d0.10 on page 543) to discover whether SYSTEM5 or SYS5SETPGRP is defined (if either appears in the list, it is defined).

Use libwrap.a for connects (V8.8 and above) Tune with confENVDEF

Beginning with V8.8 sendmail, it is possible to use the libwrap.a library to validate incoming SMTP connections.

Turn off RSA for STARTTLS (V8.12 and above) Tune with confENVDEF

Beginning with V8.12 sendmail, if you do not want to use the RSA algorithms with STARTTLS (STARTTLS on page 202), you can turn off those algorithms by specifying this TLS_NO_RSA compile-time macro:

APPENDDEF(`conf_sendmail_ENVDEF', `-DTLS_NO_RSA=1')

One good reason to do this would be if using RSA encryption is illegal in your country.

If you are running a precompiled sendmail binary, you can use the -d0.1 debugging command-line switch (-d0.1 on page 542) to determine whether TLS_NO_RSA support is included (if it appears in the list, support is included).

Set buffer for recipient list Tune, edit sendmail/conf.h

TOBUFSIZE limits the total number of recipients that can be delivered at once. It sets the size of the buffer that will hold the list of recipients, where that default size varies based on your operating system. If you need to increase that limit, you can experiment by cautiously increasing TOBUFSIZE.

To change the size of TOBUFSIZE, edit sendmail/conf.h and rebuild sendmail. There is no debugging switch that will show the size of TOBUFSIZE.

Set $y to tty name (obsolete) Debug with confENVDEF

The $y defined macro ($y on page 852) is intended to hold as its value the base name of the controlling tty device (if there is one). On BSD-derived systems, this is a name such as the following, but with the /dev/ prefix removed:

/dev/tty04

Defining TTYNAME enables sendmail to put this information into $y:

APPENDDEF(`confENVDEF', `-DTTYNAME')

Note that TTYNAME is useful only for debugging sendmail. The sendmail program does not itself use $y for anything. Also note that defining TTYNAME requires that your system support the ttyname(2) system call. If you are running a precompiled version of sendmail, you can determine whether TTYNAME was defined by sending mail with the -d35.9 debugging switch (-d35.9 on page 563) and watching for $y to be defined. You can tell because this line will be printed:

define(y as ttyp1)

The types returned by functions Port, edit sendmail/conf.h

Not all versions of C libraries declare values returned by functions in exactly the same way in all cases. For sendmail to work properly, it needs to know how certain subroutines are declared on certain systems. A few compile-time macros convey this information to sendmail, and they are listed and described in Table 3-14.

None of these compile-time macros will need to be defined by you unless you get warnings about mismatched types when compiling.

New ports should be reported to sendmail@sendmail.org so that they can be folded into future releases.

Default User Database location Tune with confMAPDEF

If you wish to define a default location for the User Database that will take effect if the UserDatabaseSpec option (UserDatabaseSpec on page 1116) is missing, you can define it, for example, like this:

APPENDDEF(`confMAPDEF', `-DNEWDB -DUDB_DEFAULT_SPEC=\"/var/db/userdb.db\"')

The backslashed quotation marks are necessary to pass the path to sendmail as a string.

Fork twice, prevent zombies (V8.12 and above) Port with confENVDEF

When sendmail forks a copy of itself to process a queue, it does so twice to prevent the creation of a zombie process. A zombie process is one that has lost its parent, and has not yet died. It continues to exist as though alive, yet it cannot be killed, hence it is a zombie.

This USE_DOUBLE_FORK compile-time macro is defined by default as 1 to enable the double fork to prevent zombies. In the rare instance that you are porting to a new system, you can redefine USE_DOUBLE_FORK like this:

APPENDDEF(`conf_sendmail_ENVDEF', `-DUSE_DOUBLE_FORK=0')

If you are running a precompiled sendmail binary, you can use the -d0.10 debugging command-line switch (-d0.10 on page 543) to determine whether USE_DOUBLE_FORK is defined (if it appears in the list, it is defined). New ports should be reported to sendmail@sendmail.org so that they can be folded into future releases.

Use the environ variable (V8.12 and above) Port with confENVDEF

Most versions of Unix compilers provide environment variables to programs in the third argument to main( ). Others provide environment variables in an external pointer variable called environ. If yours uses this latter approach, you can take advantage of it by defining this USE_ENVIRON compile-time macro:

APPENDDEF(`confENVDEF', `-DUSE_ENVIRON=1')      ← available with V8.12 and above

See The Environment on page 156 for a discussion of sendmail and the environment.

If you are running a precompiled sendmail binary, you can use the -d0.10 debugging command-line switch (-d0.10 on page 543) to determine whether USE_ENVIRON support is defined (if it appears in the list, it is defined).

Use Netscape’s ldap libraries (V8.10 and above) Tune with confENVDEF

This compile-time macro has been decprecated as of V8.12, in favor of using the SM_CONF_LDAP_MEMFREE compile-time macro (SM_... on page 139).

The Netscape LDAP libraries require that the return value from the ldap_first_attribute( ) function and the return value from the ldap_next_attribute( ) function be freed after use by calling the ldap_memfree( ) function. Normally, this is not done, because sendmail expects the open source version of LDAP. To enable this behavior for use with Netscape’s LDAP libraries, define this USING_NETSCAPE_LDAP compile-time macro:

APPENDDEF(`confENVDEF', `-DUSING_NETSCAPE_LDAP=1')

Also note that some LDAP libraries are derived from the Netscape version. These derivative libraries also need you to define this compile-time macro.

Note that this compile-time macro does not enable LDAP all by itself. Instead, you must also define the LDAPMAP compile-time macro (LDAPMAP on page 119) like this:

APPENDDEF(`confMAPDEF', `-DLDAPMAP')

If you are running a precompiled sendmail binary, you can use the -d0.10 debugging command-line switch (-d0.10 on page 543) to determine whether USING_NETSCAPE_LDAP support is defined (if it appears in the list, it is defined).

Support the User Database Tune with confMAPDEF

The User Database (userdb on page 942) is code inside sendmail that allows sender and recipient addresses to be rewritten under the control of an external database. This code is automatically included in sendmail when you define NEWDB or HESIOD:

APPENDDEF(`confMAPDEF', `-DNEWDB')   ← automatically include User Database code
APPENDDEF(`confMAPDEF', `-DHESIOD')  ← automatically include User Database code

If you don’t want to include support for the User Database, you need to specifically turn it off by setting USERDB to 0:

APPENDDEF(`confMAPDEF', `-DUSERDB=0')

See the UDB_DEFAULT_SPEC compile-time macro (UDB_DEFAULT_SPEC on page 149) for a method to set a default for the database location.

If you are running a precompiled sendmail binary, you can use the -d0.1 debugging command-line switch (-d0.1 on page 542) to determine whether USERDB support is included (if it appears in the list, support is included).

Support seteuid(2) identity changes Port, edit sendmail/conf.h

To perform most kinds of delivery in a safe manner, sendmail must be able to change its root identity to that of another user, deliver as that user, and then restore its identity to root. The preferred method for doing this is with the V1 POSIX seteuid(2) routine. To determine whether your system correctly supports this routine, compile and run the program test/t_seteuid.c. The compiled binary must be suid-root and must be executed by an ordinary user:

# cc t_seteuid.c
# chmod u+s a.out
# suspend
% ./a.out
... lots of output here
This system cannot use seteuid

Here the output shows failure, so you do not have seteuid(2) support. Beginning with V8.8, a.out prints the following on success:

It is safe to define USESETEUID on this system

If the output had not shown failure or had shown success (if you had usable seteuid(2) support), you could take advantage of that support by defining USESETEUID in sendmail/conf.h (or include/sm/conf.h for V8.12 and above). In general, USESETEUID is correctly defined for all systems that can take advantage of this seteuid support.

If seteuid(2) failed, you need to investigate using setreuid(2) instead:

# cc t_setreuid.c
# chmod u+s a.out
# suspend
% ./a.out
initial uids (should be 678/0): r/euid=678/0
after setreuid(0, 1) (should be 0/1): r/euid=0/1
after setreuid(-1, 0) (should be 0/0): r/euid=0/0
after setreuid(realuid, 0) (should be 678/0): r/euid=678/0

after setreuid(0, 2) (should be 0/2): r/euid=0/2
after setreuid(-1, 0) (should be 0/0): r/euid=0/0
after setreuid(realuid, 0) (should be 678/0): r/euid=678/0

It is safe to define HASSETREUID on this system

Here, the test succeeded (no failure message was printed prior to V8.8). If your system can use setreuid(2), you can take advantage of it by defining HASSETREUID in sendmail/conf.h (or include/sm/conf.h for V8.12 and above).

No matter which you define, be sure to read sendmail/README for possible pitfalls. Note that HASSETREUID and USESETEUID are correctly defined for all currently supported systems. You need to define one only if you are porting sendmail to a completely new system.

If you are running a precompiled sendmail binary, you can use the -d0.1 debugging command-line switch (-d0.1 on page 542) to discover whether HASSETREUID or USESETEUID support is included (if either appears in the list, support is included). New ports should be reported to sendmail@sendmail.org so that they can be folded into future releases.

Redefine wildcard shell Debug, edit sendmail/conf.c

Ordinarily, sendmail prohibits a user from running programs from inside a ~/.forward file unless that user also has a valid login shell. This restriction is in place to prevent the typical user from running any arbitrary program on a main mail server. Some sites prefer to allow users to run arbitrary programs despite the restriction about logging into the mail server. At such sites, one can bypass this restriction by placing the following special string in the /etc/shells file:

/SENDMAIL/ANY/SHELL/

If, for some reason, you need to use a different string, you can do so by redefining WILDCARD_SHELL in sendmail/conf.c.

If you enable arbitrary programs, you should also implement the sendmail restricted shell smrsh. (See The smrsh Program on page 379 for a full description of smrsh.)

Support sanity checks Debug with confENVDEF

In past releases of sendmail, changes in file descriptors and other key variables have sometimes occurred for reasons that remain a mystery to this day. Small “sanity checks” have been included in the code to discover such anomalies, should they happen again. To exclude these checks, redefine XDEBUG to 0:

APPENDDEF(`confENVDEF', `-DXDEBUG=0')

Generally, however, XDEBUG should always remain enabled. It adds only a microscopic amount of overhead to sendmail and helps to certify sendmail’s rational behavior.

If sendmail’s notion of who it is (as defined by the $j defined macro, $j on page 830) gets trashed by losing all its dots, sendmail will log the following at LOG_ALERT if XDEBUG is defined, dump its state (SIGUSR1 on page 510), and abort(3):

daemon process $j lost dot; see syslog

At startup, the value in the $j defined macro ($j on page 830) is added to the class w ($=w on page 876). If sendmail is compiled with XDEBUG, it periodically checks to make sure that $j is still listed in class w. If $j should vanish, sendmail will log the following at LOG_ALERT, dump its state (SIGUSR1 on page 510), and abort(3):

daemon process doesn't have $j in $=w; see syslog

With XDEBUG defined, sendmail periodically checks to see whether its standard I/O file descriptors have gotten clobbered. If so, it logs the following and tries to recover by connecting it to /dev/null:

where: fd which not open

Here, where will reflect the internal subroutine name and arguments that led to the check, and which will be the bad file descriptor number.

If you are running a precompiled sendmail binary, you can use the -d0.1 debugging command-line switch (-d0.1 on page 542) to determine whether XDEBUG support is included (if it appears in the list, support is included).