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

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.

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 in the local domain 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. The addresses must be 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, $j is used. 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 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:

meaning someone@foo.org will be sent to someone@elsewhere.com.

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

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.

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

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. 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, /usr/local/etc/smrsh is assumed.