README
上传用户:xu_441
上传日期:2007-01-04
资源大小:1640k
文件大小:114k
- SENDMAIL CONFIGURATION FILES
- This document describes the sendmail configuration files. This package
- requires a post-V7 version of m4; if you are running the 4.2bsd, SysV.2, or
- 7th Edition version. SunOS's /usr/5bin/m4 or BSD-Net/2's m4 both work.
- GNU m4 version 1.1 or later also works. Unfortunately, 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
- latset version). EXCEPTIONS: DEC's m4 on Digital UNIX 4.x is broken (3.x
- is fine). Use GNU m4 on this platform.
- 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 previously used at
- Berkeley. For example, ucbvax has gone away, but ucbvax.mc demonstrates
- some interesting techniques.
- *******************************************************************
- *** BE SURE YOU CUSTOMIZE THESE FILES! They have some ***
- *** Berkeley-specific assumptions built in, such as the name ***
- *** of their 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
- Alternatively, you can simply:
- cd ${CFDIR}/cf
- ./Build 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, 1999 Sendmail, Inc. and its suppliers.
- # 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 is included in these 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. You could use SCCS, RCS, CVS, 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. 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(`procmail'), and
- MAILER(`uucp'). The general rules are that the order should be:
- VERSIONID
- OSTYPE
- DOMAIN
- FEATURE
- local macro definitions
- MAILER
- LOCAL_RULE_*
- LOCAL_RULESETS
- There are a few exceptions to this rule. Local macro definitions which
- influence a FEATURE() should be done before that feature. For example,
- a define(`PROCMAIL_MAILER_PATH', ...) should be done before
- FEATURE(`local_procmail').
- +----------------------------+
- | 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. Beginning with
- 8.10, all files will use this directory by default (some options may be
- set by OSTYPE() files). This new directory should help to restore
- uniformity to sendmail's file locations.
- Below is a table of some of the common changes:
- Old filename New filename
- ------------ ------------
- /etc/bitdomain /etc/mail/bitdomain
- /etc/domaintable /etc/mail/domaintable
- /etc/genericstable /etc/mail/genericstable
- /etc/uudomain /etc/mail/uudomain
- /etc/virtusertable /etc/mail/virtusertable
- /etc/userdb /etc/mail/userdb
- /etc/aliases /etc/mail/aliases
- /etc/sendmail/aliases /etc/mail/aliases
- /etc/ucbmail/aliases /etc/mail/aliases
- /usr/adm/sendmail/aliases /etc/mail/aliases
- /usr/lib/aliases /etc/mail/aliases
- /usr/lib/mail/aliases /etc/mail/aliases
- /usr/ucblib/aliases /etc/mail/aliases
- /etc/sendmail.cw /etc/mail/local-host-names
- /etc/mail/sendmail.cw /etc/mail/local-host-names
- /etc/sendmail/sendmail.cw /etc/mail/local-host-names
- /etc/sendmail.ct /etc/mail/trusted-users
- /etc/sendmail.oE /etc/mail/error-header
- /etc/sendmail.hf /etc/mail/helpfile
- /etc/mail/sendmail.hf /etc/mail/helpfile
- /usr/ucblib/sendmail.hf /etc/mail/helpfile
- /etc/ucbmail/sendmail.hf /etc/mail/helpfile
- /usr/lib/sendmail.hf /etc/mail/helpfile
- /usr/share/lib/sendmail.hf /etc/mail/helpfile
- /usr/share/misc/sendmail.hf /etc/mail/helpfile
- /share/misc/sendmail.hf /etc/mail/helpfile
- /etc/service.switch /etc/mail/service.switch
- /etc/sendmail.st /etc/mail/statistics
- /etc/mail/sendmail.st /etc/mail/statistics
- /etc/mailer/sendmail.st /etc/mail/statistics
- /etc/sendmail/sendmail.st /etc/mail/statistics
- /usr/lib/sendmail.st /etc/mail/statistics
- /usr/ucblib/sendmail.st /etc/mail/statistics
- Note that all of these paths actually use a new m4 macro MAIL_SETTINGS_DIR
- to create the pathnames. The default value of this variable is
- `/etc/mail/'. If you set this macro to a different value, you MUST include
- a trailing slash.
- +--------+
- | 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/mail/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 [/etc/mail/helpfile] 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. To use multiple queues, supply
- a value ending with an asterisk. For
- example, /var/spool/mqueue/q* will use all of the
- directories or symbolic links to directories
- beginning with 'q' in /var/spool/mqueue as queue
- directories.
- STATUS_FILE [/etc/mail/statistics] The file containing status
- information.
- LOCAL_MAILER_PATH [/bin/mail] The program used to deliver local mail.
- LOCAL_MAILER_FLAGS [Prmn9] The flags used by the local mailer. The
- flags lsDFMAw5:/|@q 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_MAXMSGS [undefined] If defined, the maximum number of
- messages to deliver in a single connection. Only
- useful for LMTP local mailers.
- 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_MAILER_EOL [undefined] If defined, the string to use as the
- end of line for the local mailer.
- LOCAL_MAILER_DSN_DIAGNOSTIC_CODE
- [X-Unix] The DSN Diagnostic-Code value for the
- local mailer. This should be changed with care.
- 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 [rsDFMmn] 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'; "smtp8" adds `8'; and
- "dsmtp" adds `%'.
- RELAY_MAILER_FLAGS [undefined] Flags added to the relay mailer. Default
- flags are `mDFMuX' for all SMTP-based mailers; the
- relay mailer adds `a8'.
- SMTP_MAILER_MAX [undefined] The maximum size of messages that will
- be transported using the smtp, smtp8, esmtp, or dsmtp
- mailers.
- SMTP_MAILER_MAXMSGS [undefined] If defined, the maximum number of
- messages to deliver in a single connection for the
- smtp, smtp8, esmtp, or dsmtp 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.
- DSMTP_MAILER_ARGS [IPC $h] The arguments passed to the dsmtp mailer.
- RELAY_MAILER_ARGS [IPC $h] The arguments passed to the relay mailer.
- RELAY_MAILER_MAXMSGS [undefined] If defined, the maximum number of
- messages to deliver in a single connection for 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 lsDFMq
- 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. Flags nrDFM
- are always set.
- PH_MAILER_ARGS [phquery -- $u] -- arguments to the phquery mailer.
- CYRUS_MAILER_FLAGS [Ah5@/:|] 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 [u] 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').
- QPAGE_MAILER_FLAGS [mDFMs] The flags used by the qpage mailer.
- QPAGE_MAILER_PATH [/usr/local/bin/qpage] The program used to deliver
- qpage mail.
- QPAGE_MAILER_ARGS [qpage -l0 -m -P$u] The arguments passed
- to deliver qpage mail.
- QPAGE_MAILER_MAX [4096] If set, the maximum size message that
- will be accepted by the qpage mailer.
- Note: to tweak Name_MAILER_FLAGS use the macro MODIFY_MAILER_FLAGS:
- MODIFY_MAILER_FLAGS(`Name', `change') where Name is the first part of
- the macro Name_MAILER_FLAGS and change can be: flags that should
- be used directly (thus overriding the default value), or if it
- starts with `+' (`-') then those flags are added to (removed from)
- the default value. Example:
- MODIFY_MAILER_FLAGS(`LOCAL', `+e')
- will add the flag `e' to LOCAL_MAILER_FLAGS.
- WARNING: The FEATUREs local_lmtp and local_procmail set LOCAL_MAILER_FLAGS
- unconditionally, i.e., without respecting any definitions in an
- OSTYPE setting.
- +---------+
- | DOMAINS |
- +---------+
- You will probably want to collect domain-dependent defines into one
- file, referenced by the DOMAIN macro. For example, the 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') and MAILER(`procmail') -- several features and
- definitions will modify the definition of mailers, and the smtp mailer
- modifies the UUCP mailer. Moreover, MAILER(`cyrus'), MAILER(`pop'),
- MAILER(`phquery'), and MAILER(`usenet') must be defined after
- MAILER(`local').
- 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
- five 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), "dsmtp" to do on
- demand delivery, and "relay" for transmission to the
- RELAY_HOST, LUSER_RELAY, or MAIL_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 cyrus mailer must be
- defined after the local mailer.
- qpage A mailer for QuickPage, a pager interface. See
- http://www.qpage.org/ for further information.
- 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/mail/local-host-names
- file to get values for class $=w. The FEATURE may contain up to 9
- optional parameters -- 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. It must be specified before any
- feature that uses a map.
- Available features are:
- use_cw_file Read the file /etc/mail/local-host-names 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/mail/trusted-users 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 route UUCP addresses. This feature takes one
- parameter:
- `reject': reject addresses which have "!" in the local
- part unless it originates from a system
- that is allowed to relay.
- `nospecial': don't do anything special with "!".
- Warnings: 1. See the NOTICE in the ANTI-SPAM section.
- 2. don't remove "!" from OperatorChars if `reject' is
- given as parameter.
- nocanonify Don't pass addresses to $[ ... $] for canonification
- by default. It can be changed by setting the
- DaemonPortOptions modifiers (M=). That is,
- FEATURE(`nocanonify') will be overridden by setting the
- 'c' flag. Conversely, if FEATURE(`nocanonify') is not used,
- it can be emulated by setting the 'C' flag
- (DaemonPortOptions=Modifiers=C). 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.
- An exception list for FEATURE(`nocanonify') can be
- specified with CANONIFY_DOMAIN or CANONIFY_DOMAIN_FILE,
- i.e., a list of domains which are nevertheless passed to
- $[ ... $] for canonification. This is useful to turn on
- canonification for local domains, e.g., use
- CANONIFY_DOMAIN(`my.domain my') to canonify addresses
- which end in "my.domain" or "my".
- Another way to require canonification in the local
- domain is CANONIFY_DOMAIN(`$=m').
- A trailing dot is added to addresses with more than
- one component in it such that other features which
- expect a trailing dot (e.g., virtusertable) will
- still work.
- If `canonify_hosts' is specified as parameter, i.e.,
- FEATURE(`nocanonify', `canonify_hosts'), then
- addresses which have only a hostname, e.g.,
- <user@host>, will be canonified (and hopefully fully
- qualified), too.
- 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 (which are not in $=w, i.e.
- local host names). The argument of the FEATURE may be the
- key definition. If none is specified, the definition used
- is:
- hash /etc/mail/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". As a
- special case of the latter, "." matches any domain not
- covered by other keys. 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
- error:D.S.N:code message
- will give an error message with the indicated SMTP reply
- code and message, where D.S.N is an RFC 1893 compliant
- error code.
- 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 /etc/mail/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 /etc/mail/bitdomain
- Keys are the bitnet hostname; values are the corresponding
- internet hostname.
- uucpdomain Similar feature for UUCP hosts. The default map definition
- is:
- hash /etc/mail/uudomain
- 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 /etc/mail/genericstable
- The key for this table is either the full address, the domain
- (with a leading @; the localpart is passed as first argument)
- or the unqualified username (tried in the order mentioned);
- 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.
- The "+detail" of an address is passed as %1, so entries like
- old+*@foo.org new+%1@elsewhere.com
- gen+*@foo.org %1@elsewhere.com
- and other forms are possible.
- generics_entire_domain
- If the genericstable is enabled and GENERICS_DOMAIN or
- GENERICS_DOMAIN_FILE is used, this feature will cause
- addresses to be searched in the map if their domain
- parts are subdomains of elements in class $=G.
- 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
- joe@bar.com error:nouser No such user here
- jax@bar.com error:D.S.N:unavailable Address invalid
- @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, mail to joe@bar.com will
- be rejected with the specified error message, and mail to
- jax@bar.com will also have a RFC 1893 compliant error code
- D.S.N.
- 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.
- Additionally, if the local part consists of "user+detail"
- then "detail" is passed as %2 when a match against user+*
- is attempted, so entries like
- old+*@foo.org new+%2@elsewhere.com
- gen+*@foo.org %2@elsewhere.com
- and other forms are possible.
- All the host names on the left hand side (foo.com, bar.com,
- and baz.org) must be in $=w or $={VirtHost}, the latter can
- be defined by the macros VIRTUSER_DOMAIN or
- VIRTUSER_DOMAIN_FILE (analogously to MASQUERADE_DOMAIN and
- MASQUERADE_DOMAIN_FILE, see below). If VIRTUSER_DOMAIN or
- VIRTUSER_DOMAIN_FILE is used, then the entries of $={VirtHost}
- are added to class 'R', i.e., relaying is allowed to
- (and from) those domains. The default map definition is:
- hash /etc/mail/virtusertable
- A new definition can be specified as the second argument of
- the FEATURE macro, such as
- FEATURE(`virtusertable', `dbm /etc/mail/virtusers')
- virtuser_entire_domain
- If the virtusertable is enabled and VIRTUSER_DOMAIN or
- VIRTUSER_DOMAIN_FILE is used, this feature will cause
- addresses to be searched in the map if their domain
- parts are subdomains of elements in class $={VirtHost}.
- ldap_routing Implement LDAP-based e-mail recipient routing according to
- the Internet Draft draft-lachman-laser-ldap-mail-routing-01.
- This provides a method to re-route addresses with a
- domain portion in the $={LDAPRoute} class to either a
- different mail host or a different address. Hosts can
- be added to this class using LDAPROUTE_DOMAIN and
- LDAPROUTE_DOMAIN_FILE (analogously to MASQUERADE_DOMAIN and
- MASQUERADE_DOMAIN_FILE, see below).
- See the LDAP ROUTING section below for more information.
- nodns If you aren't running DNS at your site (for example,
- you 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 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.
- 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.
- WARNING: This feature sets LOCAL_MAILER_FLAGS unconditionally,
- i.e., without respecting any definitions in an OSTYPE setting.
- local_procmail Use procmail or another delivery agent as the local mailer.
- The argument to this feature is the pathname of the
- delivery agent, 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, or
- specify the appropriate parameters. When procmail is used,
- the local 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.
- This feature can take up to three arguments:
- 1. Path to the mailer program
- [default: /usr/local/bin/procmail]
- 2. Argument vector including name of the program
- [default: procmail -Y -a $h -d $u]
- 3. Flags for the mailer [default: SPfhn9]
- Empty arguments cause the defaults to be taken.
- For example, this allows it to use the maildrop
- (http://www.flounder.net/~mrsam/maildrop/) mailer instead
- by specifying:
- FEATURE(`local_procmail', `/usr/local/bin/maildrop',
- `maildrop -d $u')
- or scanmails using:
- FEATURE(`local_procmail', `/usr/local/bin/scanmails')
- WARNING: This feature sets LOCAL_MAILER_FLAGS unconditionally,
- i.e., without respecting any definitions in an OSTYPE setting.
- 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_mail_from
- Allows relaying if the mail sender is listed as RELAY in the
- access map. If an optional argument `domain' is given, the
- domain portion of the mail sender is checked too. This
- should only be used if absolutely necessary as the sender
- address can be easily forged.
- 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. Setting the DaemonPortOptions modifier
- 'u' overrides the default behavior, i.e., unqualified
- addresses are accepted even without this FEATURE.
- If this FEATURE is not used, the DaemonPortOptions modifier
- 'f' can be used to enforce fully qualified 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., an A or
- MX record in 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 /etc/mail/access
- The format of the database is described in the anti-spam
- configuration control section later in this document.
- 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 in the anti-spam configuration control section
- later in this document.
- rbl This feature is deprecated! Please use dnsbl instead.
- Turns on rejection of hosts found in the Realtime Blackhole
- List. If an argument is provided it is used as the
- name server to contact; otherwise, the main RBL server at
- rbl.maps.vix.com is used. For details, see
- http://maps.vix.com/rbl/.
- dnsbl Turns on rejection of hosts found in an DNS based rejection
- list. If an argument is provided it is used as the name
- sever to contact; otherwise it defaults to rbl.maps.vix.com.
- An explanation for an DNS based rejection list can be found
- http://maps.vix.com/rbl/. A second argument can be used to
- change the default error message of
- Mail from $&{client_addr} refused by blackhole site SERVER
- where SERVER is replaced by the first argument. This feature
- can be included several times to query different DNS based
- rejection lists.
- loose_relay_check
- Normally, if % addressing is used for a recipient, 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.
- no_msa Don't generate the default MSA daemon, i.e.,
- DAEMON_OPTIONS(`Port=587,Name=MSA,M=E')
- +-------+
- | 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 moving 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/mail/local-host-names containing a list of your aliases (one per
- line), and use ``FEATURE(`use_cw_file')'' in the .mc file, or add
- ``LOCAL_DOMAIN(`alias.host.name')''. 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 this
- out-of-date configuration file has been left 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:
- 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. Do not declare rulesets in
- the LOCAL_CONFIG section. It can be used to declare local database maps or
- whatever. For example:
- LOCAL_CONFIG
- Khostmap hash /etc/mail/hostmap
- 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
- Berkeley 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.
- To exempt hosts or subdomains from being masqueraded, you can use
- MASQUERADE_EXCEPTION(`host.domain')
- This can come handy if you want to masquerade a whole domain
- except for one (or a few) host(s).
- 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 (which has been "exposed" by default prior to 8.10).
- 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/mail/exposed-users
- 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/mail/local-users
- 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 or
- bracketed addresses (e.g., "eric@mastodon.CS.Berkeley.EDU"
- or "eric@[127.0.0.1]").
- 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 ---^
- +--------------+
- | LDAP ROUTING |
- +--------------+
- FEATURE(`ldap_routing') can be used to implement the IETF Internet Draft
- LDAP Schema for Intranet Mail Routing
- (draft-lachman-laser-ldap-mail-routing-01). This feature enables
- LDAP-based rerouting of a particular address to either a different host
- or a different address. The LDAP lookup is first attempted on the full
- address (e.g., user@example.com) and then on the domain portion
- (e.g., @example.com). Be sure to setup your domain for LDAP routing using
- LDAPROUTE_DOMAIN(), e.g.:
- LDAPROUTE_DOMAIN(`example.com')
- By default, the feature will use the schemas as specified in the draft
- and will not reject addresses not found by the LDAP lookup. However,
- this behavior can be changed by giving additional arguments to the FEATURE()
- command:
- FEATURE(`ldap_routing', <mailHost>, <mailRoutingAddress>, <bounce>)
- where <mailHost> is a map definition describing how to lookup an alternative
- mail host for a particular address; <mailRoutingAddress> is a map definition
- describing how to lookup an alternative address for a particular address; and
- the <bounce> argument, if present and not empty, dictates that mail should
- be bounced if neither a mailHost nor mailRoutingAddress is found.
- The default <mailHost> map definition is:
- ldap -1 -v mailHost -k (&(objectClass=inetLocalMailRecipient)
- (mailLocalAddress=%0))
- The default <mailRoutingAddress> map definition is:
- ldap -1 -v mailRoutingAddress -k (&(objectClass=inetLocalMailRecipient)
- (mailLocalAddress=%0))
- Note that neither includes the LDAP server hostname (-h server) or base DN
- (-b o=org,c=COUNTRY), both necessary for LDAP queries. It is presumed that
- your .mc file contains a setting for the confLDAP_DEFAULT_SPEC option with
- these settings. If this is not the case, the map definitions should be
- changed as described above.
- The following possibilities exist as a result of an LDAP lookup on an
- address:
- mailHost is mailRoutingAddress is Results in
- ----------- --------------------- ----------
- set to a set mail delivered to
- "local" host mailRoutingAddress
- set to a not set delivered to
- "local" host original address
- set to a set mailRoutingAddress
- remote host relayed to mailHost
- set to a not set original address
- remote host relayed to mailHost
- not set set mail delivered to
- mailRoutingAddress
- not set not set delivered to
- original address *OR*
- bounced as unknown user
- The term "local" host above means the host specified is in class 'w' ($=w).
- Note that the last case depends on whether the third argument is given
- to the FEATURE() command. The default is to deliver the message to the
- original address.
- The LDAP entries should be set up with an objectClass of
- inetLocalMailRecipient and the address be listed in a mailLocalAddress
- attribute. If present, there must be only one mailHost attribute and it
- must contain a fully qualified host name as its value. Similarly, if
- present, there must be only one mailHost attribute and it must contain an
- RFC822 compliant address. Some example LDAP records (in ldif format):
- dn: uid=tom, o=example.com, c=US
- objectClass: inetLocalMailRecipient
- mailLocalAddress: tom@example.com
- mailRoutingAddress: thomas@mailhost.example.com
- This would deliver mail for tom@example.com to thomas@mailhost.example.com.
- dn: uid=dick, o=example.com, c=US
- objectClass: inetLocalMailRecipient
- mailLocalAddress: dick@example.com
- mailHost: eng.example.com
- This would relay mail for dick@example.com to the same address but redirect
- the mail to MX records listed for the host eng.example.com.
- dn: uid=harry, o=example.com, c=US
- objectClass: inetLocalMailRecipient
- mailLocalAddress: harry@example.com
- mailHost: mktmail.example.com
- mailRoutingAddress: harry@mkt.example.com
- This would relay mail for harry@example.com to the MX records listed for
- the host mktmail.example.com using the new address harry@mkt.example.com
- when talking to that host.
- dn: uid=virtual.example.com, o=example.com, c=US
- objectClass: inetLocalMailRecipient
- mailLocalAddress: @virtual.example.com
- mailHost: server.example.com
- mailRoutingAddress: virtual@example.com
- This would send all mail destined for any username @virtual.example.com to
- the machine server.example.com's MX servers and deliver to the address
- virtual@example.com on that relay machine.
- +---------------------------------+
- | 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.
- A slightly better solution is
- FEATURE(`relay_mail_from')
- which allows relaying if the mail sender is listed as RELAY in the
- access map. If an optional argument `domain' is given, the domain
- portion of the mail sender is also checked to allowing relaying.
- This option only works together with the tag From: for the LHS of
- the access map entries (see below: Finer control...).
- 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.
- NOTICE: It is possible to relay mail through a system which the anti-relay
- rules do not prevent: the case of a system that does use FEATURE(`nouucp',
- `nospecial') (system A) and relays local messages to a mail hub (e.g., via
- LOCAL_RELAY or LUSER_RELAY) (system B). If system B doesn't use
- FEATURE(`nouucp') at all, addresses of the form
- <example.net!user@local.host> would be relayed to <user@example.net>.
- System A doesn't recognize `!' as an address separator and therefore
- forwards it to the mail hub which in turns relays it because it came from
- a trusted local host. So if a mailserver allows UUCP (bang-format)
- addresses, all systems from which it allows relaying should do the same
- or reject those addresses.
- 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')
- Setting the DaemonPortOptions modifier 'u' overrides the default behavior,
- i.e., unqualified addresses are accepted even without this FEATURE. If
- this FEATURE is not used, the DaemonPortOptions modifier 'f' can be used
- to enforce fully qualified addresses.
- 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 /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. For sender addresses it
- indicates that you should discard anything
- received from the indicated domain. If it
- is used for recipients, it affects only
- the designated recipients, not the whole
- message.
- ### any text where ### is an RFC 821 compliant error code
- and "any text" is a message to return for
- the command.
- ERROR:### any text
- as above, but useful to mark error messages as such.
- ERROR:D.S.N:### any text
- where D.S.N is an RFC 1893 compliant error code
- and the rest as above.
- For example:
- cyberspammer.com 550 We don't accept mail from spammers
- okay.cyberspammer.com OK
- sendmail.org RELAY
- 128.32 RELAY
- 1:2:3:4:5:6:7 RELAY
- [127.0.0.3] OK
- [1:2:3:4:5:6:7:8] OK
- 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 relaying mail from and to any hosts in the sendmail.org domain, and
- allow relaying from the 128.32.*.* network and the IPv6 1:2:3:4:5:6:7:*
- network. The latter two entries are for checks against ${client_name} if
- the IP address doesn't resolve to a hostname (or is considered as "may be
- forged").
- Warning: if you change the RFC 821 compliant error code from the default
- value of 550, then you should probably also change the RFC 1893 compliant
- error code to match it. For example, if you use
- user@example.com 450 mailbox full
- the error returned would be "450 4.0.0 mailbox full" which is wrong.
- Use "450 4.2.2 mailbox full" or "ERROR:4.2.2:450 mailbox full"
- instead.
- 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. Please note: a
- local username must be now tagged with an @ (this is consistent
- with the check of the sender address, and hence it is possible to
- distinguish between hostnames and usernames). 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(`dnsbl')
- 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.
- A second argument can be used to change the default error message
- Mail from $&{client_addr} refused by blackhole site SERVER
- where SERVER is replaced by the first argument. This FEATURE can
- be included several times to query different DNS based rejection
- lists, e.g., the dial-up user list (see http://maps.vix.com/dul/).
- 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.
- Finer control by using tags for the LHS of the access map
- Read this section only if the options listed so far are not sufficient
- for your purposes. There is now the option to tag entries in the
- access map according to their type. Three tags are available:
- Connect: connection information (${client_addr}, ${client_name})
- From: sender
- To: recipient
- If the required item is looked up in a map, it will be tried first
- with the corresponding tag in front, then (as fallback to enable
- backward compatibility) without any tag. For example,
- From:spammer@some.dom REJECT
- To:friend.domain RELAY
- Connect:friend.domain OK
- Connect:from.domain RELAY
- From:good@another.dom OK
- From:another.dom REJECT
- This would deny mails from spammer@some.dom but you could still
- send mail to that address even if FEATURE(`blacklist_recipients')
- is enabled. Your system will allow relaying to friend.domain, but
- not from it (unless enabled by other means). Connections from that
- domain will be allowed even if it ends up in one of the DNS based
- rejection lists. Relaying is enabled from from.domain but not to
- it (since relaying is based on the connection information for
- outgoing relaying, the tag Connect: must be used; for incoming
- relaying, which is based on the recipient address, To: must be
- used). The last two entries allow mails from good@another.dom but
- reject mail from all other addresses with another.dom as domain
- part.
- Delay all checks
- By using FEATURE(`delay_checks') the rulesets check_mail and check_relay
- will not be called when a client connects or issues a MAIL command,
- respectively. Instead, those rulesets will be called by the check_rcpt
- ruleset. Moreover, an argument can be specified for this option:
- friend: enable spamfriend test
- hater: enable spamhater test
- If such an argument is given, the recipient will be looked up in the
- access map (using the tag To:). The other rulesets will be skipped
- if:
- friend: recipient is found and has RHS spamfriend
- hater: recipient is not found or has RHS spamhater
- This allows for simple exceptions from the tests, e.g., by activating
- the spamfriend option and having
- To:abuse@ SPAMFRIEND
- in the access map, mail to abuse@localdomain will get through. It is
- also possible to specify a full address or an address with +detail:
- To:abuse@abuse.my.domain SPAMFRIEND
- To:me+abuse@ SPAMFRIEND
- Header Checks
- 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
- The alternative format:
- HSubject: $>+CheckSubject
- that is, $>+ instead of $>, gives the full Subject: header including
- comments to the ruleset (comments in parentheses () are stripped
- by default).
- A default ruleset for headers which don't have a specific ruleset
- defined for them can be given by:
- H*: $>CheckHdr
- After all of the headers are read, the check_eoh ruleset will be called for
- any final header-related checks. The ruleset is called with the number of
- headers and the size of all of the headers in bytes separated by $|. One
- example usage is to reject messages which do not have a Message-Id:
- header. However, the Message-Id: header is *NOT* a required header and is
- not a guaranteed spam indicator. This ruleset is an example and should
- probably not be used in production.
- LOCAL_CONFIG
- Kstorage macro
- LOCAL_RULESETS
- HMessage-Id: $>CheckMessageId
- SCheckMessageId
- # Record the presence of the header
- R$* $: $(storage {MessageIdCheck} $@ OK $) $1
- R< $+ @ $+ > $@ OK
- R$* $#error $: 553 Header Error
- Scheck_eoh
- # Check the macro
- R$* $: < $&{MessageIdCheck} >
- # Clear the macro for the next message
- R$* $: $(storage {MessageIdCheck} $) $1
- # Has a Message-Id: header
- R< $+ > $@ OK
- # Allow missing Message-Id: from local mail
- R$* $: < $&{client_name} >
- R< > $@ OK
- R< $=w > $@ OK
- # Otherwise, reject the mail
- R$* $#error $: 553 Header Error
- +--------------------------------+
- | SMTP AUTHENTICATION |
- +--------------------------------+
- The macros ${auth_authen}, ${auth_author}, and ${auth_type} can be
- used in anti-relay rulesets to allow relaying for those users that
- authenticated themselves. A very simple example is:
- SLocal_check_rcpt
- R$* $: $&{auth_type}
- R$+ $# OK
- which checks whether a user has successfully authenticated using
- any available mechanism. Depending on the setup of the CYRUS SASL
- library, more sophisticated rulesets might be required, e.g.,
- SLocal_check_rcpt
- R$* $: $&{auth_type} $| $&{auth_authen}
- RDIGEST-MD5 $| $+@$=w $# OK
- to allow relaying for users that authenticated using DIGEST-MD5
- and have an identity in the local domains.
- The ruleset Strust_auth is used to determine whether a given AUTH=
- parameter (that is passed to this ruleset) should be trusted. This
- ruleset may make use of the other ${auth_*} macros. Only if the
- ruleset resolves to the error mailer, the AUTH= parameter is not
- trusted. A user supplied ruleset Local_trust_auth can be written
- to modify the default behavior, which only trust the AUTH=
- parameter if it is identical to the authenticated user.
- Per default, relaying is allowed for any user who authenticated
- via a "trusted" mechanism, i.e., one that is defined via
- TRUST_AUTH_MECH(`list of mechanisms')
- +--------------------------------+
- | 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. They may not be 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', `uucp-new: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 uucp-new (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 uucp-new:uuhost1
- .bitnet smtp:relay.bit.net
- This should normally be stored in /etc/mail/mailertable. The actual
- database version of the mailertable is built using:
- makemap hash /etc/mail/mailertable < /etc/mail/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. (it is recommended 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 /etc/mail/userdb < /etc/mail/userdb.txt
- As a general rule, it is an extremely bad idea to using full names
- as e-mail addresses, since they are not in any sense unique. For
- example, the Unix software-development community has 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.
- +--------------------------------+
- | 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".
- +----------------+
- | 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, 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 $.$_)
- $.$?{auth_type}(authenticated as ${auth_authen} $?{auth_author}for ${auth_author} $.with ${auth_type})
- $.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/mail/local-host-names] Name
- of file used to get the local
- additions to the $=w (local host
- names) class.
- confCT_FILE Ft class [/etc/mail/trusted-users] 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').
- confTRUSTED_USER TrustedUser [no default] Trusted user for file
- ownership and starting the daemon.
- Not to be confused with
- confTRUSTED_USERS (see above).
- confSMTP_MAILER - [esmtp] The mailer name used when
- SMTP connectivity is required.
- One of "smtp", "smtp8",
- "esmtp", or "dsmtp".
- 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.
- There is a potential for a denial
- of service attack if this is set.
- This option is deprecated and will
- be removed from a future version.
- 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* UseErrorsTo [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 [True] 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.
- confCLIENT_OPTIONS ClientPortOptions
- [none] Options for outgoing SMTP client
- connections.
- 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_CONTROL Timeout.control
- [2m] The timeout for a complete
- control socket transaction to complete.
- 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).
- confTO_RESOLVER_RETRANS Timeout.resolver.retrans
- [varies] Sets the resolver's
- retransmition time interval (in
- seconds). Sets both
- Timeout.resolver.retrans.first and
- Timeout.resolver.retrans.normal.
- confTO_RESOLVER_RETRANS_FIRST Timeout.resolver.retrans.first
- [varies] Sets the resolver's
- retransmition time interval (in
- seconds) for the first attempt to
- deliver a message.
- confTO_RESOLVER_RETRANS_NORMAL Timeout.resolver.retrans.normal
- [varies] Sets the resolver's
- retransmition time interval (in
- seconds) for all resolver lookups
- except the first delivery attempt.
- confTO_RESOLVER_RETRY Timeout.resolver.retry
- [varies] Sets the number of times
- to retransmit a resolver query.
- Sets both
- Timeout.resolver.retry.first and
- Timeout.resolver.retry.normal.
- confTO_RESOLVER_RETRY_FIRST Timeout.resolver.retry.first
- [varies] Sets the number of times
- to retransmit a resolver query for
- the first attempt to deliver a
- message.
- confTO_RESOLVER_RETRY_NORMAL Timeout.resolver.retry.normal
- [varies] Sets the number of times
- to retransmit a resolver query for
- all resolver lookups except the
- first delivery attempt.
- 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 this host is the best MX
- for a host and other arrangements
- haven't been made, try connecting
- to the host directly; normally this
- would be a config error.
- confQUEUE_LA QueueLA [varies] Load average at which
- queue-only function kicks in.
- Default values is (8 * numproc)
- where numproc is the number of
- processors online (if that can be
- determined).
- confREFUSE_LA RefuseLA [varies] Load average at which
- incoming SMTP connections are
- refused. Default values is (12 *
- numproc) where numproc is the
- number of processors online (if
- that can be determined).
- confMAX_ALIAS_RECURSION MaxAliasRecursion
- [10] Maximum depth of alias recursion.
- 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.
- confMAX_HEADERS_LENGTH MaxHeadersLength
- [undefined] Maximum length of the sum
- of all headers.
- confMAX_MIME_HEADER_LENGTH MaxMimeHeaderLength
- [undefined] Maximum length of
- certain MIME header field values.
- 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, Filename, 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/mail/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 each 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.
- confCONNECT_ONLY_TO ConnectOnlyTo [undefined] override connection
- address (for testing).
- confCONTROL_SOCKET_NAME ControlSocketName
- [undefined] Control socket for daemon
- management.
- confDOUBLE_BOUNCE_ADDRESS DoubleBounceAddress
- [postmaster] If an error occurs when
- sending an error message, send that
- "double bounce" error message to this
- address.
- confDEAD_LETTER_DROP DeadLetterDrop [undefined] Filename to save bounce
- messages which could not be returned
- to the user or sent to postmaster.
- If not set, the queue file will
- be renamed.
- confRRT_IMPLIES_DSN RrtImpliesDsn [False] Return-Receipt-To: header
- implies DSN request.
- 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.
- confPID_FILE PidFile [system dependent] Location of pid
- file.
- confPROCESS_TITLE_PREFIX ProcessTitlePrefix
- [undefined] Prefix string for the
- process title shown on 'ps' listings.
- 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.
- confDF_BUFFER_SIZE DataFileBufferSize
- [4096] The maximum size of a
- memory-buffered data (df) file
- before a disk-based file is used.
- confXF_BUFFER_SIZE XScriptFileBufferSize
- [4096] The maximum size of a
- memory-buffered transcript (xf)
- file before a disk-based file is
- used.
- confAUTH_MECHANISMS AuthMechanisms [GSSAPI KERBEROS_V4 DIGEST-MD5
- CRAM-MD5] List of authentication
- mechanisms for AUTH (separated by
- spaces). The advertised list of
- authentication mechanisms will be the
- intersection of this list and the list
- of available mechanisms as determined
- by the CYRUS SASL library.
- confDEF_AUTH_INFO DefaultAuthInfo [undefined] Filename that contains
- authentication information for
- outgoing connections. This file
- must contain the user id, the
- authorization id, the password
- (plain text), and the realm to
- use on separate lines and must be
- readable by root (or the trusted
- user) only. If no realm is
- specified, $j is used.
- confAUTH_OPTIONS AuthOptions [T] When to use the AUTH= parameter
- for the MAIL FROM command:
- T: Try when available (server lists
- 250-AUTH ...)
- A: Only when authentication succeeded.
- confLDAP_DEFAULT_SPEC LDAPDefaultSpec [undefined] Default map
- specification for LDAP maps. The
- value should only contain LDAP
- specific settings such as "-h host
- -p port -d bindDN", etc. The
- settings will be used for all LDAP
- maps unless they are specified in
- the individual map specification
- ('K' command).
- See also the description of OSTYPE for some parameters that can be
- tweaked (generally pathnames to mailers).
- DaemonPortOptions are a special case since multiple daemons can be
- defined. This can be done via
- DAEMON_OPTIONS(`field1=value1,field2=value2,...')
- For example:
- DAEMON_OPTIONS(`Port=smtp,Name=MTA')
- DAEMON_OPTIONS(`Port=587,Name=MSA,M=E')
- If no DAEMON_OPTIONS are defined, then the two lines above are the default.
- The second of these represents a "Message Submission Agent" as defined by
- RFC 2476. To turn off the MSA daemon, use FEATURE(`no_msa').
- +-----------+
- | 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?
- 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 you claim to be)
- N
- O
- P
- Q
- R Relay (for unqualified names)
- S Smart Host
- T
- U my UUCP name (if you 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 this system 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 host/domains that should not be mapped to $M
- O operators that indicate network operations (cannot be in local names)
- P top level pseudo-domains: BITNET, DECNET, FAX, UUCP, etc.
- Q
- R domains this system is 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 DNS based blacklists
- 9 special local rulesets (1 and 2)
- $Revision: 8.351 $, Last updated $Date: 1999/12/09 21:54:55 $