Sendmail. Anti-Spam Configuration Control

---------------------------------------------------------------
Origin: http://www.sendmail.org/m4/anti-spam.html
---------------------------------------------------------------

Anti-Spam Configuration Control

The primary anti-spam features available in sendmail are:

• Relaying is denied by default.
  
• Better checking on sender information.
  
• Access database.
  
• Header 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

FEATURE(relay_entire_domain)

then any host in any of your local domains (that is, the $=m class)
will be relayed.

You can also allow relaying based on the MX records of the host
portion of an incoming recipient address by using

FEATURE(relay_based_on_MX)

For example, if your server receives a recipient of [e-mail]
and domain.com lists your server in its MX records, the mail will be
accepted. 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. Along the same lines,

FEATURE(relay_local_from)

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

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

FEATURE(loose_relay_check)

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

FEATURE(accept_unresolvable_domains)

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

FEATURE(accept_unqualified_senders)

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

FEATURE(access_db)

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)

The table itself uses e-mail addresses, domain names, and network
numbers as keys. For example,

[e-mail]		REJECT

cyberspammer.com	REJECT

192.168.212		REJECT

would refuse mail from [e-mail], any user from cyberspammer.com
(or any host within the cyberspammer.com 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.
RELAY	Allow domain to relay through your SMTP server. RELAY also serves 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
### any text	where ### is an RFC 821 compliant error code and "any text" is a message to return for the command.

For example:

cyberspammer.com	550 We don't accept mail from spammers

okay.cyberspammer.com	OK

sendmail.org		OK

128.32			RELAY

would accept mail from okay.cyberspammer.com, but would reject mail
from all other hosts at cyberspammer.com with the indicated message.
It would allow accept mail from any hosts in the sendmail.org 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:

FEATURE(relay_hosts_only)

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

FEATURE(blacklist_recipients)

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

host.mydomain.com		550 That host does not accept mail

[e-mail]	550 Mailbox disabled for this recipient

This would prevent a recipient of [e-mail], any
user at host.mydomain.com, and the single address
[e-mail] from receiving mail.

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

FEATURE(rbl)

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

	LOCAL_CONFIG

	Kallnumbers regex -a@MATCH ^[0-9]+$



	LOCAL_RULESETS

	SLocal_check_mail

	# check address against various regex checks

	R$*				$: $>Parse0 $>3 $1

	R$+ < @ bigisp.com. > $*	$: $(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 sendmail.cf. For example, this can be used to check the validity of
a Message-ID: header:

	LOCAL_RULESETS

	HMessage-Id: $>CheckMessageId



	SCheckMessageId

	R< $+ @ $+ >		$@ OK

	R$*			$#error $: 553 Header Error

---

ALIGN=BOTTOM WIDTH=104 HEIGHT=33 BORDER=0> src="http://lib.ru/SENDMAIL//gif/arrowup.gif" ALT="up" ALIGN=BOTTOM WIDTH=19 HEIGHT=33
BORDER=0> ALT="next" ALIGN=BOTTOM WIDTH=104 HEIGHT=33 BORDER=0>