Some implementations of Unix recognize that system information can be
found in a variety of places. On Solaris 8, for example, hostnames
can be obtained from the /etc/hosts file, from
nis, from nisplus, or from
DNS. Solaris allows the system administrator to choose the order in
which these services are searched with a
"service-switch" file. Other
systems, such as Ultrix and DEC OSF/1, have a similar concept, but
some (such as SunOS 4) use built-in rules that cannot be changed
without the source code.
Beginning with V8.7, sendmail uses a
system-service switch on Solaris, DEC OSF/1, and Ultrix. Otherwise, sendmail
uses the service switch defined by this
The form for redefining the switched-services file is as follows:
O ServiceSwitchFile=path configuration file (V8.7 and later)
-OServiceSwitchFile=path command line (V8.7 and later)
define(`confSERVICE_SWITCH_FILE',path) mc configuration (V8.7 and later)
If this option is defined on Solaris, DEC OSF/1, or Ultrix, it is
ignored. Otherwise, path is used as the
full pathname of the file that is to be used as the service switch.
If path is omitted, the default is NULL.
If the entire option is omitted, the default is
/etc/mail/service.switch. The default for the
mc technique is to omit this option.
The service-switch file must live in a safe directory and must itself
have safe permissions, or sendmail will refuse
to use the information in it. If your site unavoidably must make the
service-switch file unsafe, you might be able to overcome that
problem with the DontBlameSendmail option (DontBlameSendmail).
The form of each line in the file defined by
service how how
Here, service is either
hosts (which states how hostnames are looked up),
aliases (which states how aliases are looked up),
or passwd (which states how
passwd(5) information is looked up). For each
service, there might be one or more how
methods (not all of which make sense with all services). The
service and the
hows must be separated from each other by
whitespace. The possible methods (values for each
how) are files (the
information is in a file or database, such as
/etc/hosts), netinfo (for
information on NeXT machines), nis (the
information is in an nis map),
nisplus (the information is in an
nisplus map), dns (the host
information is looked up with DNS), or hesiod (the
information is listed with a Hesiod service).
For example, consider the contents of the following
passwd nis files
Here, sendmail will look up aliases in the
nis map mail.aliases.
Password information, such as local user login names and full name
information from the GECOS field, will first be looked up in the
nis map passwd.byname. If
not found there, they will then be looked up in the file
/etc/passwd. The last line tells
sendmail to look up A, AAAA, CNAME, PTR, and MX
records using the DNS services.
The hosts line can also determine how MX records
are treated (Section 9.2.5). If
"dns" does not appear in that line,
sendmail disables lookups of MX records. If
sendmail is configured to look up hosts with
nis first, then DNS, it will do the MX lookup in
DNS before the nis lookup.
For Solaris, hosts is looked up with the
nsswitch.conf(4) service. For DEC OSF/1 and
Ultrix, hosts is looked up with the
svc.conf(5) service. For all others the file
defined by the ServiceSwitchFile is examined for a
line that begins with the word hosts. If that line
is missing or if the file doesn't exist,
dns is returned by default. But if NAMED_BIND was
not defined (NAMED_BIND) when
sendmail was compiled, the default returned is
nis for Solaris and SunOS, and on other systems it
Note that on systems such as SunOS, a version of
gethostbyname(3) is still called that ignores
the sendmail program's
service-switch file. On such systems you might need to download the
source, recompile, and install a version that works correctly.
The ServiceSwitchFile option is not safe. If
specified from the command line, it can cause
sendmail to relinquish its special privileges.