Ordinarily, sendmail will first look for a service-switch (see Section 34.8.61) to see how it should look up its aliases. If it finds one, and if the service aliases is listed, it uses the techniques listed with the service-switch 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:

DBMDEF= -DNIS -DAUTO_NIS_ALIASES
DBMDEF= -DNISPLUS -DAUTO_NIS_ALIASES

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

On Ultrix, and possibly other systems, the res_search(2) routine incorrectly sets h_errno to 0 instead of HOST_NOT_FOUND if a host name is unknown. On such systems you can define BROKEN_RES_SEARCH in your Makefile, which tells sendmail to consider 0 the same as HOST_NOT_FOUND:

ENVDEF= -DBROKEN_RES_SEARCH

As distributed, this is not declared for any of the supplied Makefile files. If you are running Ultrix you should test your resolver library. If it fails, you should upgrade to the latest resolver library. If, for some reason, upgrading is not possible, you may define this as a workaround. When porting to a new system, you can test with the above ENVDEF= statement and, if successful, put a permanent porting entry into 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, BSD4_3 is already correctly defined in src/Makefiles or in conf.h. You should need to define BSD4_3 only if you are porting to a previously unsupported old BSD-based system:

ENVDEF= -DBSD4_3

When porting to a new system, you can test with the above ENVDEF= statement and, if successful, put a permanent porting entry into conf.h.

BSD4_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.

Delivery Status Notification (DSN) replaces certain SMTP error codes and the Return-Receipt-To: header (Section 35.10.29, Return-Receipt-To:) 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 may turn it off like this:

ENVDEF=  -DDSN=0
               
      turn off DSN support

MIME is described under the EightBitMode (8) option (see Section 34.8.22, EightBitMode (8)).

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

ENVDEF= -DERRLIST_PREDEFINED

When porting to a new system, you can test with the above ENVDEF= statement and, if successful, put a permanent porting entry into conf.h.

Most releases of sendmail contain, within the C language code, sections that are commented out. These are initial stabs at solutions that either did not work as is, are incomplete or untested, or are dreams for the future.

If you have a good reason and thoroughly understand the code and why it is excluded (and if you are brave), you may include it by adding an appropriate _FFR_ (For Future Release) definition to ENVDEF= in Makefile:

ENVDEF= -D_FFR_what

Here, what describes the appropriate future item that you want to include (as found in the source). We categorize this as a debugging technique (not a porting or tuning one) because you may want to include future code for testing, but should probably not include it in your production version.

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). [12] 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.

[12] Bugs in the interaction between NIS and vfork(2) at the system level with Solaris and systems that lacked vfork(2) altogether, such as IRIX, caused V8.8 to favor fork(2). This is really okay because in modern systems, fork(2) is just as fast as vfork(2).

ENVDEF= -DFORK=vfork

You can test with the above ENVDEF= statement and, if successful, put a permanent porting entry into conf.h.

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

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

ENVDEF=  -DHASSETSID=1       turn on
ENVDEF=  -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 above ENVDEF= statements and, if successful, put a permanent porting entry into conf.h.

These have probably been correctly defined for your system already. Therefore you should need to change them only when porting sendmail to a completely new system.

Table 18.4: HAS... #defines for Specific System Call Support

#define	System Call
HASFCHMOD	fchmod(2)
HASFLOCK	flock(2)
HASGETDTABLESIZE	getdtablesize(2)
HASGETUSERSHELL	getusershell(3)
HASINITGROUPS	initgroups(3)
HASLSTAT	lstat(2)
HASSETREUID	setreuid(2)
HASSETRLIMIT	setrlimit(2)
HASSETSID	setsid(2)
HASSETUSERCONTEXT	setusercontext(3)
HASSETVBUF	setvbuf(3)
HASSIGSETMASK	sigsetmask(2)
HASSNPRINTF	snprintf(3) and vsnprintf(3)
HASULIMIT	ulimit(2)
HASUNAME	uname(2)
HASUNSETENV	unsetenv(3)
HASWAITPID	waitpid(2)

If you are running a precompiled binary of sendmail, you can determine whether any of these were defined when sendmail was compiled by using the -d0.10 debugging switch (see Section 37.5.3, -d0.10).

Named after the 8th century B.C.E. [13] 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 Domain Naming System and uses modified BIND source:

[13] Before Christian Era, although an alternative proposal that is making the rounds calls for signed years, thus the -8th century.

DBMDEF= -DHESIOD

If HESIOD is defined when sendmail is built, support is included to look up aliases and user information via the hesiod interface. Support is also included to declare and use hesiod class maps (see Section 33.3.2, "The class") with the K configuration command. Support is also included for the User Database if USERDB is also defined.

Hesiod documentation and source are available from:

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

If you are running a precompiled sendmail binary, you may use the -d0.1 switch (see Section 37.5.1) to determine whether HESIOD support is included.

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

ENVDEF= -DHES_GETMAILHOST

HES_GETMAILHOST is by default not defined. If you need it, you must define it in your Makefile. If you are running a precompiled version of sendmail, you may use the -d0.1 debugging switch (see Section 37.5.1) to determine whether HES_GETMAILHOST has been included. The -d28.8 (see Section 37.5.100, -d28.8) debugging flag can be used to trace the behavior of the hes_getmailhost(3) routine.

Defining out IDENTPROTO neither includes nor excludes RFC1413 code. All it does is change the default value for the Timeout.ident option (see Section 34.8.70.10):

ENVDEF= -DIDENTPROTO=0           set Timeout.ident=0 by default
ENVDEF= -DIDENTPROTO=1           set Timeout.ident=30 by default

If you are running a precompiled sendmail binary, you may use the -d0.10 switch (see Section 37.5.3) to determine whether IDENTPROTO was defined as nonzero.

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 sendmail attempts to extract source-routing information from the initial connection's IP information. If any is found, sendmail adds that information to the $_ macro (see Section 31.10.1, $-) for use in the Received: header (see Section 35.10.25, Received:). The $_ macro is usually used like this:

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

where $_ will contain information like that shown below when IP source-routing information is found:

       IP source-routing information
                   
[email protected] [!@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 the DontPruneRoutes option, Section 34.8.20, DontPruneRoutes (R)). 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 Makefile. It is predefined correctly for all supported systems in conf.h, so you should need to redefine it only if you are porting sendmail to a completely new system. Be sure to read src/READ_ME for the latest information about IP_SRCROUTE.

If you are running a precompiled sendmail binary, you may use the -d0.10 switch (see Section 37.5.3) to determine whether IP_SRCROUTE support was included.

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 34.9 (see Section 34.6.4, "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 conf.h for all currently supported operating systems. Porting sendmail to a new system may require that you define LA_TYPE yourself. The possible values and their meanings are shown in Table 18.5.

Table 18.5: LA_ Methods for Getting the Load Average

LA_	Does What
LA_ZERO	Always returns 0. Essentially disables load average checking. This is portable to all systems.
LA_INT	Read /dev/kmem for the symbol avenrun. If found, interpret the result as a native (usually long) integer.
LA_FLOAT	Read /dev/kmem for the symbol avenrun. If found, interpret the result as a floating-point value.
LA_SHORT	Read /dev/kmem for the symbol avenrun. If found, interpret the result as a short integer.
LA_SUBR	Call the library routine getloadavg(3) and use the result returned.
LA_MACH	Call the MACH-specific processor_set_info(2) routine and use the result returned.
LA_PROCSTR	Read the Linux-specific /proc/loadavg file and interpret the result as a floating-point value.
LA_READKSYM	Use the (some SysV versions) ioctl of MIOC_READKSYM to read /dev/kmem.
LA_DGUX	DG/UX specific support for using the pstat_getdynamic(2)function to read the load average.

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

Table 18.6: Tuning for LA_INT, LA_SHORT, LA_FLOAT, and LA_READKSYM

#define	Tunes
FSHIFT	Number of bits to shift right when using LA_INT, LA_SHORT, and LA_READKSYM. Default is 8.
_PATH_UNIX	The pathname of your kernel. This is required for LA_INT and LA_SHORT. Default is /unix for SysV; /hp_ux for HP/UX V9; /stand/unix for HP/UX V10, News, and UXP/OS; /dev/ksyms for Solaris; /dynix for DYNIX; otherwise /vmunix.
_PATH_KMEM	The pathname of your kernel memory. This is required for LA_INT, LA_SHORT, LA_FLOAT, and LA_READKSYM. Default is /dev/kmem.
LA_AVENRUN	The name of the kernel variable that holds the load average. Used by LA_INT, LA_SHORT, and LA_FLOAT. Default is averun for SysV, otherwise _averun.
NAMELISTMASK	The mask to bitwise-AND against the return value of nlist(3). If this is undefined, the return value is used as is. A common value is 0x7fffffff to strip off the high bit.

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 is available from

ftp://terminator.rs.itd.umich.edu/ldap/

It is used by defining a map class called ldapx (see Section 33.8.9, ldapx) in your configuration file. Its use is enabled by defining LDAPMAP at compile time:

DBMDEF=LDAPMAP

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 26, Logging and Statistics. Defining LOG should be considered mandatory, and it should be turned off only if you have a well-thought-out reason for doing so. LOG cannot be turned off in the Makefile. Instead, you must edit conf.h directly and undefine it by commenting it out:

/* # define LOG                 /* enable logging - don't turn off */

comment out to remove support

LOG 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 (L) option (see Section 34.8.33, LogLevel (L)) is also nonzero. Fortunately, this is usually the case because the default is 9.

See also SYSLOG_BUFSIZE for a way to tune syslog(3)'s buffer size if necessary.

If you are running a precompiled sendmail binary, you may use the -d0.1 switch to determine whether LOG support was included (see Section 37.5.1).

The Lotus Notes mail-gateway SMTP software can produce sender header lines that contain newlines when the username part becomes too long:

From: Long Full Name/LongSite/Country
  <[email protected]>

Although perfectly legal under RFC822, such split sender headers can cause MUAs to fail in ways that are difficult to diagnose. If your site receives mail from Lotus Notes gateways, you should define LOTUS_NOTES_HACK when compiling sendmail:

ENVDEF= -DLOTUS_NOTES_HACK

Defining LOTUS_NOTES_HACK causes sendmail to include code in support of the SingleLineFromHeader option (see Section 34.8.63, SingleLineFromHeader). Setting that option to true causes the newlines in the above address to be stripped and produces a single line:

From: Long Full Name/LongSite/Country <[email protected]>

If you are running a precompiled sendmail binary, you can define SingleLineFromHeader in your configuration file. If you don't get a warning about a bad option name, then you have this support. Note that under V8.8 sendmail, LOTUS_NOTES_HACK is no longer required for SingleLineFromHeader support.

Defining MATCHGECOS causes code to be included inside sendmail for support of limited fuzzy name matching. This process is described under the MatchGECOS (G) option (see Section 34.8.34, MatchGECOS (G)). MATCHGECOS is normally defined by default. If you want to turn it off, use ENVDEF= in Makefile:

ENVDEF= -DMATCHGECOS=0

If you are running a vendor-supplied binary, you can check to see whether MATCHGECOS was defined by using the -d0.1 debugging switch (see Section 37.5.1).

In porting sendmail to a new system or tuning sendmail for special needs, it may be necessary to adjust one of its defined maximums. These cannot be tuned in Makefile. Instead, each needs to be changed in the file indicated by the third column of Table 18.7. In general, maximums should never be lowered without first examining the code for possible side effects; also, review the code to see whether any minimums are required or whether there are warnings about maximums.

Table 18.7: MAX... #defines to Redefine Maximums

#define	Default	File	Maximum
MAXALIASDB	12	conf.h	Number of alias databases
MAXATOM	200	conf.h	Atoms (tokens) in an address
MAXDNSRCH	6	domain.c	Possible domains to search
MAXHOSTNAMELEN	256	conf.h	Length of a hostname
MAXKEY	128	conf.h	Length of a database key
MAXLINE	2048	conf.h	Length of an input line
MAXMAILERS	25	conf.h	Number of delivery agents
MAXMAPSTACK	12	conf.h	Size of sequenced map stack
MAXMIMEARGS	20	conf.h	Arguments per Content-Type: header
MAXMXHOSTS	100	conf.h	Number of per host MX records
MAXMIMENESTING	20	conf.h	Multipart MIME nesting depth
MAXNAME	256	conf.h	Length of a name
MAXPRIORITIES	25	conf.h	Number of Priority lines
MAXPV	40	conf.h	Arguments to a delivery agent
MAXRULERECURSION	50	conf.c	Ruleset recursion
MAXRWSETS	200	conf.h	Number of rule sets
MAXTOCLASS	8	conf.h	Message timeout classes
MAXUSERENVIRON	100	conf.h	Environment items per delivery agent

Also see QUEUESEGSIZE and SYSLOG_BUFSIZE for the discussion of two other definitions that affect sizes.

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

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.

The default value assigned to MEMCHUNKSIZE is 1024 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 conf.h:

# define MEMCHUNKSIZE   1024            /* chunk size for memory allocation */
                        
                     change this

V8.8 sendmail contains the internal ability to convert messages that were converted into either quoted-printable or base64 (see Section 34.8.22) back into their original eight-bit form. The decision of whether or not to do this conversion is based on the F=9 delivery agent flag (see Section 30.8.6, F=9).

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, use ENVDEF= in Makefile to define it as 0:

ENVDEF= -DMIME7TO8=0
                   
        exclude support

Unless you have a compelling reason to do otherwise, we recommend that MIME7TO8 remain enabled.

If you are running a precompiled sendmail binary, you may use the -d0.1 switch to determine whether MIME7TO8 support (see Section 37.5.1) was included.

V8 sendmail contains the internal ability to convert 8-bit MIME message contents into 7-bit MIME so that mail can be transported to non-8-bit gateways. The methods used and the circumstances required to trigger conversion are described under the EightBitMode (8) option (see Section 34.8.22). The conversion itself can be watched with the -d43 debugging switch (see Section 37.5.150, -d43.1).

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, use ENVDEF= in Makefile to define it as 0:

ENVDEF= -DMIME8TO7=0
                   
        exclude support

One side effect of excluding MIME8TO7 support is that defining it to 0 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 may use the -d0.1 switch to determine whether MIME8TO7 support (see Section 37.5.1) was included.

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:

ENVDEF= -DNAMED_BIND=0
                     
             disable DNS lookups

If you are not currently running named(8) but plan to connect to the Internet, you should define NAMED_BIND but set the ResolverOptions (I) (see Section 34.8.55, ResolverOptions (I)) to false in the configuration file. Later, when you connect to the Internet, you can then simply change it to true. (See also the service-switch file, Section 34.8.61, for an another way to achieve the same effect.)

If you are running a precompiled sendmail binary, you may use the -d0.1 switch to determine whether NAMED_BIND support was included (see Section 37.5.1).

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 below) in your Makefile.

DBMDEF= -DNDBM

The ndbm(3) routines are used primarily to look up aliases. They can also be used to declare dbm class maps (see Section 33.3.2) with the K configuration command.

Library routines to support ndbm(3) are available with most modern versions of UNIX. You may have to specify library support with a -lndbm in the LIBS= line of your Makefile. If you are running a precompiled sendmail binary, you may use the -d0.1 switch to determine whether ndbm(3) support was included (see Section 37.5.1).

The sendmail program requires certain C language library routines to exist. If any is missing from your library, define one of the needs listed in Table 18.8 and sendmail will try to emulate it.

Each is defined with ENVDEF= in Makefile by setting it to a value of 1 (NEEDPUTENV is an exception in that 1 or 2 can be used).

ENVDEF= -DNEEDFSYNC=1

When porting to a new system, you can test with this ENVDEF= statement and, if successful, put a permanent porting entry into conf.h. 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.

Table 18.8: Define Replacements for Missing C Library Routines

#define	Emulates
NEEDFSYNC	Replaces a missing fsync(2). The sendmail program will try to simulate it by using fcntl(2), if available; otherwise, sendmail will not "sync" to disk. This latter circumstance is undesirable and may result in unreliable mail delivery, but it works.
NEEDGETOPT	The sendmail program calls getopt(3) twice when parsing its command-line arguments. Some version of getopt(3) do odd things when called twice. If yours is one of these, replace it.
NEEDPUTENV	Replace a missing putenv(3). If this is defined as 1, sendmail emulates by using setenv(3). If this is defined as 2, sendmail emulates by directly modifying the environmental section of memory.
NEEDSTRSTR	Replace a missing strstr(3) with a well-written internalversion.
NEEDSTRTOL	Replace a missing strtol(3) with a well-written internalversion.
NEEDVPRINTF	Replace a missing vprintf(3). Note that the emulation supplied is not very elegant. It may not even work on some systems. See conf.h for a glimpse of systems that require this.

If you are running a precompiled sendmail binary, there is no way to discover whether any of these were defined when it was built.

V8 sendmail is designed to support four kinds of networks, as listed in Table 18.9. Currently, only NETINET and NETISO are supported.

Table 18.9: Define for Network Support

Define	Description
NETINET	A TCP/IP-based network
NETISO	An ISO 8022 network
NETNS	A Xerox NS protocol network (tentative)
NETX25	A CCITT\*[=a] X.25 network (tentative)

International Telephone and Telegraph Consultative Committee.

Stubs are included in the source code for any programmer who is interested in implementing NETNS or NETX25. NETINET is defined by default. If you don't want it, you need to turn it off in your Makefile:

ENVDEF= -DNETINET=0

NETISO is undefined by default. If you want to include ISO support, you need to specifically define it in your Makefile:

ENVDEF= -DNETISO=1

Defining NETINET or NETISO has the side effect of causing SMTP and QUEUE also to be automatically defined.

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 (O) option (see Section 34.8.13, DaemonPortOptions (O)). In the absence of an option declaration, inet (for NETINET) is used as the default.

If you are running a precompiled version of sendmail, you can determine which network types are supported by using the -d0.1 debugging switch (see Section 37.5.1).

The netinfo(3) form of database is supplied with the NeXT and NeXTSTeP 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 Makefile:

DBMDEF= -DNETINFO

The netinfo(3) databases can also be used to declare netinfo class maps (see Section 33.3.2) with the K configuration command. If you are running a precompiled sendmail binary, you may use the -d0.1 switch to determine whether NETINFO support was included (see Section 37.5.1).

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 above) in your Makefile. The db(3) routines are used to look up aliases and are the routines used by the User Database (see Section 33.5, "The User Database"). They can also be used to declare hash and btree class maps (see Section 33.3.2) 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. The db(3) source is available from

ftp://ftp.cs.berkeley.edu/ucb/4bsd/db.tar.Z

Do not use the Net2 distribution. (See OLD_NEWDB below if you already have that distribution and can't easily get rid of it.) The src/READ_ME file contains critical information [14] about installing db(3).

[14] Such as why you must remove ndbm.h and ndbm.o from libdb.a before installing it for use by sendmail.

If you are running a precompiled sendmail binary, you may use the -d0.1 switch (see Section 37.5.1) to determine whether db(3) support was included in it.

If you intend to have sendmail support nis (formerly Yellow Pages) maps, you need to define NIS as part of your DBMDEF= line in Makefile:

DBMDEF= -DNIS

If NIS is defined, the AliasFile (A) 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 Section 34.8.1, AliasFile (A) for more details about the AliasFile (A) option. See Section 34.8.61 for a description of the ServiceSwitchFile option and its effect on nis aliases. Be aware that the above AliasFile (A) 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:

DBMDEF= -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 like this:

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

Here, $(YPDBDIR)/ is usually /var/yp/, so the substring is found. When "/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 successfully be distributed for use by nis clients. Without these entries you will see an error like that shown below 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 class maps (see Section 33.3.2) 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 may use the -d0.1 switch to determine whether NIS support was included (see Section 37.5.1).

If you intend to have sendmail support nisplus maps, you need to define NISPLUS as part of your DBMDEF= line in Makefile. (The use of nisplus aliases and other maps is determined by the /etc/nsswitch.conf file.)

DBMDEF= -DNISPLUS

If NISPLUS is defined, the AliasFile (A) 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 Section 34.8.1 for details about the AliasFile (A) option. Note that NISPLUS is new to V8.7 and not supported under earlier versions of sendmail.

With NISPLUS defined, support is also included to declare and use nisplus class maps (see Section 33.3.2) with the K configuration command.

If you are running a precompiled sendmail binary, you may use the -d0.1 switch to determine whether NISPLUS support was included (see Section 37.5.1).

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; on systems that allow users to belong to many groups at once, failure causes sendmail to check any other groups to which the controlling user may 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 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 (see Section 34.8.19, DontInitGroups) for a means to exclude the getgrgid(3) and initgroups(3) system calls.

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 MS-DOS) 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 macro in your Makefile:

ENVDEF= -DNOTUNIX

When porting to a new system, you can test with this ENVDEF= statement and, if successful, put a permanent porting entry into conf.h. Defining NOTUNIX causes the code for eatfrom() to be excluded from sendmail. The -d30.2 debugging switch (see Section 37.5.109, -d30.2) can be used to watch eatfrom() and to determine whether NOTUNIX was declared when compiling sendmail.

BSDI(BSD/386) 1.0, NetBSD 0.9, and FreeBSD 1.0 were distributed with an old version of the db(3) library. These systems will not use the file locking of the latest version. For such systems you must define

DBMDEF= -DNEWDB -DOLD_NEWDB=1
                            
                don't support new file locking

Although you can get and install the latest version of db(3), you should not do so unless you can rebuild your entire UNIX system. The old form of database is used throughout, and just building sendmail with the new form will cause password lookups and the like to fail.

In general, you should never have to declare OLD_NEWDB (instead, we recommend upgrading your operating system). OLD_NEWDB is automatically included in the Makefile for the systems that need it.

Only a few pathnames are hard-coded 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 hard-coded. Here, we describe those that you can change. Note that the general form for all such changes uses the ENVDEF= declaration of your Makefile:

ENVDEF= -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. /etc/sendmail.cf The sendmail.cf file is pivotal to all of the sendmail program's operations (see Chapter 27, The Configuration File). V8.7 sendmail recommends that it always be called sendmail.cf and always be located in the /etc directory. For testing, debugging, or other legitimate reasons you may prefer to locate that file elsewhere (at least temporarily). You do that with the _PATH_SENDMAILCF definition:

ENVDEF= -D_PATH_SENDMAILCF=\"/src/tests/test.cf\"

/etc/sendmail.pid The sendmail.pid file contains two lines of information. The first line is text representation of the pid of the current running daemon. The second is a copy of the command line that was originally used to start sendmail. This file is handy for killing and restarting the daemon (see Section 4.1.1, "Daemon Mode (-bd)"). If BSD4_4 is defined, the default becomes /var/run/sendmail.pid; otherwise, the default is /etc/sendmail.pid. You can change this default (and you must if you intend to run a test daemon in parallel to the original), with the ENVDEF= of your Makefile:

ENVDEF= -D_PATH_SENDMAILPID=\"/src/tests/test.pid\"

Ordinarily, two daemons cannot run simultaneously on a single host. If you need to run a second daemon, you must change the port that it listens to with the Port parameter of the DaemonPortOptions (O) option (see Section 34.8.13). /etc/hosts Ordinarily, sendmail will first look for a service-switch (see Section 34.8.61) to see how it should look up the canonical names of hosts. If it finds one and if the service hosts is listed, it uses the techniques listed with the service-switch to look up its hosts. When a technique is files, sendmail reads the file named by _PATH_HOSTS to get its canonical information. Ordinarily, that file is called /etc/hosts. If that file is different or has been customized on your system, you can redefine the location like this:

ENVDEF= -D_PATH_HOSTS=\"/etc/privatehosts\"

In general, most other techniques are preferred over the linear parse of a hosts file. However, this file is useful in determining the canonical name of the local host. Note that the location of the hosts file can also be changed with the HostsFile option (see Section 34.8.30, HostsFile). /dev/kmem The sendmail program decides when to refuse connections and when to only queue mail on the basis of its perception of the machine load average. The process of determining that average is hugely complex and varies greatly from vendor to vendor. Three pathnames that may be used in determining the load are _PATH_KMEM, _PATH_LOADAVG, and _PATH_UNIX. These should need to be changed only in the rare event that you are porting sendmail to a previously unsupported platform. Read the file conf.c to see the complex way they are presently used. Also see Table 18.6 to see how to use these to find the load average. /etc/shells A user is not allowed to run programs from a .forward file unless that user has a valid login shell (see Section 25.7.4, "Piping Through Programs"). Nor is a user allowed to save mail directly to files without a valid shell. To determine whether the login shell is valid, sendmail calls getusershell(3). If sendmail was defined without HASGETUSERSHELL defined (see Table 18.4), it instead tries to look up the shell in the /etc/shells file. If that file cannot be opened, sendmail gets valid shell names from an internal list called DefaultUserShells that is defined in conf.c. This _PATH_SHELLS definition can be used to change the location of the /etc/shells file. /usr/tmp In a panic situation (such as when sendmail cannot figure out how to deliver or bounce a mail message) the message is saved into the /usr/tmp/dead.letter file (see the ErrorMode (e) option Section 34.8.24, ErrorMode (e)). The _PATH_VARTMP definition is used to tune the location of the /usr/tmp directory. For some systems it is defined as /usr/tmp; for others it will need to be named /var/tmp. As distributed, it is undefined in all Makefiles, and it defaults to /usr/tmp.

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

The sendmail program can be made pickier by tuning its PrivacyOptions (p) option (see Section 34.8.47, PrivacyOptions (p)) or by defining two macros when compiling: PICKY_HELO_CHECK The SMTP HELO command is used to introduce the calling machine to the receiving machine. The form of that command is

HELO calling host name 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 define PICKY_HELO_CHECK.

ENVDEF= -DPICKY_HELO_CHECK

With PICKY_HELO_CHECK defined, a mismatch (other than the local machine calling itself localhost) will result in this being logged:

Host realname claimed to be heloname

Note that this check is ordinarily turned off [15] because a large number of hosts on the Internet use a name that is different from their canonical name. PICKY_QF_NAME_CHECK The name of a queue file's control file is narrowly defined inside sendmail (see Section 23.2.1, "The Queue Identifier"). If only sendmail will be placing files into your queue, you might wish to turn on this macro for additional protection:

[15] Eric was getting complaints that the continual insertion of this warning was misleading and tended to cause people to ignore it entirely.

ENVDEF= -DPICKY_QF_NAME_CHECK

With PICKY_QF_NAME_CHECK defined, sendmail will log an error if the name of the qf file is incorrectly formed and will rename the qf file into a Qf file (see Section 23.3 for details of this process).

Whenever an address (including rules) 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 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.

If sendmail cannot immediately deliver a mail message, it places that message in a queue to await another try. The QUEUE definition causes queue-handling code to be 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 are defined; otherwise, QUEUE is undefined. There is no debugging flag to show whether QUEUE is defined, but the the -bp switch (see Section 23.4, "Printing the Queue") can be used to determine whether it is supported.

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 longer a limit (other than consuming all memory) 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 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 like this being logged:

grew WorkList for...

you may need to modify QUEUESEGSIZE. Doing so requires that you edit conf.h and recompile.

QUEUESEGSIZE can be traced with the -d41 debugging switch (see Section 37.5.144, -d41.1).

The F configuration command (see Section 32.1.2, "The F Class Command") allows the specification of a scanf(3) style string to aid in parsing files (see Section 32.1.2.1, "scanf(3) variations"). In general this is not recommended because a misdesigned input file can cause sendmail to core dump. However, because of its popularity, it is enabled at compile time by default. If you don't need it, we recommend you exclude its support with ENVDEF= in Makefile.

ENVDEF= -DSCANF=0
                
        disable scanf(3)

The scanf(3) is used only in reading files into a class with the F configuration command. If you are running a precompiled version of sendmail, you can determine whether SCANF was included by using the -d0.1 debugging switch (see Section 37.5.1).

The sendmail program can reject 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 (b) option (see Section 34.8.40, MinFreeBlocks (b)). The method that sendmail uses to measure the free space on a disk varies from system to system. SFS_TYPE defines which of several methods sendmail will use. Those available are shown in Table 18.10.

Table 18.10: Method to Determine Free Disk Space

Define	Description
SFS_NONE	Your system has no way to determine the free space on a disk. This causes the MinFreeBlocks (b) option (see Section 34.8.40)to be ignored.
SFS_USTAT	Your system uses the ustat(2) system call to get information about mounted file systems.
SFS_4ARGS	Your system uses the four-argument form of the statfs(2) system call and <sys/statfs.h>. If you define this, you can also define SFS_BAVAIL as the field name for the statfs C language structure (by default, f_bavail).
SFS_VFS	Your system uses the two-argument form of the statfs(2) system call and <sys/vfs.h>.
SFS_MOUNT	Your system uses the two-argument form of the statfs(2) system call and <sys/mount.h>.
SFS_STATFS	Your system uses the two-argument form of the statfs(2) system call and <sys/statfs.h>.
SFS_STATVFS	Your system uses the statvfs(2) system call.

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 conf.h.

You can use the -d4.80 debugging switch (see Section 37.5.19, -d4.80) 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.

If you are running sendmail as a daemon, you need to define SMTP to enable mail transfers. If you don't intend to run sendmail as a daemon, SMTP might not need to be defined. The default is that SMTP is automatically defined if either NETINET or NETISO is defined; otherwise, SMTP is undefined.

SMTP support is recommended, even if sendmail is not running with network support or as a daemon. To take advantage of the new DSN protocol, future MUAs will talk to sendmail using SMTP over a pipe connection with the -bs command-line switch (see Section 36.7.11, -bs). The mh(1) suite of programs does that now. Delivery agents are also being designed with SMTP so that they can take advantage of DSN.

You enable SMTP support with ENVDEF= in your Makefile:

ENVDEF= -DSMTP=1

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 -d18 and -d19 debugging switches (see Section 37.5.65, -d19.1) and with the -v command-line switch (see Section 36.7.41, -v).

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 it as a daemon, connect to it with telnet(1), and issue the SHOWQ SMTP command. If it displays the mail queue, then that precompiled sendmail was built with SMTPDEBUG defined, and you should not use it!

Each delivery agent that is defined in the configuration file may or may not have an L= (Line length) equate (see Section 30.4.6, L=). 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 is set (see Section 30.8.29, F=L), 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.

If compiling for a Sun Solaris machine, you will find this SOLARIS definition correctly defined for you in your Makefile:

ENVDEF=    -DSOLARIS              Solaris 2.1 and 2.2
ENVDEF=    -DSOLARIS=20300        Solaris 2.3
ENVDEF=    -DSOLARIS=20400        Solaris 2.4
ENVDEF=    -DSOLARIS=20500        Solaris 2.5
ENVDEF=    -DSOLARIS=20501        Solaris 2.5.1

Be sure to see src/READ_ME for several well-known pitfalls concerning Solaris.

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 conf.c for all supported systems. In the rare event that you need to port sendmail to another system, you may do so by defining SPT_TYPE in conf.h.

When delivering to files, sendmail runs as the controlling user unless the suid or sgid bits of the file are set. If so, it 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 root-owned files with sendmail running as root, you can enable this behavior with

ENVDEF= -DSUID_ROOT_FILES_OK

But be aware that you may 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 are running a precompiled sendmail binary, you can use the -d0.1 debugging switch (see Section 37.5.1) to determine whether SUID_ROOT_FILES_OK was defined in it.

The sendmail program logs errors, information, and debugging messages using the syslog(3) facility. By default, sendmail uses a 1024-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:

ENVDEF= -DSYSLOG_BUFSIZE=512
                         
         reduce syslog(3)'s buffer size

First, note that SYSLOG_BUFSIZE is correctly set in conf.h and Makefiles/* for all supported systems. 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, (see Section 18.8.16), and if the LogLevel (L) option (see Section 34.8.33) is set to 6 or more, and if your syslog.conf(5) file is configured to log mail messages at LOG_INFO and above (see Section 26.1, "Logging with syslog"). If you are running a precompiled version of sendmail, there is no way to determine the setting of SYSLOG_BUFSIZE.

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 conf.h.

If you suspect that you need to define SYSTEM5 when porting to a new system, you should also investigate SYS5SIGNALS and SYS5SETPGRP in conf.h and READ_ME. If you are running a precompiled version of sendmail, you can use the -d0.10 debugging switch (see Section 37.5.3) to discover whether SYSTEM5 or SYS5SETPGRP were defined.

Beginning with V8.8 sendmail, it is now possible to use the libwrap.a library to validate incoming SMTP connections. To enable this ability, you need to define TCPWRAPPERS and arrange for the libwrap.a library to be included in your Makefile:

ENVDEF= -DTCPWRAPPERS
LIBS= -lwrap

See src/README and Section 22.4.1, "Accept/Reject Connections via libwrap.a" for additional information.

For each delivery of one or more recipients to a single delivery agent, sendmail issues a summary of delivery through syslog(3). When logged, the recipient part of the message looks like this:

to=recipients

Here, recipients is a comma-separated list of recipients. The maximum number of characters in this list is determined by TOBUFSIZE. That limit is intended to prevent the internal syslog(3) buffer from overflowing. On machines with older versions of syslog(3) you may need to reduce the size of TOBUFSIZE in conf.h. In general, TOBUFSIZE is correctly defined for all currently supported systems. You should need to change it only if porting to a new system.

Note that one side effect of TOBUFSIZE is that it also limits the total number of recipients that can be delivered at once. If you need to increase that limit (and if you have a robust version of syslog), you can experiment by cautiously increasing TOBUFSIZE.

The sendmail program uses the uname(2) system call to determine the UUCP name of the local host. If your machine lacks the uname(2) call (if HASUNAME was not defined), sendmail attempts to emulate uname(2) with its own internal routine. That internal routine first tries to read the /etc/whoami file. If that fails, it then tries to parse /usr/include/whoami.h. Finally, if that fails and if TRUST_POPEN is defined, sendmail executes the following command to get the UUCP name:

popen("uuname -l", "r")

The result (no matter how it was obtained) is then placed into the $k macro (see Section 31.10.21, $k).

In general, you should never define TRUST_POPEN. The popen(3) call presents a huge security risk. If your system lacks uname(2) and is unable to set its UUCP name, consider hard-coding that name in the configuration file:

Dkuucpname

You may wish to define TRUST_POPEN temporarily to see whether that causes your UUCP name to be found. Once that is done, undefine it for your final release of sendmail.

There is no debugging switch that will tell you whether TRUST_POPEN was defined in a precompiled version of sendmail. If that binary is not stripped, you can use nm(1) to check for popen(3) support:

% nm sendmail | grep popen
00058bc8 T _popen                       found, so TRUST_POPEN was defined

If sendmail is stripped, you can still run strings(1) in order to check for the actual command:

% strings sendmail | grep "uname -l"
uuname -l                               found, so TRUST_POPEN was defined

In either event you should contact your vendor and ask for this security risk to be removed.

The $y macro (see Section 31.10.44, $y) 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 like the following, but with the /dev/ prefix removed:

/dev/tty04

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

ENVDEF= -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 (see Section 37.5.120, -d35.9) and watching for $y to be defined:

define(y as ttyp1)

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

DBMDEF= -DNEWDB -DUDB_DEFAULT_SPEC=\"/var/db/userdb.db\"

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

The User Database (see Section 33.5) 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:

DBMDEF= -DNEWDB           automatically include User Database code
DBMDEF= -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:

DBMDEF= -DNEWDB -DUSERDB=0
DBMDEF= -DHESIOD -DUSERDB=0

See UDB_DEFAULT_SPEC for a method to set a default for the database location. If you are running a precompiled sendmail binary, you may use the -d0.1 switch (see Section 37.5.1) to determine whether USERDB support is included.

.SS "seteuid routine" 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 Posix 1 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 conf.h. 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 conf.h.

No matter which you define, be sure to read src/READ_ME 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 switch (see Section 37.5.1) to discover whether HASSETREUID or USESETEUID support is included.

Ordinarily, sendmail prohibits ordinary users from running programs from inside their ~./forward files unless they have a valid login shell. This restriction is in place to prevent ordinary users from running arbitrary programs 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 special string

/SENDMAIL/ANY/SHELL/

in the /etc/shells file. If, for some reason, you need to use a different string, you may do so by redefining WILDCARD_SHELL in conf.c.

If you enable arbitrary programs you should also implement the sendmail restricted shell smrsh (see Section 22.8.2, "The smrsh Program").

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:

ENVDEF= -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 macro; see Section 31.10.20, $j) gets trashed by losing all its dots, sendmail will log the following at LOG_ALERT if XDEBUG is defined, dump its state (see Section 26.3.3, "SIGUSR1 Dump States"), and abort(3):

daemon process $j lost dot; see syslog

At startup the value in the $j macro (see Section 31.10.20) is appended to the class w (see Section 32.5.8, $=w). 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 (see Section 26.3.3), 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 switch (see Section 37.5.1) to determine whether XDEBUG support is included.