As of sendmail version 8.9, forwarding of SMTP messages is not permitted by default.
For example, if you are on site
A.COM, you will not accept mail from
C.ORG without special arrangements. These instructions assume
that you are using the M4 technique for creating your sendmail.cf files; if you are not,
you are on your own.
The simplest approach is to list the domains you are willing to relay in the file
Anything listed in this file will be accepted for relaying. N.B.: Sendmail must be
restarted after this file is modified.
For more precise tuning, several
FEATUREs have been added to control
FEATURE(relay_hosts_only). Normally domains are listed in
/etc/mail/relay-domains; any hosts in those domains match. With this feature, each host in a domain must be listed.
FEATURE(relay_entire_domain). Setting this feature allows relaying of all hosts within your domain. For example, on the host
gateway.A.COM, this feature allows mail to or from any host in the
A.COMdomain. More precisely, this relays any host listed in the
$=mclass. This is equivalent to listing the name of the domain in
FEATURE(access_db). This enables the hash database
/etc/mail/accessto enable or disable access from individual domains (or hosts, if
FEATURE(relay_hosts_only)is set). The database format is described below.
FEATURE(blacklist_recipients). If set, this feature looks up recipients as well as senders in the access database.
FEATURE(rbl). Enables rejection of mail based on the Realtime Blackhole List maintained at maps.vix.com.
FEATURE(accept_unqualified_senders). Normally, sendmail will not accept mail from a sender without a domain attached -- for example,
user@B.NET. This feature allows such users.
FEATURE(accept_unresolvable_domains). Normally, sendmail will refuse to accept mail that has a return address with a domain that cannot be resolved using the regular host lookups (a technique commonly used by spammers). This feature permits acceptance of such addresses. Unresolvable domains can be selectively accepted using the access database.
FEATURE(relay_based_on_MX). Setting this feature permits relaying for any domain that is directed to your host.
Several other features are probably a bad idea, unless you are inside a firewall, because they make your system vulnerable to abuse by spammers:
FEATURE(relay_local_from). This feature allows relaying if the message claims to originate at your domain. Since forging this address is trivial, this is probably a bad idea.
FEATURE(loose_relay_check). This turns off checking for explicit routing through your host, such as
FEATURE(promiscuous_relay). If you really want to forward all the spam on the net, this will turn off all checking for relaying.
The access database (normally in
/etc/mail/access) allows a mail
administrator to administratively allow access to the mail server by individual domains.
Each database entry consists of a domain name or network number as the key and an action
as the value.
Keys can be a fully or partly qualified host or domain name such as
domain.com. The last two forms match
any host or subdomain under the specified domain. (If
is set, only the first form works.) Keys can also be a network address or subnetwork,
latter two forms match any host in the indicated subnetwork. Lastly, keys can be
to reject mail from a specific user.
Values can be
REJECT to refuse connections from this host,
to accept the message but silently discard it (the sender will think it has been
OK to allow access (overriding other built-in checks),
to allow access including relaying SMTP through your machine, or an arbitrary message to
reject the mail with the customized message.
For example, a database might contain:
cyberpromo.comdomain, allow any relaying to or from any host in the
sendmail.orgdomain, and reject mail from
firstname.lastname@example.org a specific message.