2256 lines
88 KiB
Plaintext
2256 lines
88 KiB
Plaintext
|
|
|
|
NEW SENDMAIL CONFIGURATION FILES
|
|
|
|
Eric Allman <eric@Sendmail.ORG>
|
|
|
|
@(#)README 8.184 (Berkeley) 12/29/1998
|
|
|
|
|
|
This document describes the sendmail configuration files being used
|
|
at Berkeley. These use features in the new (R8) sendmail; they will
|
|
not work on other versions.
|
|
|
|
These configuration files are probably not as general as previous
|
|
versions, and don't handle as many of the weird cases automagically.
|
|
I was able to simplify them for two reasons. First, the network
|
|
has become more consistent -- for example, at this point, everyone
|
|
on the internet is supposed to be running a name server, so hacks to
|
|
handle NIC-registered hosts can go away. Second, I assumed that a
|
|
subdomain would be running SMTP internally -- UUCP is presumed to be
|
|
a long-haul protocol. I realize that this is not universal, but it
|
|
does describe the vast majority of sites with which I am familiar,
|
|
including those outside the US.
|
|
|
|
Of course, the downside of this is that if you do live in a weird
|
|
world, things are going to get weirder for you. I'm sorry about that,
|
|
but at the time we at Berkeley had a problem, and it seemed like the
|
|
right thing to do.
|
|
|
|
This package requires a post-V7 version of m4; if you are running the
|
|
4.2bsd, SysV.2, or 7th Edition version, I suggest finding a friend with
|
|
a newer version. You can m4-expand on their system, then run locally.
|
|
SunOS's /usr/5bin/m4 or BSD-Net/2's m4 both work. GNU m4 version 1.1
|
|
or later also works. Unfortunately, I'm told that the M4 on BSDI 1.0
|
|
doesn't work -- you'll have to use a Net/2 or GNU version. GNU m4 is
|
|
available from ftp://ftp.gnu.org/pub/gnu/m4-1.4.tar.gz (check for
|
|
the latest version). EXCEPTIONS: DEC's m4 on Digital UNIX 4.x is broken
|
|
(3.x is fine). Use GNU m4 on this platform.
|
|
|
|
IF YOU DON'T HAVE A BERKELEY MAKE, don't despair! Just run
|
|
"m4 ../m4/cf.m4 foo.mc > foo.cf" -- that should be all you need.
|
|
There is also a fairly crude (but functional) Makefile.dist that works
|
|
on the old version of make.
|
|
|
|
To get started, you may want to look at tcpproto.mc (for TCP-only
|
|
sites), uucpproto.mc (for UUCP-only sites), and clientproto.mc (for
|
|
clusters of clients using a single mail host). Others are versions
|
|
that we use at Berkeley, although not all are in current use. For
|
|
example, ucbvax has gone away, but I've left ucbvax.mc in because
|
|
it demonstrates some interesting techniques.
|
|
|
|
I'm not pretending that this README describes everything that these
|
|
configuration files can do; clever people can probably tweak them
|
|
to great effect. But it should get you started.
|
|
|
|
*******************************************************************
|
|
*** BE SURE YOU CUSTOMIZE THESE FILES! They have some ***
|
|
*** Berkeley-specific assumptions built in, such as the name ***
|
|
*** of our UUCP-relay. You'll want to create your own domain ***
|
|
*** description, and use that in place of ***
|
|
*** domain/Berkeley.EDU.m4. ***
|
|
*******************************************************************
|
|
|
|
|
|
+--------------------------+
|
|
| INTRODUCTION AND EXAMPLE |
|
|
+--------------------------+
|
|
|
|
Configuration files are contained in the subdirectory "cf", with a
|
|
suffix ".mc". They must be run through "m4" to produce a ".cf" file.
|
|
You must pre-load "cf.m4":
|
|
|
|
m4 ${CFDIR}/m4/cf.m4 config.mc > config.cf
|
|
|
|
where ${CFDIR} is the root of the cf directory and config.mc is the
|
|
name of your configuration file. If you are running a version of M4
|
|
that understands the __file__ builtin (versions of GNU m4 >= 0.75 do
|
|
this, but the versions distributed with 4.4BSD and derivatives do not)
|
|
or the -I flag (ditto), then ${CFDIR} can be in an arbitrary directory.
|
|
For "traditional" versions, ${CFDIR} ***MUST*** be "..", or you MUST
|
|
use -D_CF_DIR_=/path/to/cf/dir/ -- note the trailing slash! For example:
|
|
|
|
m4 -D_CF_DIR_=${CFDIR}/ ${CFDIR}/m4/cf.m4 config.mc > config.cf
|
|
|
|
Let's examine a typical .mc file:
|
|
|
|
divert(-1)
|
|
#
|
|
# Copyright (c) 1998 Sendmail, Inc. All rights reserved.
|
|
# Copyright (c) 1983 Eric P. Allman. All rights reserved.
|
|
# Copyright (c) 1988, 1993
|
|
# The Regents of the University of California. All rights reserved.
|
|
#
|
|
# By using this file, you agree to the terms and conditions set
|
|
# forth in the LICENSE file which can be found at the top level of
|
|
# the sendmail distribution.
|
|
#
|
|
|
|
#
|
|
# This is a Berkeley-specific configuration file for HP-UX 9.x.
|
|
# It applies only to the Computer Science Division at Berkeley,
|
|
# and should not be used elsewhere. It is provided on the sendmail
|
|
# distribution as a sample only. To create your own configuration
|
|
# file, create an appropriate domain file in ../domain, change the
|
|
# `DOMAIN' macro below to reference that file, and copy the result
|
|
# to a name of your own choosing.
|
|
#
|
|
divert(0)
|
|
|
|
The divert(-1) will delete the crud in the resulting output file.
|
|
The copyright notice can be replaced by whatever your lawyers require;
|
|
our lawyers require the one that I've included in my files. A copyleft
|
|
is a copyright by another name. The divert(0) restores regular output.
|
|
|
|
VERSIONID(`<SCCS or RCS version id>')
|
|
|
|
VERSIONID is a macro that stuffs the version information into the
|
|
resulting file. We use SCCS; you could use RCS, something else, or
|
|
omit it completely. This is not the same as the version id included
|
|
in SMTP greeting messages -- this is defined in m4/version.m4.
|
|
|
|
OSTYPE(hpux9)dnl
|
|
|
|
You must specify an OSTYPE to properly configure things such as the
|
|
pathname of the help and status files, the flags needed for the local
|
|
mailer, and other important things. If you omit it, you will get an
|
|
error when you try to build the configuration. Look at the ostype
|
|
directory for the list of known operating system types.
|
|
|
|
DOMAIN(CS.Berkeley.EDU)dnl
|
|
|
|
This example is specific to the Computer Science Division at Berkeley.
|
|
You can use "DOMAIN(generic)" to get a sufficiently bland definition
|
|
that may well work for you, or you can create a customized domain
|
|
definition appropriate for your environment.
|
|
|
|
MAILER(local)
|
|
MAILER(smtp)
|
|
|
|
These describe the mailers used at the default CS site site. The
|
|
local mailer is always included automatically. Beware: MAILER
|
|
declarations should always be at the end of the configuration file,
|
|
and MAILER(smtp) should always precede MAILER(uucp). The general
|
|
rules are that the order should be:
|
|
|
|
VERSIONID
|
|
OSTYPE
|
|
DOMAIN
|
|
FEATURE
|
|
local macro definitions
|
|
MAILER
|
|
LOCAL_RULESET_*
|
|
|
|
|
|
+----------------------------+
|
|
| A BRIEF INTRODUCTION TO M4 |
|
|
+----------------------------+
|
|
|
|
Sendmail uses the M4 macro processor to ``compile'' the configuration
|
|
files. The most important thing to know is that M4 is stream-based,
|
|
that is, it doesn't understand about lines. For this reason, in some
|
|
places you may see the word ``dnl'', which stands for ``delete
|
|
through newline''; essentially, it deletes all characters starting
|
|
at the ``dnl'' up to and including the next newline character. In
|
|
most cases sendmail uses this only to avoid lots of unnecessary
|
|
blank lines in the output.
|
|
|
|
Other important directives are define(A, B) which defines the macro
|
|
``A'' to have value ``B''. Macros are expanded as they are read, so
|
|
one normally quotes both values to prevent expansion. For example,
|
|
|
|
define(`SMART_HOST', `smart.foo.com')
|
|
|
|
One word of warning: M4 macros are expanded even in lines that appear
|
|
to be comments. For example, if you have
|
|
|
|
# See FEATURE(foo) above
|
|
|
|
it will not do what you expect, because the FEATURE(foo) will be
|
|
expanded. This also applies to
|
|
|
|
# And then define the $X macro to be the return address
|
|
|
|
because ``define'' is an M4 keyword. If you want to use them, surround
|
|
them with directed quotes, `like this'.
|
|
|
|
+----------------+
|
|
| FILE LOCATIONS |
|
|
+----------------+
|
|
|
|
sendmail 8.9 has introduced a new configuration directory for sendmail
|
|
related files, /etc/mail. The new files available for sendmail 8.9 --
|
|
the class 'R' /etc/mail/relay-domains and the access database
|
|
/etc/mail/access -- take advantage of this new directory. 8.9 will
|
|
serve as a transition release. Beginning with 8.10, all of the files
|
|
will use this directory by default.
|
|
|
|
+--------+
|
|
| OSTYPE |
|
|
+--------+
|
|
|
|
You MUST define an operating system environment, or the configuration
|
|
file build will puke. There are several environments available; look
|
|
at the "ostype" directory for the current list. This macro changes
|
|
things like the location of the alias file and queue directory. Some
|
|
of these files are identical to one another.
|
|
|
|
It is IMPERATIVE that the OSTYPE occur before any MAILER definitions.
|
|
In general, the OSTYPE macro should go immediately after any version
|
|
information, and MAILER definitions should always go last.
|
|
|
|
Operating system definitions are usually easy to write. They may define
|
|
the following variables (everything defaults, so an ostype file may be
|
|
empty). Unfortunately, the list of configuration-supported systems is
|
|
not as broad as the list of source-supported systems, since many of
|
|
the source contributors do not include corresponding ostype files.
|
|
|
|
ALIAS_FILE [/etc/aliases] The location of the text version
|
|
of the alias file(s). It can be a comma-separated
|
|
list of names (but be sure you quote values with
|
|
commas in them -- for example, use
|
|
define(`ALIAS_FILE', `a,b')
|
|
to get "a" and "b" both listed as alias files;
|
|
otherwise the define() primitive only sees "a").
|
|
HELP_FILE [/usr/lib/sendmail.hf] The name of the file
|
|
containing information printed in response to
|
|
the SMTP HELP command.
|
|
QUEUE_DIR [/var/spool/mqueue] The directory containing
|
|
queue files.
|
|
STATUS_FILE [/etc/sendmail.st] The file containing status
|
|
information.
|
|
LOCAL_MAILER_PATH [/bin/mail] The program used to deliver local mail.
|
|
LOCAL_MAILER_FLAGS [rmn9] The flags used by the local mailer. The
|
|
flags lsDFM are always included.
|
|
LOCAL_MAILER_ARGS [mail -d $u] The arguments passed to deliver local
|
|
mail.
|
|
LOCAL_MAILER_MAX [undefined] If defined, the maximum size of local
|
|
mail that you are willing to accept.
|
|
LOCAL_MAILER_CHARSET [undefined] If defined, messages containing 8-bit data
|
|
that ARRIVE from an address that resolves to the
|
|
local mailer and which are converted to MIME will be
|
|
labeled with this character set.
|
|
LOCAL_SHELL_PATH [/bin/sh] The shell used to deliver piped email.
|
|
LOCAL_SHELL_FLAGS [eu9] The flags used by the shell mailer. The
|
|
flags lsDFM are always included.
|
|
LOCAL_SHELL_ARGS [sh -c $u] The arguments passed to deliver "prog"
|
|
mail.
|
|
LOCAL_SHELL_DIR [$z:/] The directory search path in which the
|
|
shell should run.
|
|
USENET_MAILER_PATH [/usr/lib/news/inews] The name of the program
|
|
used to submit news.
|
|
USENET_MAILER_FLAGS [rlsDFMmn] The mailer flags for the usenet mailer.
|
|
USENET_MAILER_ARGS [-m -h -n] The command line arguments for the
|
|
usenet mailer.
|
|
USENET_MAILER_MAX [100000] The maximum size of messages that will
|
|
be accepted by the usenet mailer.
|
|
SMTP_MAILER_FLAGS [undefined] Flags added to SMTP mailer. Default
|
|
flags are `mDFMUX' for all SMTP-based mailers; the
|
|
"esmtp" mailer adds `a' and "smtp8" adds `8'.
|
|
SMTP_MAILER_MAX [undefined] The maximum size of messages that will
|
|
be transported using the smtp, smtp8, or esmtp
|
|
mailers.
|
|
SMTP_MAILER_ARGS [IPC $h] The arguments passed to the smtp mailer.
|
|
About the only reason you would want to change this
|
|
would be to change the default port.
|
|
ESMTP_MAILER_ARGS [IPC $h] The arguments passed to the esmtp mailer.
|
|
SMTP8_MAILER_ARGS [IPC $h] The arguments passed to the smtp8 mailer.
|
|
RELAY_MAILER_ARGS [IPC $h] The arguments passed to the relay mailer.
|
|
SMTP_MAILER_CHARSET [undefined] If defined, messages containing 8-bit data
|
|
that ARRIVE from an address that resolves to one of
|
|
the SMTP mailers and which are converted to MIME will
|
|
be labeled with this character set.
|
|
UUCP_MAILER_PATH [/usr/bin/uux] The program used to send UUCP mail.
|
|
UUCP_MAILER_FLAGS [undefined] Flags added to UUCP mailer. Default
|
|
flags are `DFMhuU' (and `m' for uucp-new mailer,
|
|
minus `U' for uucp-dom mailer).
|
|
UUCP_MAILER_ARGS [uux - -r -z -a$g -gC $h!rmail ($u)] The arguments
|
|
passed to the UUCP mailer.
|
|
UUCP_MAILER_MAX [100000] The maximum size message accepted for
|
|
transmission by the UUCP mailers.
|
|
UUCP_MAILER_CHARSET [undefined] If defined, messages containing 8-bit data
|
|
that ARRIVE from an address that resolves to one of
|
|
the UUCP mailers and which are converted to MIME will
|
|
be labeled with this character set.
|
|
FAX_MAILER_PATH [/usr/local/lib/fax/mailfax] The program used to
|
|
submit FAX messages.
|
|
FAX_MAILER_ARGS [mailfax $u $h $f] The arguments passed to the FAX
|
|
mailer.
|
|
FAX_MAILER_MAX [100000] The maximum size message accepted for
|
|
transmission by FAX.
|
|
POP_MAILER_PATH [/usr/lib/mh/spop] The pathname of the POP mailer.
|
|
POP_MAILER_FLAGS [Penu] Flags added to POP mailer. Flags "lsDFM"
|
|
are always added.
|
|
POP_MAILER_ARGS [pop $u] The arguments passed to the POP mailer.
|
|
PROCMAIL_MAILER_PATH [/usr/local/bin/procmail] The path to the procmail
|
|
program. This is also used by FEATURE(local_procmail).
|
|
PROCMAIL_MAILER_FLAGS [SPhnu9] Flags added to Procmail mailer. Flags
|
|
``DFM'' are always set. This is NOT used by
|
|
FEATURE(local_procmail); tweak LOCAL_MAILER_FLAGS
|
|
instead.
|
|
PROCMAIL_MAILER_ARGS [procmail -Y -m $h $f $u] The arguments passed to
|
|
the Procmail mailer. This is NOT used by
|
|
FEATURE(local_procmail); tweak LOCAL_MAILER_ARGS
|
|
instead.
|
|
PROCMAIL_MAILER_MAX [undefined] If set, the maximum size message that
|
|
will be accepted by the procmail mailer.
|
|
MAIL11_MAILER_PATH [/usr/etc/mail11] The path to the mail11 mailer.
|
|
MAIL11_MAILER_FLAGS [nsFx] Flags for the mail11 mailer.
|
|
MAIL11_MAILER_ARGS [mail11 $g $x $h $u] Arguments passed to the mail11
|
|
mailer.
|
|
PH_MAILER_PATH [/usr/local/etc/phquery] The path to the phquery
|
|
program.
|
|
PH_MAILER_FLAGS [ehmu] Flags for the phquery mailer.
|
|
PH_MAILER_ARGS [phquery -- $u] -- arguments to the phquery mailer.
|
|
CYRUS_MAILER_FLAGS [A5@/:|] The flags used by the cyrus mailer. The
|
|
flags lsDFMnPq are always included.
|
|
CYRUS_MAILER_PATH [/usr/cyrus/bin/deliver] The program used to deliver
|
|
cyrus mail.
|
|
CYRUS_MAILER_ARGS [deliver -e -m $h -- $u] The arguments passed
|
|
to deliver cyrus mail.
|
|
CYRUS_MAILER_MAX [undefined] If set, the maximum size message that
|
|
will be accepted by the cyrus mailer.
|
|
CYRUS_MAILER_USER [cyrus:mail] The user and group to become when
|
|
running the cyrus mailer.
|
|
CYRUS_BB_MAILER_FLAGS [undefined] The flags used by the cyrusbb
|
|
mailer. The flags lsDFMnP are always included.
|
|
CYRUS_BB_MAILER_ARGS [deliver -e -m $u] The arguments passed
|
|
to deliver cyrusbb mail.
|
|
confEBINDIR [/usr/libexec] The directory for executables.
|
|
Currently used for FEATURE(local_lmtp) and
|
|
FEATURE(smrsh).
|
|
|
|
|
|
|
|
+---------+
|
|
| DOMAINS |
|
|
+---------+
|
|
|
|
You will probably want to collect domain-dependent defines into one
|
|
file, referenced by the DOMAIN macro. For example, our Berkeley
|
|
domain file includes definitions for several internal distinguished
|
|
hosts:
|
|
|
|
UUCP_RELAY The host that will accept UUCP-addressed email.
|
|
If not defined, all UUCP sites must be directly
|
|
connected.
|
|
BITNET_RELAY The host that will accept BITNET-addressed email.
|
|
If not defined, the .BITNET pseudo-domain won't work.
|
|
DECNET_RELAY The host that will accept DECNET-addressed email.
|
|
If not defined, the .DECNET pseudo-domain and addresses
|
|
of the form node::user will not work.
|
|
FAX_RELAY The host that will accept mail to the .FAX pseudo-domain.
|
|
The "fax" mailer overrides this value.
|
|
LOCAL_RELAY DEPRECATED. The site that will handle unqualified
|
|
names -- that is, names with out an @domain extension.
|
|
If not set, they are assumed to belong on this machine.
|
|
This allows you to have a central site to store a
|
|
company- or department-wide alias database. This
|
|
only works at small sites, and only with some user
|
|
agents.
|
|
LUSER_RELAY The site that will handle lusers -- that is, apparently
|
|
local names that aren't local accounts or aliases.
|
|
|
|
Any of these can be either ``mailer:hostname'' (in which case the
|
|
mailer is the internal mailer name, such as ``uucp-new'' and the hostname
|
|
is the name of the host as appropriate for that mailer) or just a
|
|
``hostname'', in which case a default mailer type (usually ``relay'',
|
|
a variant on SMTP) is used. WARNING: if you have a wildcard MX
|
|
record matching your domain, you probably want to define these to
|
|
have a trailing dot so that you won't get the mail diverted back
|
|
to yourself.
|
|
|
|
The domain file can also be used to define a domain name, if needed
|
|
(using "DD<domain>") and set certain site-wide features. If all hosts
|
|
at your site masquerade behind one email name, you could also use
|
|
MASQUERADE_AS here.
|
|
|
|
You do not have to define a domain -- in particular, if you are a
|
|
single machine sitting off somewhere, it is probably more work than
|
|
it's worth. This is just a mechanism for combining "domain dependent
|
|
knowledge" into one place.
|
|
|
|
+---------+
|
|
| MAILERS |
|
|
+---------+
|
|
|
|
There are fewer mailers supported in this version than the previous
|
|
version, owing mostly to a simpler world. As a general rule, put the
|
|
MAILER definitions last in your .mc file, and always put MAILER(smtp)
|
|
before MAILER(uucp) -- several features and definitions will modify
|
|
the definition of mailers, and the smtp mailer modifies the UUCP
|
|
mailer.
|
|
|
|
local The local and prog mailers. You will almost always
|
|
need these; the only exception is if you relay ALL
|
|
your mail to another site. This mailer is included
|
|
automatically.
|
|
|
|
smtp The Simple Mail Transport Protocol mailer. This does
|
|
not hide hosts behind a gateway or another other
|
|
such hack; it assumes a world where everyone is
|
|
running the name server. This file actually defines
|
|
four mailers: "smtp" for regular (old-style) SMTP to
|
|
other servers, "esmtp" for extended SMTP to other
|
|
servers, "smtp8" to do SMTP to other servers without
|
|
converting 8-bit data to MIME (essentially, this is
|
|
your statement that you know the other end is 8-bit
|
|
clean even if it doesn't say so), and "relay" for
|
|
transmission to our RELAY_HOST, LUSER_RELAY, or
|
|
MAILER_HUB.
|
|
|
|
uucp The Unix-to-Unix Copy Program mailer. Actually, this
|
|
defines two mailers, "uucp-old" (a.k.a. "uucp") and
|
|
"uucp-new" (a.k.a. "suucp"). The latter is for when you
|
|
know that the UUCP mailer at the other end can handle
|
|
multiple recipients in one transfer. If the smtp mailer
|
|
is also included in your configuration, two other mailers
|
|
("uucp-dom" and "uucp-uudom") are also defined [warning:
|
|
you MUST specify MAILER(smtp) before MAILER(uucp)]. When you
|
|
include the uucp mailer, sendmail looks for all names in
|
|
the $=U class and sends them to the uucp-old mailer; all
|
|
names in the $=Y class are sent to uucp-new; and all
|
|
names in the $=Z class are sent to uucp-uudom. Note that
|
|
this is a function of what version of rmail runs on
|
|
the receiving end, and hence may be out of your control.
|
|
See the section below describing UUCP mailers in more
|
|
detail.
|
|
|
|
usenet Usenet (network news) delivery. If this is specified,
|
|
an extra rule is added to ruleset 0 that forwards all
|
|
local email for users named ``group.usenet'' to the
|
|
``inews'' program. Note that this works for all groups,
|
|
and may be considered a security problem.
|
|
|
|
fax Facsimile transmission. This is experimental and based
|
|
on Sam Leffler's HylaFAX software. For more information,
|
|
see http://www.vix.com/hylafax/.
|
|
|
|
pop Post Office Protocol.
|
|
|
|
procmail An interface to procmail (does not come with sendmail).
|
|
This is designed to be used in mailertables. For example,
|
|
a common question is "how do I forward all mail for a given
|
|
domain to a single person?". If you have this mailer
|
|
defined, you could set up a mailertable reading:
|
|
|
|
host.com procmail:/etc/procmailrcs/host.com
|
|
|
|
with the file /etc/procmailrcs/host.com reading:
|
|
|
|
:0 # forward mail for host.com
|
|
! -oi -f $1 person@other.host
|
|
|
|
This would arrange for (anything)@host.com to be sent
|
|
to person@other.host. Within the procmail script, $1 is
|
|
the name of the sender and $2 is the name of the recipient.
|
|
If you use this with FEATURE(local_procmail), the FEATURE
|
|
should be listed first.
|
|
|
|
mail11 The DECnet mail11 mailer, useful only if you have the mail11
|
|
program from gatekeeper.dec.com:/pub/DEC/gwtools (and
|
|
DECnet, of course). This is for Phase IV DECnet support;
|
|
if you have Phase V at your site you may have additional
|
|
problems.
|
|
|
|
phquery The phquery program. This is somewhat counterintuitively
|
|
referenced as the "ph" mailer internally. It can be used
|
|
to do CCSO name server lookups. The phquery program, which
|
|
this mailer uses, is distributed with the ph client.
|
|
|
|
cyrus The cyrus and cyrusbb mailers. The cyrus mailer delivers to
|
|
a local cyrus user. this mailer can make use of the
|
|
"user+detail@local.host" syntax; it will deliver the mail to
|
|
the user's "detail" mailbox if the mailbox's ACL permits.
|
|
The cyrusbb mailer delivers to a system-wide cyrus mailbox
|
|
if the mailbox's ACL permits.
|
|
|
|
|
|
The local mailer accepts addresses of the form "user+detail", where
|
|
the "+detail" is not used for mailbox matching but is available
|
|
to certain local mail programs (in particular, see FEATURE(local_procmail)).
|
|
For example, "eric", "eric+sendmail", and "eric+sww" all indicate
|
|
the same user, but additional arguments <null>, "sendmail", and "sww"
|
|
may be provided for use in sorting mail.
|
|
|
|
|
|
+----------+
|
|
| FEATURES |
|
|
+----------+
|
|
|
|
Special features can be requested using the "FEATURE" macro. For
|
|
example, the .mc line:
|
|
|
|
FEATURE(use_cw_file)
|
|
|
|
tells sendmail that you want to have it read an /etc/sendmail.cw
|
|
file to get values for class $=w. The FEATURE may contain a single
|
|
optional parameter -- for example:
|
|
|
|
FEATURE(mailertable, dbm /usr/lib/mailertable)
|
|
|
|
The default database map type for the table features can be set with
|
|
|
|
define(`DATABASE_MAP_TYPE', `dbm')
|
|
|
|
which would set it to use ndbm databases. The default is the Berkeley DB
|
|
hash database format. Note that you must still declare a database map type
|
|
if you specify an argument to a FEATURE. DATABASE_MAP_TYPE is only used
|
|
if no argument is given for the FEATURE.
|
|
|
|
Available features are:
|
|
|
|
use_cw_file Read the file /etc/sendmail.cw file to get alternate
|
|
names for this host. This might be used if you were
|
|
on a host that MXed for a dynamic set of other
|
|
hosts. If the set is static, just including the line
|
|
"Cw<name1> <name2> ..." (where the names are fully
|
|
qualified domain names) is probably superior.
|
|
The actual filename can be overridden by redefining
|
|
confCW_FILE.
|
|
|
|
use_ct_file Read the file /etc/sendmail.ct file to get the names
|
|
of users that will be ``trusted'', that is, able to
|
|
set their envelope from address using -f without
|
|
generating a warning message.
|
|
The actual filename can be overridden by redefining
|
|
confCT_FILE.
|
|
|
|
redirect Reject all mail addressed to "address.REDIRECT" with
|
|
a ``551 User not local; please try <address>'' message.
|
|
If this is set, you can alias people who have left
|
|
to their new address with ".REDIRECT" appended.
|
|
|
|
nouucp Don't do anything special with UUCP addresses at all.
|
|
|
|
nocanonify Don't pass addresses to $[ ... $] for canonification.
|
|
This would generally only be used by sites that only
|
|
act as mail gateways or which have user agents that do
|
|
full canonification themselves. You may also want to
|
|
use "define(`confBIND_OPTS',`-DNSRCH -DEFNAMES')" to
|
|
turn off the usual resolver options that do a similar
|
|
thing.
|
|
|
|
stickyhost If set, email sent to "user@local.host" are marked
|
|
as "sticky" -- that is, the local addresses aren't
|
|
matched against UDB and don't go through ruleset 5.
|
|
This is used if you want a set up where "user" is
|
|
not necessarily the same as "user@local.host", e.g.,
|
|
to make a distinct domain-wide namespace. Prior to
|
|
8.7 this was the default, and notsticky was used to
|
|
turn this off.
|
|
|
|
mailertable Include a "mailer table" which can be used to override
|
|
routing for particular domains. The argument of the
|
|
FEATURE may be the key definition. If none is specified,
|
|
the definition used is:
|
|
hash -o /etc/mailertable
|
|
Keys in this database are fully qualified domain names
|
|
or partial domains preceded by a dot -- for example,
|
|
"vangogh.CS.Berkeley.EDU" or ".CS.Berkeley.EDU".
|
|
Values must be of the form:
|
|
mailer:domain
|
|
where "mailer" is the internal mailer name, and "domain"
|
|
is where to send the message. These maps are not
|
|
reflected into the message header. As a special case,
|
|
the forms:
|
|
local:user
|
|
will forward to the indicated user using the local mailer,
|
|
local:
|
|
will forward to the original user in the e-mail address
|
|
using the local mailer, and
|
|
error:code message
|
|
will give an error message with the indicated code and
|
|
message.
|
|
|
|
domaintable Include a "domain table" which can be used to provide
|
|
domain name mapping. Use of this should really be
|
|
limited to your own domains. It may be useful if you
|
|
change names (e.g., your company changes names from
|
|
oldname.com to newname.com). The argument of the
|
|
FEATURE may be the key definition. If none is specified,
|
|
the definition used is:
|
|
hash -o /etc/domaintable
|
|
The key in this table is the domain name; the value is
|
|
the new (fully qualified) domain. Anything in the
|
|
domaintable is reflected into headers; that is, this
|
|
is done in ruleset 3.
|
|
|
|
bitdomain Look up bitnet hosts in a table to try to turn them into
|
|
internet addresses. The table can be built using the
|
|
bitdomain program contributed by John Gardiner Myers.
|
|
The argument of the FEATURE may be the key definition; if
|
|
none is specified, the definition used is:
|
|
hash -o /etc/bitdomain.db
|
|
Keys are the bitnet hostname; values are the corresponding
|
|
internet hostname.
|
|
|
|
uucpdomain Similar feature for UUCP hosts. The default map definition
|
|
is:
|
|
hash -o /etc/uudomain.db
|
|
At the moment there is no automagic tool to build this
|
|
database.
|
|
|
|
always_add_domain
|
|
Include the local host domain even on locally delivered
|
|
mail. Normally it is not added on unqualified names.
|
|
However, if you use a shared message store but do not use
|
|
the same user name space everywhere, you may need the host
|
|
name on local names.
|
|
|
|
allmasquerade If masquerading is enabled (using MASQUERADE_AS), this
|
|
feature will cause recipient addresses to also masquerade
|
|
as being from the masquerade host. Normally they get
|
|
the local hostname. Although this may be right for
|
|
ordinary users, it can break local aliases. For example,
|
|
if you send to "localalias", the originating sendmail will
|
|
find that alias and send to all members, but send the
|
|
message with "To: localalias@masqueradehost". Since that
|
|
alias likely does not exist, replies will fail. Use this
|
|
feature ONLY if you can guarantee that the ENTIRE
|
|
namespace on your masquerade host supersets all the
|
|
local entries.
|
|
|
|
limited_masquerade
|
|
Normally, any hosts listed in $=w are masqueraded. If this
|
|
feature is given, only the hosts listed in $=M are masqueraded.
|
|
This is useful if you have several domains with disjoint
|
|
namespaces hosted on the same machine.
|
|
|
|
masquerade_entire_domain
|
|
If masquerading is enabled (using MASQUERADE_AS) and
|
|
MASQUERADE_DOMAIN (see below) is set, this feature will
|
|
cause addresses to be rewritten such that the masquerading
|
|
domains are actually entire domains to be hidden. All
|
|
hosts within the masquerading domains will be rewritten
|
|
to the masquerade name (used in MASQUERADE_AS). For example,
|
|
if you have:
|
|
|
|
MASQUERADE_AS(masq.com)
|
|
MASQUERADE_DOMAIN(foo.org)
|
|
MASQUERADE_DOMAIN(bar.com)
|
|
|
|
then *foo.org and *bar.com are converted to masq.com. Without
|
|
this feature, only foo.org and bar.com are masqueraded.
|
|
|
|
NOTE: only domains within your jurisdiction and
|
|
current hierarchy should be masqueraded using this.
|
|
|
|
genericstable This feature will cause certain addresses originating locally
|
|
(i.e. that are unqualified) or a domain listed in $=G to be
|
|
looked up in a map and turned into another ("generic") form,
|
|
which can change both the domain name and the user name. This
|
|
is similar to the userdb functionality. The same types of
|
|
addresses as for masquerading are looked up, i.e. only header
|
|
sender addresses unless the allmasquerade and/or
|
|
masquerade_envelope features are given. Qualified addresses
|
|
must have the domain part in the list of names given by the
|
|
by the macros GENERICS_DOMAIN or GENERICS_DOMAIN_FILE
|
|
(analogously to MASQUERADE_DOMAIN and MASQUERADE_DOMAIN_FILE,
|
|
see below).
|
|
|
|
The argument of FEATURE(genericstable) may be the map
|
|
definition; the default map definition is:
|
|
|
|
hash -o /etc/genericstable
|
|
|
|
The key for this table is either the full address or the
|
|
unqualified username (the former is tried first); the
|
|
value is the new user address. If the new user address does
|
|
not include a domain, it will be qualified in the standard
|
|
manner, i.e. using $j or the masquerade name. Note that the
|
|
address being looked up must be fully qualified. For local
|
|
mail, it is necessary to use FEATURE(always_add_domain) for
|
|
the addresses to be qualified.
|
|
|
|
virtusertable A domain-specific form of aliasing, allowing multiple
|
|
virtual domains to be hosted on one machine. For example,
|
|
if the virtuser table contained:
|
|
|
|
info@foo.com foo-info
|
|
info@bar.com bar-info
|
|
@baz.org jane@elsewhere.net
|
|
|
|
then mail addressed to info@foo.com will be sent to the
|
|
address foo-info, mail addressed to info@bar.com will be
|
|
delivered to bar-info, and mail addressed to anyone at
|
|
baz.org will be sent to jane@elsewhere.net. The username
|
|
from the original address is passed as %1 allowing:
|
|
|
|
@foo.org %1@elsewhere.com
|
|
|
|
meaning someone@foo.org will be sent to someone@elsewhere.com.
|
|
|
|
All the host names on the left hand side (foo.com, bar.com,
|
|
and baz.org) must be in $=w. The default map definition is:
|
|
|
|
hash -o /etc/virtusertable
|
|
|
|
A new definition can be specified as the second argument of
|
|
the FEATURE macro, such as
|
|
|
|
FEATURE(virtusertable, dbm -o /etc/mail/virtusers)
|
|
|
|
nodns We aren't running DNS at our site (for example,
|
|
we are UUCP-only connected). It's hard to consider
|
|
this a "feature", but hey, it had to go somewhere.
|
|
Actually, as of 8.7 this is a no-op -- remove "dns" from
|
|
the hosts service switch entry instead.
|
|
|
|
nullclient This is a special case -- it creates a stripped down
|
|
configuration file containing nothing but support for
|
|
forwarding all mail to a central hub via a local
|
|
SMTP-based network. The argument is the name of that
|
|
hub.
|
|
|
|
The only other feature that should be used in conjunction
|
|
with this one is "nocanonify" (this causes addresses to
|
|
be sent unqualified via the SMTP connection; normally
|
|
they are qualified with the masquerade name, which
|
|
defaults to the name of the hub machine). No mailers
|
|
should be defined. No aliasing or forwarding is done.
|
|
Also, note that absolutely no anti-spam or anti-relaying
|
|
is done in a null client configuration. More information
|
|
can be found in the ANTI-SPAM CONFIGURATION CONTROL section.
|
|
|
|
local_lmtp Use an LMTP capable local mailer. The argument to this
|
|
feature is the pathname of an LMTP capable mailer. By
|
|
default, mail.local is used. This is expected to be the
|
|
mail.local which came with the 8.9 distribution which is
|
|
LMTP capable. The path to mail.local is set by the
|
|
confEBINDIR m4 variable -- making the default
|
|
LOCAL_MAILER_PATH /usr/libexec/mail.local.
|
|
|
|
local_procmail Use procmail as the local mailer. This mailer can
|
|
make use of the "user+indicator@local.host" syntax;
|
|
normally the +indicator is just tossed, but by default
|
|
it is passed as the -a argument to procmail. The
|
|
argument to this feature is the pathname of procmail,
|
|
which defaults to PROCMAIL_MAILER_PATH. Note that this
|
|
does NOT use PROCMAIL_MAILER_FLAGS or PROCMAIL_MAILER_ARGS
|
|
for the local mailer; tweak LOCAL_MAILER_FLAGS and
|
|
LOCAL_MAILER_ARGS instead.
|
|
|
|
bestmx_is_local Accept mail as though locally addressed for any host that
|
|
lists us as the best possible MX record. This generates
|
|
additional DNS traffic, but should be OK for low to
|
|
medium traffic hosts. The argument may be a set of
|
|
domains, which will limit the feature to only apply to
|
|
these domains -- this will reduce unnecessary DNS
|
|
traffic. THIS FEATURE IS FUNDAMENTALLY INCOMPATIBLE WITH
|
|
WILDCARD MX RECORDS!!! If you have a wildcard MX record
|
|
that matches your domain, you cannot use this feature.
|
|
|
|
smrsh Use the SendMail Restricted SHell (smrsh) provided
|
|
with the distribution instead of /bin/sh for mailing
|
|
to programs. This improves the ability of the local
|
|
system administrator to control what gets run via
|
|
e-mail. If an argument is provided it is used as the
|
|
pathname to smrsh; otherwise, the path defined by
|
|
confEBINDIR is used for the smrsh binary -- by default,
|
|
/usr/libexec/smrsh is assumed.
|
|
|
|
promiscuous_relay
|
|
By default, the sendmail configuration files do not permit
|
|
mail relaying (that is, accepting mail from outside your
|
|
domain and sending it to another host outside your domain).
|
|
This option sets your site to allow mail relaying from any
|
|
site to any site. In general, it is better to control the
|
|
relaying more carefully with the access db and the 'R'
|
|
class ($=R). Domains can be added to class 'R' by the
|
|
macros RELAY_DOMAIN or RELAY_DOMAIN_FILE (analogously to
|
|
MASQUERADE_DOMAIN and MASQUERADE_DOMAIN_FILE, see below).
|
|
|
|
relay_entire_domain
|
|
By default, only hosts listed as RELAY in the access db
|
|
will be allowed to relay. This option also allows any
|
|
host in your domain as defined by the 'm' class ($=m).
|
|
|
|
relay_hosts_only
|
|
By default, names that are listed as RELAY in the access
|
|
db and class 'R' ($=R) are domain names, not host names.
|
|
For example, if you specify ``foo.com'', then mail to or
|
|
from foo.com, abc.foo.com, or a.very.deep.domain.foo.com
|
|
will all be accepted for relaying. This feature changes
|
|
the behaviour to lookup individual host names only.
|
|
|
|
relay_based_on_MX
|
|
Turns on the ability to allow relaying based on the MX
|
|
records of the host portion of an incoming recipient; that
|
|
is, if an MX record for host foo.com points to your site,
|
|
you will accept and relay mail addressed to foo.com. See
|
|
description below for more information before using this
|
|
feature. Also, see the KNOWNBUGS entry regarding bestmx
|
|
map lookups.
|
|
|
|
FEATURE(relay_based_on_MX) does not necessarily allow
|
|
routing of these messages which you expect to be allowed,
|
|
if route address syntax (or %-hack syntax) is used. If
|
|
this is a problem, add entries to the access-table or use
|
|
FEATURE(loose_relay_check).
|
|
|
|
relay_local_from
|
|
Allows relaying if the domain portion of the mail sender
|
|
is a local host. This should only be used if absolutely
|
|
necessary as it opens a window for spammers. Specifically,
|
|
they can send mail to your mail server that claims to be
|
|
from your domain (either directly or via a routed address),
|
|
and you will go ahead and relay it out to arbitrary hosts
|
|
on the Internet.
|
|
|
|
accept_unqualified_senders
|
|
Normally, MAIL FROM: commands in the SMTP session will be
|
|
refused if the connection is a network connection and the
|
|
sender address does not include a domain name. If your
|
|
setup sends local mail unqualified (i.e. MAIL FROM: <joe>),
|
|
you will need to use this feature to accept unqualified
|
|
sender addresses.
|
|
|
|
accept_unresolvable_domains
|
|
Normally, MAIL FROM: commands in the SMTP session will be
|
|
refused if the host part of the argument to MAIL FROM: cannot
|
|
be located in the host name service (e.g., DNS). If you are
|
|
inside a firewall that has only a limited view of the
|
|
Internet host name space, this could cause problems. In this
|
|
case you probably want to use this feature to accept all
|
|
domains on input, even if they are unresolvable.
|
|
|
|
access_db Turns on the access database feature. The access db gives
|
|
you the ability to allow or refuse to accept mail from
|
|
specified domains for administrative reasons. By default,
|
|
the access database specification is
|
|
``hash -o /etc/mail/access''. The format of the
|
|
database is described below.
|
|
|
|
blacklist_recipients
|
|
Turns on the ability to block incoming mail for certain
|
|
recipient usernames, hostnames, or addresses. For
|
|
example, you can block incoming mail to user nobody,
|
|
host foo.mydomain.com, or guest@bar.mydomain.com.
|
|
These specifications are put in the access db as
|
|
described below.
|
|
|
|
rbl Turns on rejection of hosts found in the Realtime Blackhole
|
|
List. If an argument is provided it is used as the
|
|
name sever to contact; otherwise, the main RBL server at
|
|
rbl.maps.vix.com is used. For details, see
|
|
http://maps.vix.com/rbl/.
|
|
|
|
loose_relay_check
|
|
Normally, if a recipient using % addressing is used, e.g.
|
|
user%site@othersite, and othersite is in class 'R', the
|
|
check_rcpt ruleset will strip @othersite and recheck
|
|
user@site for relaying. This feature changes that
|
|
behavior. It should not be needed for most installations.
|
|
|
|
|
|
+-------+
|
|
| HACKS |
|
|
+-------+
|
|
|
|
Some things just can't be called features. To make this clear,
|
|
they go in the hack subdirectory and are referenced using the HACK
|
|
macro. These will tend to be site-dependent. The release
|
|
includes the Berkeley-dependent "cssubdomain" hack (that makes
|
|
sendmail accept local names in either Berkeley.EDU or CS.Berkeley.EDU;
|
|
this is intended as a short-term aid while we move hosts into
|
|
subdomains.
|
|
|
|
|
|
+--------------------+
|
|
| SITE CONFIGURATION |
|
|
+--------------------+
|
|
|
|
*****************************************************
|
|
* This section is really obsolete, and is preserved *
|
|
* only for back compatibility. You should plan on *
|
|
* using mailertables for new installations. In *
|
|
* particular, it doesn't work for the newer forms *
|
|
* of UUCP mailers, such as uucp-uudom. *
|
|
*****************************************************
|
|
|
|
Complex sites will need more local configuration information, such as
|
|
lists of UUCP hosts they speak with directly. This can get a bit more
|
|
tricky. For an example of a "complex" site, see cf/ucbvax.mc.
|
|
|
|
If your host is known by several different names, you need to augment
|
|
the $=w class. This is a list of names by which you are known, and
|
|
anything sent to an address using a host name in this list will be
|
|
treated as local mail. You can do this in two ways: either create
|
|
the file /etc/sendmail.cw containing a list of your aliases (one per
|
|
line), and use ``FEATURE(use_cw_file)'' in the .mc file, or add the
|
|
line:
|
|
|
|
Cw alias.host.name
|
|
|
|
at the end of that file. See the ``vangogh.mc'' file for an example.
|
|
Be sure you use the fully-qualified name of the host, rather than a
|
|
short name.
|
|
|
|
The SITECONFIG macro allows you to indirectly reference site-dependent
|
|
configuration information stored in the siteconfig subdirectory. For
|
|
example, the line
|
|
|
|
SITECONFIG(uucp.ucbvax, ucbvax, U)
|
|
|
|
reads the file uucp.ucbvax for local connection information. The
|
|
second parameter is the local name (in this case just "ucbvax" since
|
|
it is locally connected, and hence a UUCP hostname). The third
|
|
parameter is the name of both a macro to store the local name (in
|
|
this case, $U) and the name of the class (e.g., $=U) in which to store
|
|
the host information read from the file. Another SITECONFIG line reads
|
|
|
|
SITECONFIG(uucp.ucbarpa, ucbarpa.Berkeley.EDU, W)
|
|
|
|
This says that the file uucp.ucbarpa contains the list of UUCP sites
|
|
connected to ucbarpa.Berkeley.EDU. The $=W class will be used to
|
|
store this list, and $W is defined to be ucbarpa.Berkeley.EDU, that
|
|
is, the name of the relay to which the hosts listed in uucp.ucbarpa
|
|
are connected. [The machine ucbarpa is gone now, but I've left
|
|
this out-of-date configuration file around to demonstrate how you
|
|
might do this.]
|
|
|
|
Note that the case of SITECONFIG with a third parameter of ``U'' is
|
|
special; the second parameter is assumed to be the UUCP name of the
|
|
local site, rather than the name of a remote site, and the UUCP name
|
|
is entered into $=w (the list of local hostnames) as $U.UUCP.
|
|
|
|
The siteconfig file (e.g., siteconfig/uucp.ucbvax.m4) contains nothing
|
|
more than a sequence of SITE macros describing connectivity. For
|
|
example:
|
|
|
|
SITE(cnmat)
|
|
SITE(sgi olympus)
|
|
|
|
The second example demonstrates that you can use two names on the
|
|
same line; these are usually aliases for the same host (or are at
|
|
least in the same company).
|
|
|
|
|
|
+--------------------+
|
|
| USING UUCP MAILERS |
|
|
+--------------------+
|
|
|
|
It's hard to get UUCP mailers right because of the extremely ad hoc
|
|
nature of UUCP addressing. These config files are really designed
|
|
for domain-based addressing, even for UUCP sites.
|
|
|
|
There are four UUCP mailers available. The choice of which one to
|
|
use is partly a matter of local preferences and what is running at
|
|
the other end of your UUCP connection. Unlike good protocols that
|
|
define what will go over the wire, UUCP uses the policy that you
|
|
should do what is right for the other end; if they change, you have
|
|
to change. This makes it hard to do the right thing, and discourages
|
|
people from updating their software. In general, if you can avoid
|
|
UUCP, please do.
|
|
|
|
The major choice is whether to go for a domainized scheme or a
|
|
non-domainized scheme. This depends entirely on what the other
|
|
end will recognize. If at all possible, you should encourage the
|
|
other end to go to a domain-based system -- non-domainized addresses
|
|
don't work entirely properly.
|
|
|
|
The four mailers are:
|
|
|
|
uucp-old (obsolete name: "uucp")
|
|
This is the oldest, the worst (but the closest to UUCP) way of
|
|
sending messages accros UUCP connections. It does bangify
|
|
everything and prepends $U (your UUCP name) to the sender's
|
|
address (which can already be a bang path itself). It can
|
|
only send to one address at a time, so it spends a lot of
|
|
time copying duplicates of messages. Avoid this if at all
|
|
possible.
|
|
|
|
uucp-new (obsolete name: "suucp")
|
|
The same as above, except that it assumes that in one rmail
|
|
command you can specify several recipients. It still has a
|
|
lot of other problems.
|
|
|
|
uucp-dom
|
|
This UUCP mailer keeps everything as domain addresses.
|
|
Basically, it uses the SMTP mailer rewriting rules. This mailer
|
|
is only included if MAILER(smtp) is also specified.
|
|
|
|
Unfortunately, a lot of UUCP mailer transport agents require
|
|
bangified addresses in the envelope, although you can use
|
|
domain-based addresses in the message header. (The envelope
|
|
shows up as the From_ line on UNIX mail.) So....
|
|
|
|
uucp-uudom
|
|
This is a cross between uucp-new (for the envelope addresses)
|
|
and uucp-dom (for the header addresses). It bangifies the
|
|
envelope sender (From_ line in messages) without adding the
|
|
local hostname, unless there is no host name on the address
|
|
at all (e.g., "wolf") or the host component is a UUCP host name
|
|
instead of a domain name ("somehost!wolf" instead of
|
|
"some.dom.ain!wolf"). This is also included only if MAILER(smtp)
|
|
is also specified.
|
|
|
|
Examples:
|
|
|
|
We are on host grasp.insa-lyon.fr (UUCP host name "grasp"). The
|
|
following summarizes the sender rewriting for various mailers.
|
|
|
|
Mailer sender rewriting in the envelope
|
|
------ ------ -------------------------
|
|
uucp-{old,new} wolf grasp!wolf
|
|
uucp-dom wolf wolf@grasp.insa-lyon.fr
|
|
uucp-uudom wolf grasp.insa-lyon.fr!wolf
|
|
|
|
uucp-{old,new} wolf@fr.net grasp!fr.net!wolf
|
|
uucp-dom wolf@fr.net wolf@fr.net
|
|
uucp-uudom wolf@fr.net fr.net!wolf
|
|
|
|
uucp-{old,new} somehost!wolf grasp!somehost!wolf
|
|
uucp-dom somehost!wolf somehost!wolf@grasp.insa-lyon.fr
|
|
uucp-uudom somehost!wolf grasp.insa-lyon.fr!somehost!wolf
|
|
|
|
If you are using one of the domainized UUCP mailers, you really want
|
|
to convert all UUCP addresses to domain format -- otherwise, it will
|
|
do it for you (and probably not the way you expected). For example,
|
|
if you have the address foo!bar!baz (and you are not sending to foo),
|
|
the heuristics will add the @uucp.relay.name or @local.host.name to
|
|
this address. However, if you map foo to foo.host.name first, it
|
|
will not add the local hostname. You can do this using the uucpdomain
|
|
feature.
|
|
|
|
|
|
+-------------------+
|
|
| TWEAKING RULESETS |
|
|
+-------------------+
|
|
|
|
For more complex configurations, you can define special rules.
|
|
The macro LOCAL_RULE_3 introduces rules that are used in canonicalizing
|
|
the names. Any modifications made here are reflected in the header.
|
|
|
|
A common use is to convert old UUCP addresses to SMTP addresses using
|
|
the UUCPSMTP macro. For example:
|
|
|
|
LOCAL_RULE_3
|
|
UUCPSMTP(decvax, decvax.dec.com)
|
|
UUCPSMTP(research, research.att.com)
|
|
|
|
will cause addresses of the form "decvax!user" and "research!user"
|
|
to be converted to "user@decvax.dec.com" and "user@research.att.com"
|
|
respectively.
|
|
|
|
This could also be used to look up hosts in a database map:
|
|
|
|
LOCAL_RULE_3
|
|
R$* < @ $+ > $* $: $1 < @ $(hostmap $2 $) > $3
|
|
|
|
This map would be defined in the LOCAL_CONFIG portion, as shown below.
|
|
|
|
Similarly, LOCAL_RULE_0 can be used to introduce new parsing rules.
|
|
For example, new rules are needed to parse hostnames that you accept
|
|
via MX records. For example, you might have:
|
|
|
|
LOCAL_RULE_0
|
|
R$+ <@ host.dom.ain.> $#uucp $@ cnmat $: $1 < @ host.dom.ain.>
|
|
|
|
You would use this if you had installed an MX record for cnmat.Berkeley.EDU
|
|
pointing at this host; this rule catches the message and forwards it on
|
|
using UUCP.
|
|
|
|
You can also tweak rulesets 1 and 2 using LOCAL_RULE_1 and LOCAL_RULE_2.
|
|
These rulesets are normally empty.
|
|
|
|
A similar macro is LOCAL_CONFIG. This introduces lines added after the
|
|
boilerplate option setting but before rulesets, and can be used to
|
|
declare local database maps or whatever. For example:
|
|
|
|
LOCAL_CONFIG
|
|
Khostmap hash /etc/hostmap.db
|
|
Kyplocal nis -m hosts.byname
|
|
|
|
|
|
+---------------------------+
|
|
| MASQUERADING AND RELAYING |
|
|
+---------------------------+
|
|
|
|
You can have your host masquerade as another using
|
|
|
|
MASQUERADE_AS(host.domain)
|
|
|
|
This causes mail being sent to be labeled as coming from the
|
|
indicated host.domain, rather than $j. One normally masquerades as
|
|
one of one's own subdomains (for example, it's unlikely that I would
|
|
choose to masquerade as an MIT site). This behaviour is modified by
|
|
a plethora of FEATUREs; in particular, see masquerade_envelope,
|
|
allmasquerade, limited_masquerade, and masquerade_entire_domain.
|
|
|
|
The masquerade name is not normally canonified, so it is important
|
|
that it be your One True Name, that is, fully qualified and not a
|
|
CNAME. However, if you use a CNAME, the receiving side may canonify
|
|
it for you, so don't think you can cheat CNAME mapping this way.
|
|
|
|
Normally the only addresses that are masqueraded are those that come
|
|
from this host (that is, are either unqualified or in $=w, the list
|
|
of local domain names). You can augment this list using
|
|
|
|
MASQUERADE_DOMAIN(otherhost.domain)
|
|
|
|
The effect of this is that although mail to user@otherhost.domain
|
|
will not be delivered locally, any mail including any user@otherhost.domain
|
|
will, when relayed, be rewritten to have the MASQUERADE_AS address.
|
|
This can be a space-separated list of names.
|
|
|
|
If these names are in a file, you can use
|
|
|
|
MASQUERADE_DOMAIN_FILE(filename)
|
|
|
|
to read the list of names from the indicated file.
|
|
|
|
Normally only header addresses are masqueraded. If you want to
|
|
masquerade the envelope as well, use
|
|
|
|
FEATURE(masquerade_envelope)
|
|
|
|
There are always users that need to be "exposed" -- that is, their
|
|
internal site name should be displayed instead of the masquerade name.
|
|
Root is an example. You can add users to this list using
|
|
|
|
EXPOSED_USER(usernames)
|
|
|
|
This adds users to class E; you could also use something like
|
|
|
|
FE/etc/sendmail.cE
|
|
|
|
You can also arrange to relay all unqualified names (that is, names
|
|
without @host) to a relay host. For example, if you have a central
|
|
email server, you might relay to that host so that users don't have
|
|
to have .forward files or aliases. You can do this using
|
|
|
|
define(`LOCAL_RELAY', mailer:hostname)
|
|
|
|
The ``mailer:'' can be omitted, in which case the mailer defaults to
|
|
"relay". There are some user names that you don't want relayed, perhaps
|
|
because of local aliases. A common example is root, which may be
|
|
locally aliased. You can add entries to this list using
|
|
|
|
LOCAL_USER(usernames)
|
|
|
|
This adds users to class L; you could also use something like
|
|
|
|
FL/etc/sendmail.cL
|
|
|
|
If you want all incoming mail sent to a centralized hub, as for a
|
|
shared /var/spool/mail scheme, use
|
|
|
|
define(`MAIL_HUB', mailer:hostname)
|
|
|
|
Again, ``mailer:'' defaults to "relay". If you define both LOCAL_RELAY
|
|
and MAIL_HUB _AND_ you have FEATURE(stickyhost), unqualified names will
|
|
be sent to the LOCAL_RELAY and other local names will be sent to MAIL_HUB.
|
|
Names in $=L will be delivered locally, so you MUST have aliases or
|
|
.forward files for them.
|
|
|
|
For example, if you are on machine mastodon.CS.Berkeley.EDU and you have
|
|
FEATURE(stickyhost), the following combinations of settings will have the
|
|
indicated effects:
|
|
|
|
email sent to.... eric eric@mastodon.CS.Berkeley.EDU
|
|
|
|
LOCAL_RELAY set to mail.CS.Berkeley.EDU (delivered locally)
|
|
mail.CS.Berkeley.EDU (no local aliasing) (aliasing done)
|
|
|
|
MAIL_HUB set to mammoth.CS.Berkeley.EDU mammoth.CS.Berkeley.EDU
|
|
mammoth.CS.Berkeley.EDU (aliasing done) (aliasing done)
|
|
|
|
Both LOCAL_RELAY and mail.CS.Berkeley.EDU mammoth.CS.Berkeley.EDU
|
|
MAIL_HUB set as above (no local aliasing) (aliasing done)
|
|
|
|
If you do not have FEATURE(stickyhost) set, then LOCAL_RELAY and
|
|
MAIL_HUB act identically, with MAIL_HUB taking precedence.
|
|
|
|
If you want all outgoing mail to go to a central relay site, define
|
|
SMART_HOST as well. Briefly:
|
|
|
|
LOCAL_RELAY applies to unqualified names (e.g., "eric").
|
|
MAIL_HUB applies to names qualified with the name of the
|
|
local host (e.g., "eric@mastodon.CS.Berkeley.EDU").
|
|
SMART_HOST applies to names qualified with other hosts.
|
|
|
|
However, beware that other relays (e.g., UUCP_RELAY, BITNET_RELAY,
|
|
DECNET_RELAY, and FAX_RELAY) take precedence over SMART_HOST, so if you
|
|
really want absolutely everything to go to a single central site you will
|
|
need to unset all the other relays -- or better yet, find or build a
|
|
minimal config file that does this.
|
|
|
|
For duplicate suppression to work properly, the host name is best
|
|
specified with a terminal dot:
|
|
|
|
define(`MAIL_HUB', `host.domain.')
|
|
note the trailing dot ---^
|
|
|
|
|
|
+---------------------------------+
|
|
| ANTI-SPAM CONFIGURATION CONTROL |
|
|
+---------------------------------+
|
|
|
|
The primary anti-spam features available in sendmail are:
|
|
|
|
* Relaying is denied by default.
|
|
* Better checking on sender information.
|
|
* Access database.
|
|
* Header checks.
|
|
|
|
Relaying (transmission of messages from a site outside your domain to
|
|
another site outside your domain) is denied by default. Note that
|
|
this changed in sendmail 8.9; previous versions allowed relaying by
|
|
default. If you want to revert to the old behaviour, you will need
|
|
to use FEATURE(promiscuous_relay). You can allow certain domains to
|
|
relay through your server by adding their domain name or IP address to
|
|
class 'R' ($=R) using RELAY_DOMAIN() and RELAY_DOMAIN_FILE() or via the
|
|
access database (described below).
|
|
|
|
If you use
|
|
|
|
FEATURE(relay_entire_domain)
|
|
|
|
then any host in any of your local domains (that is, the $=m class)
|
|
will be relayed (that is, you will accept mail either to or from any
|
|
host in your domain).
|
|
|
|
You can also allow relaying based on the MX records of the host
|
|
portion of an incoming recipient address by using
|
|
|
|
FEATURE(relay_based_on_MX)
|
|
|
|
For example, if your server receives a recipient of user@domain.com
|
|
and domain.com lists your server in its MX records, the mail will be
|
|
accepted for relay to domain.com. Note that this will stop spammers
|
|
from using your host to relay spam but it will not stop outsiders from
|
|
using your server as a relay for their site (that is, they set up an
|
|
MX record pointing to your mail server, and you will relay mail addressed
|
|
to them without any prior arrangement). Along the same lines,
|
|
|
|
FEATURE(relay_local_from)
|
|
|
|
will allow relaying if the sender specifies a return path (i.e.
|
|
MAIL FROM: <user@domain>) domain which is a local domain. This a
|
|
dangerous feature as it will allow spammers to spam using your mail
|
|
server by simply specifying a return address of user@your.domain.com.
|
|
It should not be used unless absolutely necessary.
|
|
|
|
If source routing is used in the recipient address (i.e.
|
|
RCPT TO: <user%site.com@othersite.com>), sendmail will check
|
|
user@site.com for relaying if othersite.com is an allowed relay host
|
|
in either class 'R', class 'm' if FEATURE(relay_entire_domain) is used,
|
|
or the access database if FEATURE(access_db) is used. To prevent
|
|
the address from being stripped down, use:
|
|
|
|
FEATURE(loose_relay_check)
|
|
|
|
If you think you need to use this feature, you probably do not. This
|
|
should only be used for sites which have no control over the addresses
|
|
that they provide a gateway for. Use this FEATURE with caution as it
|
|
can allow spammers to relay through your server if not setup properly.
|
|
|
|
As of 8.9, sendmail will refuse mail if the MAIL FROM: parameter has
|
|
an unresolvable domain (i.e., one that DNS, your local name service,
|
|
or special case rules in ruleset 3 cannot locate). If you want to
|
|
continue to accept such domains, e.g. because you are inside a
|
|
firewall that has only a limited view of the Internet host name space
|
|
(note that you will not be able to return mail to them unless you have
|
|
some "smart host" forwarder), use
|
|
|
|
FEATURE(accept_unresolvable_domains)
|
|
|
|
sendmail will also refuse mail if the MAIL FROM: parameter is not
|
|
fully qualified (i.e., contains a domain as well as a user). If you
|
|
want to continue to accept such senders, use
|
|
|
|
FEATURE(accept_unqualified_senders)
|
|
|
|
An ``access'' database can be created to accept or reject mail from
|
|
selected domains. For example, you may choose to reject all mail
|
|
originating from known spammers. To enable such a database, use
|
|
|
|
FEATURE(access_db)
|
|
|
|
The FEATURE macro can accept a second parameter giving the key file
|
|
definition for the database; for example
|
|
|
|
FEATURE(access_db, hash -o /etc/mail/access)
|
|
|
|
Remember, since /etc/mail/access is a database, after creating the text
|
|
file as described below, you must use makemap to create the database
|
|
map. For example:
|
|
|
|
makemap hash /etc/mail/access < /etc/mail/access
|
|
|
|
The table itself uses e-mail addresses, domain names, and network
|
|
numbers as keys. For example,
|
|
|
|
spammer@aol.com REJECT
|
|
cyberspammer.com REJECT
|
|
192.168.212 REJECT
|
|
|
|
would refuse mail from spammer@aol.com, any user from cyberspammer.com
|
|
(or any host within the cyberspammer.com domain), and any host on the
|
|
192.168.212.* network.
|
|
|
|
The value part of the map can contain:
|
|
|
|
OK Accept mail even if other rules in the
|
|
running ruleset would reject it, for example,
|
|
if the domain name is unresolvable.
|
|
RELAY Accept mail addressed to the indicated domain or
|
|
received from the indicated domain for relaying
|
|
through your SMTP server. RELAY also serves as
|
|
an implicit OK for the other checks.
|
|
REJECT Reject the sender or recipient with a general
|
|
purpose message.
|
|
DISCARD Discard the message completely using the
|
|
$#discard mailer. This only works for sender
|
|
addresses (i.e., it indicates that you should
|
|
discard anything received from the indicated
|
|
domain).
|
|
### any text where ### is an RFC 821 compliant error code
|
|
and "any text" is a message to return for
|
|
the command.
|
|
|
|
For example:
|
|
|
|
cyberspammer.com 550 We don't accept mail from spammers
|
|
okay.cyberspammer.com OK
|
|
sendmail.org OK
|
|
128.32 RELAY
|
|
|
|
would accept mail from okay.cyberspammer.com, but would reject mail
|
|
from all other hosts at cyberspammer.com with the indicated message.
|
|
It would allow accept mail from any hosts in the sendmail.org domain,
|
|
and allow relaying for the 128.32.*.* network. Note, UUCP users may
|
|
need to add hostname.UUCP to the access database or class 'R' ($=R).
|
|
If you also use:
|
|
|
|
FEATURE(relay_hosts_only)
|
|
|
|
then the above example will allow relaying for sendmail.org, but not
|
|
hosts within the sendmail.org domain. Note that this will also require
|
|
hosts listed in class 'R' ($=R) to be fully qualified host names.
|
|
|
|
You can also use the access database to block sender addresses based on
|
|
the username portion of the address. For example:
|
|
|
|
FREE.STEALTH.MAILER@ 550 Spam not accepted
|
|
|
|
Note that you must include the @ after the username to signify that
|
|
this database entry is for checking only the username portion of the
|
|
sender address.
|
|
|
|
If you use:
|
|
|
|
FEATURE(blacklist_recipients)
|
|
|
|
then you can add entries to the map for local users, hosts in your
|
|
domains, or addresses in your domain which should not receive mail:
|
|
|
|
badlocaluser 550 Mailbox disabled for this username
|
|
host.mydomain.com 550 That host does not accept mail
|
|
user@otherhost.mydomain.com 550 Mailbox disabled for this recipient
|
|
|
|
This would prevent a recipient of badlocaluser@mydomain.com, any
|
|
user at host.mydomain.com, and the single address
|
|
user@otherhost.mydomain.com from receiving mail. Enabling this
|
|
feature will keep you from sending mails to all addresses that
|
|
have an error message or REJECT as value part in the access map.
|
|
Taking the example from above:
|
|
|
|
spammer@aol.com REJECT
|
|
cyberspammer.com REJECT
|
|
|
|
Mail can't be sent to spammer@aol.com or anyone at cyberspammer.com.
|
|
|
|
There is also a ``Realtime Blackhole List'' run by the MAPS project
|
|
at http://maps.vix.com/. This is a database maintained in DNS of
|
|
spammers. To use this database, use
|
|
|
|
FEATURE(rbl)
|
|
|
|
This will cause sendmail to reject mail from any site in the
|
|
Realtime Blackhole List database. You can specify an alternative
|
|
RBL name server to contact by specifying an argument to the FEATURE.
|
|
|
|
The features described above make use of the check_relay, check_mail,
|
|
and check_rcpt rulesets. If you wish to include your own checks,
|
|
you can put your checks in the rulesets Local_check_relay,
|
|
Local_check_mail, and Local_check_rcpt. For example if you wanted to
|
|
block senders with all numeric usernames (i.e. 2312343@bigisp.com),
|
|
you would use Local_check_mail and the new regex map:
|
|
|
|
LOCAL_CONFIG
|
|
Kallnumbers regex -a@MATCH ^[0-9]+$
|
|
|
|
LOCAL_RULESETS
|
|
SLocal_check_mail
|
|
# check address against various regex checks
|
|
R$* $: $>Parse0 $>3 $1
|
|
R$+ < @ bigisp.com. > $* $: $(allnumbers $1 $)
|
|
R@MATCH $#error $: 553 Header Error
|
|
|
|
These rules are called with the original arguments of the corresponding
|
|
check_* ruleset. If the local ruleset returns $#OK, no further checking
|
|
is done by the features described above and the mail is accepted. If the
|
|
local ruleset resolves to a mailer (such as $#error or $#discard), the
|
|
appropriate action is taken. Otherwise, the results of the local
|
|
rewriting are ignored.
|
|
|
|
|
|
You can also reject mail on the basis of the contents of headers.
|
|
This is done by adding a ruleset call to the 'H' header definition command
|
|
in sendmail.cf. For example, this can be used to check the validity of
|
|
a Message-ID: header:
|
|
|
|
LOCAL_RULESETS
|
|
HMessage-Id: $>CheckMessageId
|
|
|
|
SCheckMessageId
|
|
R< $+ @ $+ > $@ OK
|
|
R$* $#error $: 553 Header Error
|
|
|
|
Users of FEATURE(nullclient) who desire to use the anti-spam and
|
|
anti-relaying capabilities should replace FEATURE(nullclient, mailhub)
|
|
with:
|
|
|
|
undefine(`ALIAS_FILE')
|
|
define(`MAIL_HUB', `mailhub')
|
|
define(`SMART_HOST', `mailhub')
|
|
define(`confFORWARD_PATH', `')
|
|
|
|
where mailhub is the fully qualified hostname for their mail server.
|
|
|
|
|
|
+--------------------------------+
|
|
| ADDING NEW MAILERS OR RULESETS |
|
|
+--------------------------------+
|
|
|
|
Sometimes you may need to add entirely new mailers or rulesets. They
|
|
should be introduced with the constructs MAILER_DEFINITIONS and
|
|
LOCAL_RULESETS respectively. For example:
|
|
|
|
MAILER_DEFINITIONS
|
|
Mmymailer, ...
|
|
...
|
|
|
|
LOCAL_RULESETS
|
|
Smyruleset
|
|
...
|
|
|
|
|
|
+-------------------------------+
|
|
| NON-SMTP BASED CONFIGURATIONS |
|
|
+-------------------------------+
|
|
|
|
These configuration files are designed primarily for use by SMTP-based
|
|
sites. I don't pretend that they are well tuned for UUCP-only or
|
|
UUCP-primarily nodes (the latter is defined as a small local net
|
|
connected to the rest of the world via UUCP). However, there is one
|
|
hook to handle some special cases.
|
|
|
|
You can define a ``smart host'' that understands a richer address syntax
|
|
using:
|
|
|
|
define(`SMART_HOST', mailer:hostname)
|
|
|
|
In this case, the ``mailer:'' defaults to "relay". Any messages that
|
|
can't be handled using the usual UUCP rules are passed to this host.
|
|
|
|
If you are on a local SMTP-based net that connects to the outside
|
|
world via UUCP, you can use LOCAL_NET_CONFIG to add appropriate rules.
|
|
For example:
|
|
|
|
define(`SMART_HOST', suucp:uunet)
|
|
LOCAL_NET_CONFIG
|
|
R$* < @ $* .$m. > $* $#smtp $@ $2.$m. $: $1 < @ $2.$m. > $3
|
|
|
|
This will cause all names that end in your domain name ($m) via
|
|
SMTP; anything else will be sent via suucp (smart UUCP) to uunet.
|
|
If you have FEATURE(nocanonify), you may need to omit the dots after
|
|
the $m. If you are running a local DNS inside your domain which is
|
|
not otherwise connected to the outside world, you probably want to
|
|
use:
|
|
|
|
define(`SMART_HOST', smtp:fire.wall.com)
|
|
LOCAL_NET_CONFIG
|
|
R$* < @ $* . > $* $#smtp $@ $2. $: $1 < @ $2. > $3
|
|
|
|
That is, send directly only to things you found in your DNS lookup;
|
|
anything else goes through SMART_HOST.
|
|
|
|
You may need to turn off the anti-spam rules in order to accept
|
|
UUCP mail with FEATURE(promiscuous_relay) and
|
|
FEATURE(accept_unresolvable_domains).
|
|
|
|
|
|
+-----------+
|
|
| WHO AM I? |
|
|
+-----------+
|
|
|
|
Normally, the $j macro is automatically defined to be your fully
|
|
qualified domain name (FQDN). Sendmail does this by getting your
|
|
host name using gethostname and then calling gethostbyname on the
|
|
result. For example, in some environments gethostname returns
|
|
only the root of the host name (such as "foo"); gethostbyname is
|
|
supposed to return the FQDN ("foo.bar.com"). In some (fairly rare)
|
|
cases, gethostbyname may fail to return the FQDN. In this case
|
|
you MUST define confDOMAIN_NAME to be your fully qualified domain
|
|
name. This is usually done using:
|
|
|
|
Dmbar.com
|
|
define(`confDOMAIN_NAME', `$w.$m')dnl
|
|
|
|
|
|
+--------------------+
|
|
| USING MAILERTABLES |
|
|
+--------------------+
|
|
|
|
To use FEATURE(mailertable), you will have to create an external
|
|
database containing the routing information for various domains.
|
|
For example, a mailertable file in text format might be:
|
|
|
|
.my.domain xnet:%1.my.domain
|
|
uuhost1.my.domain suucp:uuhost1
|
|
.bitnet smtp:relay.bit.net
|
|
|
|
This should normally be stored in /etc/mailertable. The actual
|
|
database version of the mailertable is built using:
|
|
|
|
makemap hash /etc/mailertable.db < /etc/mailertable
|
|
|
|
The semantics are simple. Any LHS entry that does not begin with
|
|
a dot matches the full host name indicated. LHS entries beginning
|
|
with a dot match anything ending with that domain name -- that is,
|
|
they can be thought of as having a leading "*" wildcard. Matching
|
|
is done in order of most-to-least qualified -- for example, even
|
|
though ".my.domain" is listed first in the above example, an entry
|
|
of "uuhost1.my.domain" will match the second entry since it is
|
|
more explicit.
|
|
|
|
The RHS should always be a "mailer:host" pair. The mailer is the
|
|
configuration name of a mailer (that is, an `M' line in the
|
|
sendmail.cf file). The "host" will be the hostname passed to
|
|
that mailer. In domain-based matches (that is, those with leading
|
|
dots) the "%1" may be used to interpolate the wildcarded part of
|
|
the host name. For example, the first line above sends everything
|
|
addressed to "anything.my.domain" to that same host name, but using
|
|
the (presumably experimental) xnet mailer.
|
|
|
|
In some cases you may want to temporarily turn off MX records,
|
|
particularly on gateways. For example, you may want to MX
|
|
everything in a domain to one machine that then forwards it
|
|
directly. To do this, you might use the DNS configuration:
|
|
|
|
*.domain. IN MX 0 relay.machine
|
|
|
|
and on relay.machine use the mailertable:
|
|
|
|
.domain smtp:[gateway.domain]
|
|
|
|
The [square brackets] turn off MX records for this host only.
|
|
If you didn't do this, the mailertable would use the MX record
|
|
again, which would give you an MX loop.
|
|
|
|
|
|
+--------------------------------+
|
|
| USING USERDB TO MAP FULL NAMES |
|
|
+--------------------------------+
|
|
|
|
The user database was not originally intended for mapping full names
|
|
to login names (e.g., Eric.Allman => eric), but some people are using
|
|
it that way. (I would recommend that you set up aliases for this
|
|
purpose instead -- since you can specify multiple alias files, this
|
|
is fairly easy.) The intent was to locate the default maildrop at
|
|
a site, but allow you to override this by sending to a specific host.
|
|
|
|
If you decide to set up the user database in this fashion, it is
|
|
imperative that you not use FEATURE(stickyhost) -- otherwise,
|
|
e-mail sent to Full.Name@local.host.name will be rejected.
|
|
|
|
To build the internal form of the user database, use:
|
|
|
|
makemap btree /usr/data/base.db < /usr/data/base.txt
|
|
|
|
As a general rule, I am adamantly opposed to using full names as
|
|
e-mail addresses, since they are not in any sense unique. For example,
|
|
the Unix software-development community has two Andy Tannenbaums,
|
|
at least two well-known Peter Deutsches, and at one time Bell Labs
|
|
had two Stephen R. Bournes with offices along the same hallway.
|
|
Which one will be forced to suffer the indignity of being
|
|
Stephen_R_Bourne_2? The less famous of the two, or the one that
|
|
was hired later?
|
|
|
|
Finger should handle full names (and be fuzzy). Mail should use
|
|
handles, and not be fuzzy. [Not that I expect anyone to pay any
|
|
attention to my opinions.]
|
|
|
|
|
|
+--------------------------------+
|
|
| MISCELLANEOUS SPECIAL FEATURES |
|
|
+--------------------------------+
|
|
|
|
Plussed users
|
|
Sometimes it is convenient to merge configuration on a
|
|
centralized mail machine, for example, to forward all
|
|
root mail to a mail server. In this case it might be
|
|
useful to be able to treat the root addresses as a class
|
|
of addresses with subtle differences. You can do this
|
|
using plussed users. For example, a client might include
|
|
the alias:
|
|
|
|
root: root+client1@server
|
|
|
|
On the server, this will match an alias for "root+client1".
|
|
If that is not found, the alias "root+*" will be tried,
|
|
then "root".
|
|
|
|
LDAP
|
|
For notes on use LDAP in sendmail, see
|
|
http://www.stanford.edu/~bbense/Inst.html
|
|
|
|
|
|
|
|
+----------------+
|
|
| SECURITY NOTES |
|
|
+----------------+
|
|
|
|
A lot of sendmail security comes down to you. Sendmail 8 is much
|
|
more careful about checking for security problems than previous
|
|
versions, but there are some things that you still need to watch
|
|
for. In particular:
|
|
|
|
* Make sure the aliases file isn't writable except by trusted
|
|
system personnel. This includes both the text and database
|
|
version.
|
|
|
|
* Make sure that other files that sendmail reads, such as the
|
|
mailertable, are only writable by trusted system personnel.
|
|
|
|
* The queue directory should not be world writable PARTICULARLY
|
|
if your system allows "file giveaways" (that is, if a non-root
|
|
user can chown any file they own to any other user).
|
|
|
|
* If your system allows file giveaways, DO NOT create a publically
|
|
writable directory for forward files. This will allow anyone
|
|
to steal anyone else's e-mail. Instead, create a script that
|
|
copies the .forward file from users' home directories once a
|
|
night (if you want the non-NFS-mounted forward directory).
|
|
|
|
* If your system allows file giveaways, you'll find that
|
|
sendmail is much less trusting of :include: files -- in
|
|
particular, you'll have to have /SENDMAIL/ANY/SHELL/ in
|
|
/etc/shells before they will be trusted (that is, before
|
|
files and programs listed in them will be honored).
|
|
|
|
In general, file giveaways are a mistake -- if you can turn them
|
|
off I recommend you do so.
|
|
|
|
|
|
+--------------------------------+
|
|
| TWEAKING CONFIGURATION OPTIONS |
|
|
+--------------------------------+
|
|
|
|
There are a large number of configuration options that don't normally
|
|
need to be changed. However, if you feel you need to tweak them, you
|
|
can define the following M4 variables. This list is shown in four
|
|
columns: the name you define, the default value for that definition,
|
|
the option or macro that is affected (either Ox for an option or Dx
|
|
for a macro), and a brief description. Greater detail of the semantics
|
|
can be found in the Installation and Operations Guide.
|
|
|
|
Some options are likely to be deprecated in future versions -- that is,
|
|
the option is only included to provide back-compatibility. These are
|
|
marked with "*".
|
|
|
|
Remember that these options are M4 variables, and hence may need to
|
|
be quoted. In particular, arguments with commas will usually have to
|
|
be ``double quoted, like this phrase'' to avoid having the comma
|
|
confuse things. This is common for alias file definitions and for
|
|
the read timeout.
|
|
|
|
M4 Variable Name Configuration Description & [Default]
|
|
================ ============= =======================
|
|
confMAILER_NAME $n macro [MAILER-DAEMON] The sender name used
|
|
for internally generated outgoing
|
|
messages.
|
|
confDOMAIN_NAME $j macro If defined, sets $j. This should
|
|
only be done if your system cannot
|
|
determine your local domain name,
|
|
and then it should be set to
|
|
$w.Foo.COM, where Foo.COM is your
|
|
domain name.
|
|
confCF_VERSION $Z macro If defined, this is appended to the
|
|
configuration version name.
|
|
confFROM_HEADER From: [$?x$x <$g>$|$g$.] The format of an
|
|
internally generated From: address.
|
|
confRECEIVED_HEADER Received:
|
|
[$?sfrom $s $.$?_($?s$|from $.$_)
|
|
$.by $j ($v/$Z)$?r with $r$. id $i$?u
|
|
for $u; $|;
|
|
$.$b]
|
|
The format of the Received: header
|
|
in messages passed through this host.
|
|
It is unwise to try to change this.
|
|
confCW_FILE Fw class [/etc/sendmail.cw] Name of file used
|
|
to get the local additions to the $=w
|
|
(local host names) class.
|
|
confCT_FILE Ft class [/etc/sendmail.ct] Name of file used
|
|
to get the local additions to the $=t
|
|
(trusted users) class.
|
|
confCR_FILE FR class [/etc/mail/relay-domains] Name of
|
|
file used to get the local additions
|
|
to the $=R (hosts allowed to relay)
|
|
class.
|
|
confTRUSTED_USERS Ct class [no default] Names of users to add to
|
|
the list of trusted users. This list
|
|
always includes root, uucp, and daemon.
|
|
See also FEATURE(use_ct_file).
|
|
confSMTP_MAILER - [esmtp] The mailer name used when
|
|
SMTP connectivity is required.
|
|
One of "smtp", "smtp8", or "esmtp".
|
|
confUUCP_MAILER - [uucp-old] The mailer to be used by
|
|
default for bang-format recipient
|
|
addresses. See also discussion of
|
|
$=U, $=Y, and $=Z in the MAILER(uucp)
|
|
section.
|
|
confLOCAL_MAILER - [local] The mailer name used when
|
|
local connectivity is required.
|
|
Almost always "local".
|
|
confRELAY_MAILER - [relay] The default mailer name used
|
|
for relaying any mail (e.g., to a
|
|
BITNET_RELAY, a SMART_HOST, or
|
|
whatever). This can reasonably be
|
|
"uucp-new" if you are on a
|
|
UUCP-connected site.
|
|
confSEVEN_BIT_INPUT SevenBitInput [False] Force input to seven bits?
|
|
confEIGHT_BIT_HANDLING EightBitMode [pass8] 8-bit data handling
|
|
confALIAS_WAIT AliasWait [10m] Time to wait for alias file
|
|
rebuild until you get bored and
|
|
decide that the apparently pending
|
|
rebuild failed.
|
|
confMIN_FREE_BLOCKS MinFreeBlocks [100] Minimum number of free blocks on
|
|
queue filesystem to accept SMTP mail.
|
|
(Prior to 8.7 this was minfree/maxsize,
|
|
where minfree was the number of free
|
|
blocks and maxsize was the maximum
|
|
message size. Use confMAX_MESSAGE_SIZE
|
|
for the second value now.)
|
|
confMAX_MESSAGE_SIZE MaxMessageSize [infinite] The maximum size of messages
|
|
that will be accepted (in bytes).
|
|
confBLANK_SUB BlankSub [.] Blank (space) substitution
|
|
character.
|
|
confCON_EXPENSIVE HoldExpensive [False] Avoid connecting immediately
|
|
to mailers marked expensive?
|
|
confCHECKPOINT_INTERVAL CheckpointInterval
|
|
[10] Checkpoint queue files every N
|
|
recipients.
|
|
confDELIVERY_MODE DeliveryMode [background] Default delivery mode.
|
|
confAUTO_REBUILD AutoRebuildAliases
|
|
[False] Automatically rebuild alias
|
|
file if needed.
|
|
confERROR_MODE ErrorMode [print] Error message mode.
|
|
confERROR_MESSAGE ErrorHeader [undefined] Error message header/file.
|
|
confSAVE_FROM_LINES SaveFromLine Save extra leading From_ lines.
|
|
confTEMP_FILE_MODE TempFileMode [0600] Temporary file mode.
|
|
confMATCH_GECOS MatchGECOS [False] Match GECOS field.
|
|
confMAX_HOP MaxHopCount [25] Maximum hop count.
|
|
confIGNORE_DOTS* IgnoreDots [False; always False in -bs or -bd mode]
|
|
Ignore dot as terminator for incoming
|
|
messages?
|
|
confBIND_OPTS ResolverOptions [undefined] Default options for DNS
|
|
resolver.
|
|
confMIME_FORMAT_ERRORS* SendMimeErrors [True] Send error messages as MIME-
|
|
encapsulated messages per RFC 1344.
|
|
confFORWARD_PATH ForwardPath [$z/.forward.$w:$z/.forward]
|
|
The colon-separated list of places to
|
|
search for .forward files. N.B.: see
|
|
the Security Notes section.
|
|
confMCI_CACHE_SIZE ConnectionCacheSize
|
|
[2] Size of open connection cache.
|
|
confMCI_CACHE_TIMEOUT ConnectionCacheTimeout
|
|
[5m] Open connection cache timeout.
|
|
confHOST_STATUS_DIRECTORY HostStatusDirectory
|
|
[undefined] If set, host status is kept
|
|
on disk between sendmail runs in the
|
|
named directory tree. This need not be
|
|
a full pathname, in which case it is
|
|
interpreted relative to the queue
|
|
directory.
|
|
confSINGLE_THREAD_DELIVERY SingleThreadDelivery
|
|
[False] If this option and the
|
|
HostStatusDirectory option are both
|
|
set, single thread deliveries to other
|
|
hosts. That is, don't allow any two
|
|
sendmails on this host to connect
|
|
simultaneously to any other single
|
|
host. This can slow down delivery in
|
|
some cases, in particular since a
|
|
cached but otherwise idle connection
|
|
to a host will prevent other sendmails
|
|
from connecting to the other host.
|
|
confUSE_ERRORS_TO* UserErrorsTo [False] Use the Errors-To: header to
|
|
deliver error messages. This should
|
|
not be necessary because of general
|
|
acceptance of the envelope/header
|
|
distinction.
|
|
confLOG_LEVEL LogLevel [9] Log level.
|
|
confME_TOO MeToo [False] Include sender in group
|
|
expansions.
|
|
confCHECK_ALIASES CheckAliases [False] Check RHS of aliases when
|
|
running newaliases. Since this does
|
|
DNS lookups on every address, it can
|
|
slow down the alias rebuild process
|
|
considerably on large alias files.
|
|
confOLD_STYLE_HEADERS* OldStyleHeaders [True] Assume that headers without
|
|
special chars are old style.
|
|
confDAEMON_OPTIONS DaemonPortOptions
|
|
[none] SMTP daemon options.
|
|
confPRIVACY_FLAGS PrivacyOptions [authwarnings] Privacy flags.
|
|
confCOPY_ERRORS_TO PostmasterCopy [undefined] Address for additional
|
|
copies of all error messages.
|
|
confQUEUE_FACTOR QueueFactor [600000] Slope of queue-only function.
|
|
confDONT_PRUNE_ROUTES DontPruneRoutes [False] Don't prune down route-addr
|
|
syntax addresses to the minimum
|
|
possible.
|
|
confSAFE_QUEUE* SuperSafe [True] Commit all messages to disk
|
|
before forking.
|
|
confTO_INITIAL Timeout.initial [5m] The timeout waiting for a response
|
|
on the initial connect.
|
|
confTO_CONNECT Timeout.connect [0] The timeout waiting for an initial
|
|
connect() to complete. This can only
|
|
shorten connection timeouts; the kernel
|
|
silently enforces an absolute maximum
|
|
(which varies depending on the system).
|
|
confTO_ICONNECT Timeout.iconnect
|
|
[undefined] Like Timeout.connect, but
|
|
applies only to the very first attempt
|
|
to connect to a host in a message.
|
|
This allows a single very fast pass
|
|
followed by more careful delivery
|
|
attempts in the future.
|
|
confTO_HELO Timeout.helo [5m] The timeout waiting for a response
|
|
to a HELO or EHLO command.
|
|
confTO_MAIL Timeout.mail [10m] The timeout waiting for a
|
|
response to the MAIL command.
|
|
confTO_RCPT Timeout.rcpt [1h] The timeout waiting for a response
|
|
to the RCPT command.
|
|
confTO_DATAINIT Timeout.datainit
|
|
[5m] The timeout waiting for a 354
|
|
response from the DATA command.
|
|
confTO_DATABLOCK Timeout.datablock
|
|
[1h] The timeout waiting for a block
|
|
during DATA phase.
|
|
confTO_DATAFINAL Timeout.datafinal
|
|
[1h] The timeout waiting for a response
|
|
to the final "." that terminates a
|
|
message.
|
|
confTO_RSET Timeout.rset [5m] The timeout waiting for a response
|
|
to the RSET command.
|
|
confTO_QUIT Timeout.quit [2m] The timeout waiting for a response
|
|
to the QUIT command.
|
|
confTO_MISC Timeout.misc [2m] The timeout waiting for a response
|
|
to other SMTP commands.
|
|
confTO_COMMAND Timeout.command [1h] In server SMTP, the timeout waiting
|
|
for a command to be issued.
|
|
confTO_IDENT Timeout.ident [30s] The timeout waiting for a response
|
|
to an IDENT query.
|
|
confTO_FILEOPEN Timeout.fileopen
|
|
[60s] The timeout waiting for a file
|
|
(e.g., :include: file) to be opened.
|
|
confTO_QUEUERETURN Timeout.queuereturn
|
|
[5d] The timeout before a message is
|
|
returned as undeliverable.
|
|
confTO_QUEUERETURN_NORMAL
|
|
Timeout.queuereturn.normal
|
|
[undefined] As above, for normal
|
|
priority messages.
|
|
confTO_QUEUERETURN_URGENT
|
|
Timeout.queuereturn.urgent
|
|
[undefined] As above, for urgent
|
|
priority messages.
|
|
confTO_QUEUERETURN_NONURGENT
|
|
Timeout.queuereturn.non-urgent
|
|
[undefined] As above, for non-urgent
|
|
(low) priority messages.
|
|
confTO_QUEUEWARN Timeout.queuewarn
|
|
[4h] The timeout before a warning
|
|
message is sent to the sender telling
|
|
them that the message has been deferred.
|
|
confTO_QUEUEWARN_NORMAL Timeout.queuewarn.normal
|
|
[undefined] As above, for normal
|
|
priority messages.
|
|
confTO_QUEUEWARN_URGENT Timeout.queuewarn.urgent
|
|
[undefined] As above, for urgent
|
|
priority messages.
|
|
confTO_QUEUEWARN_NONURGENT
|
|
Timeout.queuewarn.non-urgent
|
|
[undefined] As above, for non-urgent
|
|
(low) priority messages.
|
|
confTO_HOSTSTATUS Timeout.hoststatus
|
|
[30m] How long information about host
|
|
statuses will be maintained before it
|
|
is considered stale and the host should
|
|
be retried. This applies both within
|
|
a single queue run and to persistent
|
|
information (see below).
|
|
confTIME_ZONE TimeZoneSpec [USE_SYSTEM] Time zone info -- can be
|
|
USE_SYSTEM to use the system's idea,
|
|
USE_TZ to use the user's TZ envariable,
|
|
or something else to force that value.
|
|
confDEF_USER_ID DefaultUser [1:1] Default user id.
|
|
confUSERDB_SPEC UserDatabaseSpec
|
|
[undefined] User database specification.
|
|
confFALLBACK_MX FallbackMXhost [undefined] Fallback MX host.
|
|
confTRY_NULL_MX_LIST TryNullMXList [False] If we are the best MX for a
|
|
host and haven't made other
|
|
arrangements, try connecting to the
|
|
host directly; normally this would be
|
|
a config error.
|
|
confQUEUE_LA QueueLA [8] Load average at which queue-only
|
|
function kicks in.
|
|
confREFUSE_LA RefuseLA [12] Load average at which incoming
|
|
SMTP connections are refused.
|
|
confMAX_DAEMON_CHILDREN MaxDaemonChildren
|
|
[undefined] The maximum number of
|
|
children the daemon will permit. After
|
|
this number, connections will be
|
|
rejected. If not set or <= 0, there is
|
|
no limit.
|
|
confCONNECTION_RATE_THROTTLE ConnectionRateThrottle
|
|
[undefined] The maximum number of
|
|
connections permitted per second.
|
|
After this many connections are
|
|
accepted, further connections will be
|
|
delayed. If not set or <= 0, there is
|
|
no limit.
|
|
confWORK_RECIPIENT_FACTOR
|
|
RecipientFactor [30000] Cost of each recipient.
|
|
confSEPARATE_PROC ForkEachJob [False] Run all deliveries in a separate
|
|
process.
|
|
confWORK_CLASS_FACTOR ClassFactor [1800] Priority multiplier for class.
|
|
confWORK_TIME_FACTOR RetryFactor [90000] Cost of each delivery attempt.
|
|
confQUEUE_SORT_ORDER QueueSortOrder [Priority] Queue sort algorithm:
|
|
Priority, Host, or Time.
|
|
confMIN_QUEUE_AGE MinQueueAge [0] The minimum amount of time a job
|
|
must sit in the queue between queue
|
|
runs. This allows you to set the
|
|
queue run interval low for better
|
|
responsiveness without trying all
|
|
jobs in each run.
|
|
confDEF_CHAR_SET DefaultCharSet [unknown-8bit] When converting
|
|
unlabeled 8 bit input to MIME, the
|
|
character set to use by default.
|
|
confSERVICE_SWITCH_FILE ServiceSwitchFile
|
|
[/etc/service.switch] The file to use
|
|
for the service switch on systems that
|
|
do not have a system-defined switch.
|
|
confHOSTS_FILE HostsFile [/etc/hosts] The file to use when doing
|
|
"file" type access of hosts names.
|
|
confDIAL_DELAY DialDelay [0s] If a connection fails, wait this
|
|
long and try again. Zero means "don't
|
|
retry". This is to allow "dial on
|
|
demand" connections to have enough time
|
|
to complete a connection.
|
|
confNO_RCPT_ACTION NoRecipientAction
|
|
[none] What to do if there are no legal
|
|
recipient fields (To:, Cc: or Bcc:)
|
|
in the message. Legal values can
|
|
be "none" to just leave the
|
|
nonconforming message as is, "add-to"
|
|
to add a To: header with all the
|
|
known recipients (which may expose
|
|
blind recipients), "add-apparently-to"
|
|
to do the same but use Apparently-To:
|
|
instead of To:, "add-bcc" to add an
|
|
empty Bcc: header, or
|
|
"add-to-undisclosed" to add the header
|
|
``To: undisclosed-recipients:;''.
|
|
confSAFE_FILE_ENV SafeFileEnvironment
|
|
[undefined] If set, sendmail will do a
|
|
chroot() into this directory before
|
|
writing files.
|
|
confCOLON_OK_IN_ADDR ColonOkInAddr [True unless Configuration Level > 6]
|
|
If set, colons are treated as a regular
|
|
character in addresses. If not set,
|
|
they are treated as the introducer to
|
|
the RFC 822 "group" syntax. Colons are
|
|
handled properly in route-addrs. This
|
|
option defaults on for V5 and lower
|
|
configuration files.
|
|
confMAX_QUEUE_RUN_SIZE MaxQueueRunSize [0] If set, limit the maximum size of
|
|
any given queue run to this number of
|
|
entries. Essentially, this will stop
|
|
reading the queue directory after this
|
|
number of entries are reached; it does
|
|
_not_ pick the highest priority jobs,
|
|
so this should be as large as your
|
|
system can tolerate. If not set, there
|
|
is no limit.
|
|
confDONT_EXPAND_CNAMES DontExpandCnames
|
|
[False] If set, $[ ... $] lookups that
|
|
do DNS based lookups do not expand
|
|
CNAME records. This currently violates
|
|
the published standards, but the IETF
|
|
seems to be moving toward legalizing
|
|
this. For example, if "FTP.Foo.ORG"
|
|
is a CNAME for "Cruft.Foo.ORG", then
|
|
with this option set a lookup of
|
|
"FTP" will return "FTP.Foo.ORG"; if
|
|
clear it returns "Cruft.FOO.ORG". N.B.
|
|
you may not see any effect until your
|
|
downstream neighbors stop doing CNAME
|
|
lookups as well.
|
|
confFROM_LINE UnixFromLine [From $g $d] The From_ line used
|
|
when sending to files or programs.
|
|
confSINGLE_LINE_FROM_HEADER SingleLineFromHeader
|
|
[False] From: lines that have
|
|
embedded newlines are unwrapped
|
|
onto one line.
|
|
confALLOW_BOGUS_HELO AllowBogusHELO [False] Allow HELO SMTP command that
|
|
does not include a host name.
|
|
confMUST_QUOTE_CHARS MustQuoteChars [.'] Characters to be quoted in a full
|
|
name phrase (@,;:\()[] are automatic).
|
|
confOPERATORS OperatorChars [.:%@!^/[]+] Address operator
|
|
characters.
|
|
confSMTP_LOGIN_MSG SmtpGreetingMessage
|
|
[$j Sendmail $v/$Z; $b]
|
|
The initial (spontaneous) SMTP
|
|
greeting message. The word "ESMTP"
|
|
will be inserted between the first and
|
|
second words to convince other
|
|
sendmails to try to speak ESMTP.
|
|
confDONT_INIT_GROUPS DontInitGroups [False] If set, the initgroups(3)
|
|
routine will never be invoked. You
|
|
might want to do this if you are
|
|
running NIS and you have a large group
|
|
map, since this call does a sequential
|
|
scan of the map; in a large site this
|
|
can cause your ypserv to run
|
|
essentially full time. If you set
|
|
this, agents run on behalf of users
|
|
will only have their primary
|
|
(/etc/passwd) group permissions.
|
|
confUNSAFE_GROUP_WRITES UnsafeGroupWrites
|
|
[False] If set, group-writable
|
|
:include: and .forward files are
|
|
considered "unsafe", that is, programs
|
|
and files cannot be directly referenced
|
|
from such files. World-writable files
|
|
are always considered unsafe.
|
|
confDOUBLE_BOUNCE_ADDRESS DoubleBounceAddress
|
|
[postmaster] If an error occurs when
|
|
sending an error message, send that
|
|
"double bounce" error message to this
|
|
address.
|
|
confRUN_AS_USER RunAsUser [undefined] If set, become this user
|
|
when reading and delivering mail.
|
|
Causes all file reads (e.g., .forward
|
|
and :include: files) to be done as
|
|
this user. Also, all programs will
|
|
be run as this user, and all output
|
|
files will be written as this user.
|
|
Intended for use only on firewalls
|
|
where users do not have accounts.
|
|
confMAX_RCPTS_PER_MESSAGE MaxRecipientsPerMessage
|
|
[infinite] If set, allow no more than
|
|
the specified number of recipients in
|
|
an SMTP envelope. Further recipients
|
|
receive a 452 error code (i.e., they
|
|
are deferred for the next delivery
|
|
attempt).
|
|
confDONT_PROBE_INTERFACES DontProbeInterfaces
|
|
[False] If set, sendmail will _not_
|
|
insert the names and addresses of any
|
|
local interfaces into the $=w class
|
|
(list of known "equivalent" addresses).
|
|
If you set this, you must also include
|
|
some support for these addresses (e.g.,
|
|
in a mailertable entry) -- otherwise,
|
|
mail to addresses in this list will
|
|
bounce with a configuration error.
|
|
confDONT_BLAME_SENDMAIL DontBlameSendmail
|
|
[safe] Override sendmail's file
|
|
safety checks. This will definitely
|
|
compromise system security and should
|
|
not be used unless absolutely
|
|
necessary.
|
|
confREJECT_MSG - [550 Access denied] The message
|
|
given if the access database contains
|
|
REJECT in the value portion.
|
|
|
|
See also the description of OSTYPE for some parameters that can be
|
|
tweaked (generally pathnames to mailers).
|
|
|
|
|
|
+-----------+
|
|
| HIERARCHY |
|
|
+-----------+
|
|
|
|
Within this directory are several subdirectories, to wit:
|
|
|
|
m4 General support routines. These are typically
|
|
very important and should not be changed without
|
|
very careful consideration.
|
|
|
|
cf The configuration files themselves. They have
|
|
".mc" suffixes, and must be run through m4 to
|
|
become complete. The resulting output should
|
|
have a ".cf" suffix.
|
|
|
|
ostype Definitions describing a particular operating
|
|
system type. These should always be referenced
|
|
using the OSTYPE macro in the .mc file. Examples
|
|
include "bsd4.3", "bsd4.4", "sunos3.5", and
|
|
"sunos4.1".
|
|
|
|
domain Definitions describing a particular domain, referenced
|
|
using the DOMAIN macro in the .mc file. These are
|
|
site dependent; for example, "CS.Berkeley.EDU.m4"
|
|
describes hosts in the CS.Berkeley.EDU subdomain.
|
|
|
|
mailer Descriptions of mailers. These are referenced using
|
|
the MAILER macro in the .mc file.
|
|
|
|
sh Shell files used when building the .cf file from the
|
|
.mc file in the cf subdirectory.
|
|
|
|
feature These hold special orthogonal features that you might
|
|
want to include. They should be referenced using
|
|
the FEATURE macro.
|
|
|
|
hack Local hacks. These can be referenced using the HACK
|
|
macro. They shouldn't be of more than voyeuristic
|
|
interest outside the .Berkeley.EDU domain, but who knows?
|
|
We've all got our own peccadillos.
|
|
|
|
siteconfig Site configuration -- e.g., tables of locally connected
|
|
UUCP sites.
|
|
|
|
|
|
+------------------------+
|
|
| ADMINISTRATIVE DETAILS |
|
|
+------------------------+
|
|
|
|
The following sections detail usage of certain internal parts of the
|
|
sendmail.cf file. Read them carefully if you are trying to modify
|
|
the current model. If you find the above descriptions adequate, these
|
|
should be {boring, confusing, tedious, ridiculous} (pick one or more).
|
|
|
|
RULESETS (* means built in to sendmail)
|
|
|
|
0 * Parsing
|
|
1 * Sender rewriting
|
|
2 * Recipient rewriting
|
|
3 * Canonicalization
|
|
4 * Post cleanup
|
|
5 * Local address rewrite (after aliasing)
|
|
1x mailer rules (sender qualification)
|
|
2x mailer rules (recipient qualification)
|
|
3x mailer rules (sender header qualification)
|
|
4x mailer rules (recipient header qualification)
|
|
5x mailer subroutines (general)
|
|
6x mailer subroutines (general)
|
|
7x mailer subroutines (general)
|
|
8x reserved
|
|
90 Mailertable host stripping
|
|
96 Bottom half of Ruleset 3 (ruleset 6 in old sendmail)
|
|
97 Hook for recursive ruleset 0 call (ruleset 7 in old sendmail)
|
|
98 Local part of ruleset 0 (ruleset 8 in old sendmail)
|
|
99 Guaranteed null (for debugging)
|
|
|
|
|
|
MAILERS
|
|
|
|
0 local, prog local and program mailers
|
|
1 [e]smtp, relay SMTP channel
|
|
2 uucp-* UNIX-to-UNIX Copy Program
|
|
3 netnews Network News delivery
|
|
4 fax Sam Leffler's HylaFAX software
|
|
5 mail11 DECnet mailer
|
|
|
|
|
|
MACROS
|
|
|
|
A
|
|
B Bitnet Relay
|
|
C DECnet Relay
|
|
D The local domain -- usually not needed
|
|
E reserved for X.400 Relay
|
|
F FAX Relay
|
|
G
|
|
H mail Hub (for mail clusters)
|
|
I
|
|
J
|
|
K
|
|
L Luser Relay
|
|
M Masquerade (who I claim to be)
|
|
N
|
|
O
|
|
P
|
|
Q
|
|
R Relay (for unqualified names)
|
|
S Smart Host
|
|
T
|
|
U my UUCP name (if I have a UUCP connection)
|
|
V UUCP Relay (class V hosts)
|
|
W UUCP Relay (class W hosts)
|
|
X UUCP Relay (class X hosts)
|
|
Y UUCP Relay (all other hosts)
|
|
Z Version number
|
|
|
|
|
|
CLASSES
|
|
|
|
A
|
|
B domains that are candidates for bestmx lookup
|
|
C
|
|
D
|
|
E addresses that should not seem to come from $M
|
|
F hosts we forward for
|
|
G domains that should be looked up in genericstable
|
|
H
|
|
I
|
|
J
|
|
K
|
|
L addresses that should not be forwarded to $R
|
|
M domains that should be mapped to $M
|
|
N
|
|
O operators that indicate network operations (cannot be in local names)
|
|
P top level pseudo-domains: BITNET, DECNET, FAX, UUCP, etc.
|
|
Q
|
|
R domains we are willing to relay (pass anti-spam filters)
|
|
S
|
|
T
|
|
U locally connected UUCP hosts
|
|
V UUCP hosts connected to relay $V
|
|
W UUCP hosts connected to relay $W
|
|
X UUCP hosts connected to relay $X
|
|
Y locally connected smart UUCP hosts
|
|
Z locally connected domain-ized UUCP hosts
|
|
. the class containing only a dot
|
|
[ the class containing only a left bracket
|
|
|
|
|
|
M4 DIVERSIONS
|
|
|
|
1 Local host detection and resolution
|
|
2 Local Ruleset 3 additions
|
|
3 Local Ruleset 0 additions
|
|
4 UUCP Ruleset 0 additions
|
|
5 locally interpreted names (overrides $R)
|
|
6 local configuration (at top of file)
|
|
7 mailer definitions
|
|
8
|
|
9 special local rulesets (1 and 2)
|