Original Source :

Anti-Spam Configuration Control

The primary anti-spam features available in sendmail are:

bulletRelaying is denied by default.
bulletBetter checking on sender information.
bulletAccess database.
bulletHeader 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


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


For example, if your server receives a recipient of and lists your server in its MX records, the mail will be accepted for relay to 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,


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 It should not be used unless absolutely necessary.

If source routing is used in the recipient address (i.e. RCPT TO: <>), sendmail will check for relaying if 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:


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.

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



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



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



The FEATURE macro can accept a second parameter giving the key file definition for the database; for example


FEATURE(`access_db', `hash -o /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,		REJECT	REJECT
192.168.212		REJECT

would refuse mail from, any user from (or any host within the 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/recipient with a general purpose message.
DISCARD Discard the message completely using the $#discard mailer.
This only works for sender addresses (i.e., it indicates that you
should discard anything received from the indicated domain).
### any text where ### is an RFC 821 compliant error code and
"any text" is a message to return for the command.

For example:	550 We don't accept mail from spammers	OK		OK
128.32			RELAY

would accept mail from, but would reject mail from all other hosts at with the indicated message. It would allow accept mail from any hosts in the domain, and allow relaying for the 128.32.*.* network. Note, UUCP users may need to add hostname.UUCP to the access database or class 'R' ($=R). If you also use:



then the above example will allow relaying for, but not hosts within the 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:



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		550 That host does not accept mail	550 Mailbox disabled for this recipient

This would prevent a recipient of, any user at, and the single address from receiving mail. Enabling this feature will keep you from sending messages to all addresses that have an error message or REJECT as value part in the access map. Taking the example from above:		REJECT	REJECT

Mail can't be sent to or anyone at

There is also a ``Realtime Blackhole List'' run by the MAPS project at This is a database maintained in DNS of spammers. To use this database, use



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.

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., you would use Local_check_mail and the new regex map:

	Kallnumbers regex -a@MATCH ^[0-9]+$ 
	# check address against various regex checks 
	R$*				$: $>Parse0 $>3 $1
	R$+ < @ > $*	$: $(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.

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 For example, this can be used to check the validity of a Message-ID: header:

	HMessage-Id: $>CheckMessageId

	R< $+ @ $+ >		$@ OK
	R$*			$#error $: 553 Header Error

Users of FEATURE(`nullclient') who desire to use the anti-spam and anti-relaying capabilities should replace FEATURE(`nullclient', `mailhub') with:

	define(`MAIL_HUB', `mailhub')
	define(`SMART_HOST', `mailhub')
	define(`confFORWARD_PATH', `')

where mailhub is the fully qualified hostname for their mail server. The above rules will provide the relaying to the mailhub without local alias and forward file expansion. To match the other behavior of FEATURE(`nullclient'), you should also add these lines along with those listed above: