The host that will accept USENET-addressed e-mail. If not defined, USENET-addressed mail will be handled by the USENET mailer as normal. USENET-addressed e-mail has the form newsgroup.USENET.

The host that will accept UUCP-addressed e-mail. If not defined, all UUCP sites must be directly connected.

The host that will accept BITNET-addressed e-mail. If not defined, the .BITNET pseudo-domain will not work.

The host that will accept DECNET-addressed e-mail. If not defined, the .DECNET pseudo-domain and addresses of the form node::user will not work.

The host that will accept mail to the .FAX pseudo-domain. The “fax” mailer overrides this value.

The site that will handle unqualified names -- that is, names without 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 works only at small sites, and only with some user agents.

The site that will handle lusers; that is, apparently local names that are not local accounts or aliases.

The local and prog mailers. You will almost always need these; the only exception is if you relay all of your mail to another site. This mailer is included automatically.

The Simple Mail Transport Protocol mailer. This mailer is the standard mailer for internet peer-to-peer mail transport; it assumes a world where everyone is running the name server. This file actually defines four mailers: “smtp” for regular (old-style) SMTP to other servers, “esmtp” for extended SMTP to other servers, “smtp8” to do SMTP to other servers without converting 8-bit data to MIME (essentially, this is your statement that you know the other end is 8-bit clean even if it does not say so), and “relay” for transmission to our RELAY_HOST, LUSER_RELAY, or MAILER_HUB.

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. For more information, see the /usr/lib/sendmail.cf_m4 file.

Usenet (network news) delivery. If this mailer is specified, an extra rule is added to ruleset 0 that forwards all local e-mail for users named ``group.usenet'' to the ``inews'' program. Note that this works for all groups, and may be considered a security problem.

Facsimile transmission. This is experimental and based on Sam Leffler's HylaFAX software. For more information, see http://www.vix.com/hylafax/.

Post Office Protocol.

An interface to procmail (does not come with sendmail). This mailer is designed to be used in mailer tables. 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 can set up a mailer table as follows:

host.comprocmail:/etc/procmailrcs/host.com

The /etc/procmailrcs/host.com file will contain the following entry:

:0# forward mail for host.com 
! -oi -f $1 person@other.host

This arranges 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 macro should be listed first.

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.

The phquery program. Internally, this is somewhat counterintuitively referenced as the “ph” mailer. It can be used to do CCSO name server lookups. The phquery program, which this mailer uses, is distributed with the ph client.

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.

Reads the /etc/sendmail.cw file to get alternate names for this host. This might be used if you were on a host that provides MX records for a dynamic set of other hosts. If the set is static, it is better to include the line "Cw<name1> <name2> ..." (where the names are fully qualified domain names). You can override the actual file name by redefining the confCW_FILE variable.

Reads the /etc/sendmail.ct file to get the names of users that will be trusted; that is, able to set their envelope “from” address by using -f without generating a warning message. You can override the actual file name by redefining the confCT_FILE variable.

Rejects all mail addressed to “address.REDIRECT” and provides the following message:

551 User not local; please try <address> 

If this feature is set, you can alias people who have left to their new address with “.REDIRECT” appended.

Prevents special treatment of UUCP addresses.

Prevents passing of addresses to $[ ... $] for canonification. This feature is used only by sites that act only as mail gateways or sites that have user agents that do full canonification themselves. You may also want to use the following define command to turn off the usual resolver options that perform a similar function:

define(`confBIND_OPTS',`-DNSRCH -DEFNAMES')

Indicates that e-mail sent to “user@local.host” is marked as “sticky”; that is, the local addresses are not matched against UDB and do not go through ruleset 5. This feature is used when “user” is not necessarily the same as “user@local.host;” for example, to make a distinct domain-wide namespace. Prior to version 8.7, stickyhost was the default, and notsticky was used to turn this feature off.

Indicates inclusion of a “mailer table” that can be used to override routing for particular domains. The argument of the FEATURE can be the key definition. If none is specified, the following definition is used:

hash -o /etc/mailertable

Keys in this database are fully qualified domain names or partial domains preceded by a dot; for example, “vangogh.CS.Berkeley.EDU” or “.CS.Berkeley.EDU”. Values must be of the form “mailer:domain,” where “mailer” is the internal mailer name, and “domain” is the destination of the message. These maps are not reflected into the message header. Special cases are as follows:

local:user - Forwards to the indicated user using the local mailer

local: - Forwards to the original user in the e-mail address using the local mailer

error:code message - Provides an error message with the indicated code and message.

Indicates inclusion of a “domain table” to provide domain name mapping. Use of this feature should be limited to your own domains. It might be useful if you change names (for example, your company changes names from oldname.com to newname.com). The argument of the FEATURE macro can be the key definition. If none is specified, the definition used is as follows:

hash -o /etc/domaintable

The key in this table is the domain name; the value is the new (fully qualified) domain. Anything in the domaintable is reflected into headers; that is, this is done in ruleset 3.

Looks 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 as follows:

hash -o /etc/bitdomain.db

Keys are the bitnet hostname; values are the corresponding internet hostname.

Indicates feature for UUCP hosts similar to bitdomain. The default map definition is as follows:

hash -o /etc/uudomain.db

At the moment there is no automatic tool to build this database.

Indicates inclusion of the local host domain even on locally delivered mail. The local host name is not usually added on unqualified names. However, if you use a shared message store but do not use the same user name space everywhere, you might need the host name on local names.

If masquerading is enabled (using the MASQUERADE_AS macro), this feature causes recipient addresses to masquerade also, as being from the masquerade host. Recipient addresses usually get the local host name. Although this might be right for most 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 of the local entries.

Usually, any hosts listed in $=w are masqueraded. If this feature is indicated, only the hosts listed in $=M are masqueraded. This feature is useful if you have several domains with disjoint namespaces hosted on the same machine.

If masquerading is enabled (using MASQUERADE_AS) and MASQUERADE_DOMAIN is set, this feature causes 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). In the following example, *foo.org and *bar.com are converted to masq.com. Without the “masquerade_entire_domain” feature, only foo.org and bar.com are masqueraded.

MASQUERADE_AS(masq.com)

MASQUERADE_DOMAIN(foo.org)

MASQUERADE_DOMAIN(bar.com)

---

Note: This feature should be used only for masquerading domains within your jurisdiction and current hierarchy.

---

Usually, only header addresses are masqueraded. This feature enables masquerading of the envelope of a message.

Causes certain addresses originating locally (that is, addresses 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 (that is. only header sender addresses) unless the allmasquerade and/or masquerade_envelope features are indicated. Qualified addresses must have the domain part in the list of names given by the GENERICS_DOMAIN or GENERICS_DOMAIN_FILE macros (analogously to MASQUERADE_DOMAIN and MASQUERADE_DOMAIN_FILE).

The argument of FEATURE(`genericstable') can be the map definition. The default map definition is as follows:

hash -o /etc/genericstable

The key for this table is either the full address or the unqualified username (the former is tried first); the value is the new user address. If the new user address does not include a domain, it will be qualified in the standard manner; that is, 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.

Indicates a domain-specific form of aliasing, allowing multiple virtual domains to be hosted on one machine. For example, consider a virtusertable with the following contents:

info@foo.com     foo-info
info@bar.com     bar-info 
@baz.org         jane@elsewhere.net

Mail addressed to info@foo.com will be sent to the address foo-info, mail addressed to info@bar.com will be delivered to bar-info, and mail addressed to anyone at baz.org will be sent to jane@elsewhere.net. The username from the original address is passed as %1 allowing:

@foo.org         1@elsewhere.com

With this designation, someone@foo.org will be sent to someone@elsewhere.com.

All of the host names on the left hand side (foo.com, bar.com, and baz.org) must be in $=w. The default map definition is:

hash -o /etc/virtusertable

A new definition can be specified as the second argument of the FEATURE macro, as in the following example:

FEATURE(`virtusertable', `dbm -o /etc/mail/virtusers')

Indicates that the site is not running DNS (for example, the site might be UUCP-only connected).

Creates a stripped-down configuration file containing nothing but support for forwarding all mail to a central hub via a local SMTP-based network. The argument is the name of that hub.

The only other feature that should be used in conjunction with nullclient is “nocanonify” (this causes addresses to be sent unqualified via the SMTP connection; usually, they are qualified with the masquerade name, which defaults to the name of the hub machine). No mailers should be defined. No aliasing or forwarding is done. Also, note that absolutely no anti-spam or anti-relaying is done in a null client configuration.

Indicates use of 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 LMTP capable mail.local that came with the 8.9 distribution. The path to mail.local is set by the confEBINDIR m4 variable, making the default LOCAL_MAILER_PATH /usr/libexec/mail.local.

Indicates use of procmail as the local mailer. This mailer can make use of the “user+indicator@local.host” syntax; usually, the +indicator is not used, but by default it is passed as the -a argument to procmail. The argument to this feature is the pathname of procmail, which defaults to PROCMAIL_MAILER_PATH. Note that this does not use PROCMAIL_MAILER_FLAGS or PROCMAIL_MAILER_ARGS for the local mailer; make changes to LOCAL_MAILER_FLAGS and LOCAL_MAILER_ARGS instead.

Indicates acceptance of mail as though locally addressed for any host that lists the local address as containing the best possible MX record. This acceptance generates additional DNS traffic, but should not cause problems for low to medium traffic hosts. However, the argument can be a set of domains, which limits the feature to apply only to these domains, reducing unnecessary DNS traffic.

---

Caution: 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.

---

Indicates use of 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.

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 RELAY_DOMAIN or RELAY_DOMAIN_FILE macros (analogously to MASQUERADE_DOMAIN and MASQUERADE_DOMAIN_FILE).

By default, only hosts listed as RELAY in the access db are allowed to relay. This option also allows any host in your domain as defined by the `m' class ($=m).

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 behavior to look up individual host names only.

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.

---

Note: If route address syntax (or %-hack syntax) is used, the FEATURE(`relay_based_on_MX') command does not necessarily allow routing of these messages. If this is a problem, add entries to the access-table or use FEATURE(`loose_relay_check').

---

Allows relaying if the domain portion of the mail sender is a local host. This feature should be used only if absolutely necessary, because it opens a window for spammers. Specifically, mail can be sent to your mail server that claims to be from your domain (either directly or via a routed address), and you can relay it out to arbitrary hosts on the Internet.

Accepts unqualified sender addresses. Usually, if the connection is a network connection and the sender address does not include a domain name, MAIL FROM: commands in the SMTP session are refused. If your setup sends local mail unqualified (for example. MAIL FROM: <joe>), you will need to use this feature.

Accepts all domains on input, even if they are unresolvable. Usually, if the host part of the argument to MAIL FROM: cannot be located in the host name service (for example, DNS), MAIL FROM: commands in the SMTP session are refused. 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 can use this feature.

Turns on the access database feature. The access_db feature lets you allow or refuse to accept mail from specified domains for administrative reasons. By default, the access database specification is as follows:

hash -o /etc/mail/access

The format of the access database is described in the /usr/lib/sendmail.cf_m4/README file.

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 database. The format of the access database is described in the /usr/lib/sendmail.cf_m4/README file.

Turns on rejection of hosts found in the Realtime Blackhole List. If an argument is provided, it is used as the name sever to contact; otherwise, the main RBL server at rbl.maps.vix.com is used. For details, see http://maps.vix.com/rbl/.

Usually, if a recipient using % addressing is used (for example, 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.

These features allow setting QueueLA and RefuseLA to a base value times the number of CPUs in a system. The argument is the number by which to scale. For example,

FEATURE(`percpu_QueueLA', 10)dnl

Allows direct delivery to a set of domains if a SMART_HOST parameter has been defined. This feature is useful inside of a firewall. All domains in the argument are considered locally connected. If no argument is given, the local domain is assumed.

Enables mail to be forwarded to a usenet newsgroup. Mail addressed to groups specified in the mailnews FEATURE will be translated to group.USENET, and either locally delivered (via USENET_MAILER) or forwarded (via USENET_RELAY)