Read the file /etc/sendmail.cw file to get alternate names for this host. This might be used if you were on a host that MXed for a dynamic set of other hosts. If the set is static, just including the line "Cw<name1> <name2> ..." (where the names are fully qualified domain names)is probably superior. The actual filename can be overridden by redefining confCW_FILE.

Read the file /etc/sendmail.ct file to get the names of users that will be ``trusted'', that is, able to set their envelope from address using -f without generating a warning message. The actual filename can be overridden by redefining confCT_FILE.

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.

Don't do anything special with UUCP addresses at all.

Don't pass addresses to $[ ... $] for canonification. This would generally only be used by sites that only act as mail gateways or which have user agents that do full canonification themselves. You may also want to use "define(`confBIND_OPTS',`-DNSRCH -DEFNAMES')" to turn off the usual resolver options that do a similar thing.

If set, email sent to "[email protected]" 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 "[email protected]", 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.

Include a "mailer table" which can be used to override routing for particular domains. The argument of the FEATURE may be the key definition. If none is specified, the definition used is:

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:

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:

will forward to the indicated user using the local mailer,

will forward to the original user in the e-mail address using the local mailer, and

will give an error message with the indicated code and message.

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:

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.

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:

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

Similar feature for UUCP hosts. The default map definition is:

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

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.

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.

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.

If masquerading is enabled (using MASQUERADE_AS) and MASQUERADE_DOMAIN 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:

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.

Using this features instructs sendmail to masquerade the envelope sender and recipient as well as those in the headers.

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

The key for this table is either the full address or the unqualified username (the former is tried first); the value is the new user address. If the new user address does not include a domain, it will be qualified in the standard manner, i.e. using $j or the masquerade name. Note that the address being looked up must be fully qualified. For local mail, it is necessary to use FEATURE(always_add_domain) for the addresses to be qualified.

A domain-specific form of aliasing, allowing multiple virtual domains to be hosted on one machine. For example, if the virtuser table contained:

then mail addressed to [email protected] will be sent to the address foo-info, mail addressed to [email protected] will be delivered to bar-info, and mail addressed to anyone at baz.org will be sent to [email protected]. The username from the original address is passed as %1 allowing:

meaning [email protected] will be sent to [email protected].

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

A new definition can be specified as the second argument of the FEATURE macro, such as

We aren't running DNS at our site (for example, we are UUCP-only connected). It's hard to consider this a "feature", but hey, it had to go somewhere. Actually, as of 8.7 this is a no-op -- remove "dns" from the hosts service switch entry instead.

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

The only other feature that should be used in conjunction with this one is "nocanonify" (this causes addresses to be sent unqualified via the SMTP connection; normally they are qualified with the masquerade name, which defaults to the name of the hub machine). No mailers should be defined. No aliasing or forwarding is done. Also, note that absolutely no anti-spam or anti-relaying is done in a null client configuration. More information can be found in the ANTI-SPAM CONFIGURATION CONTROL section.

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.

Use procmail as the local mailer. This mailer can make use of the "[email protected]" syntax; normally the +indicator is just tossed, but by default it is passed as the -a argument to procmail. The argument to this feature is the pathname of procmail, which defaults to PROCMAIL_MAILER_PATH. Note that this does NOT use PROCMAIL_MAILER_FLAGS or PROCMAIL_MAILER_ARGS for the local mailer; tweak LOCAL_MAILER_FLAGS and LOCAL_MAILER_ARGS instead.

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.

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.

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

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

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.

Turns on the ability to allow relaying based on the MX records of the host portion of an incoming recipient. See description below for more information before using this feature.

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.

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.

Normally, MAIL FROM: commands in the SMTP session will be refused if the host part of the argument to MAIL FROM: cannot be located in the host name service (e.g., DNS). If you are inside a firewall that has only a limited view of the Internet host name space, this could cause problems. In this case you probably want to use this feature to accept all domains on input, even if they are unresolvable.

Turns on the access database feature. The access db gives you the ability to allow or refuse to accept mail from specified domains for administrative reasons. By default, the access database specification is ``hash -o /etc/mail/access''. The format of the database is described on the Anti-Spam Configuration Control page.

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 [email protected]. These specifications are put in the access db as described on the Anti-Spam Configuration Control page..

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

Normally, if a recipient using % addressing is used, e.g. user%site@othersite, and othersite is in class 'R', the check_rcpt ruleset will strip @othersite and recheck user@site for relaying. This feature changes that behavior. It should not be needed for most installations.