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 host (class {w}) to another site except yours) is denied by default. Note that this changed in sendmail 8.9; previous versions allowed relaying by default. If you really 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} using RELAY_DOMAIN() and RELAY_DOMAIN_FILE() or via the access database (described below). Note that IPv6 addresses must be prefaced with "IPv6:". The file consists (like any other file based class) of entries listed on separate lines, e.g.,
sendmail.org
128.32
IPv6:2002:c0a8:02c7
IPv6:2002:c0a8:51d2::23f4
host.mydomain.com
[UNIX:localhost]
Notice: the last entry allows relaying for connections via a UNIX socket to the MTA/MSP. This might be necessary if your configuration doesn't allow relaying by other means in that case, e.g., by having localhost.$m in class {R} (make sure $m is not just a top level domain).
The relay_domain macro initializes a special class - R - to hold its value. Its value is a list of hosts and domains to which Sendmail should allow mail to be relayed. You can add domains to this list by using:
RELAY_DOMAIN(`list of hosts and domains')
This list is separated by spaces and the list can be made up of hosts, domain names, TCP/IP addresses (IPv4 or IPv6) or network numbers.
You could use a file instead by using:
RELAY_DOMAIN_FILE(`/path/to/file')
listing one entry per line. Any host or domain listed in this file or in the R class is allowed to relay mail through the local machine.
If you use
FEATURE(`relay_entire_domain')
then any host in any of your local domains (that is, class {m}) 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
FEATURE(`relay_based_on_MX')
For example, if your server receives a recipient of user@domain.com and domain.com lists your server in its MX records, the mail will be accepted for relay to domain.com. This feature may cause problems if MX lookups for the recipient domain are slow or time out. In that case, mail will be temporarily rejected. It is usually better to maintain a list of hosts/domains for which the server acts as relay. Note also that this feature 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,
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 is a dangerous feature as it will allow spammers to spam using your mail server by simply specifying a return address of user@your.domain.com. It should not be used unless absolutely necessary. A slightly better solution is
FEATURE(`relay_mail_from')
which allows relaying if the mail sender is listed as RELAY in the access map. If an optional argument `domain' (this is the literal word `domain', not a placeholder) is given, the domain portion of the mail sender is also checked to allowing relaying. This option only works together with the tag From: for the LHS of the access map entries. This feature allows spammers to abuse your mail server by specifying a return address that you enabled in your access file. This may be harder to figure out for spammers, but it should not be used unless necessary. Instead use SMTP AUTH or STARTTLS to allow relaying for roaming users.
If source routing is used in the recipient address (e.g., RCPT TO:<user%site.com@othersite.com>), sendmail will check user@site.com 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.
NOTICE: It is possible to relay mail through a system which the anti-relay rules do not prevent: the case of a system that does use FEATURE(`nouucp', `nospecial') (system A) and relays local messages to a mail hub (e.g., via LOCAL_RELAY or LUSER_RELAY) (system B). If system B doesn't use FEATURE(`nouucp') at all, addresses of the form <example.net!user@local.host> would be relayed to <user@example.net>. System A doesn't recognize `!' as an address separator and therefore forwards it to the mail hub which in turns relays it because it came from a trusted local host. So if a mailserver allows UUCP (bang-format) addresses, all systems from which it allows relaying should do the same or reject those addresses.
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). This also applies to addresses that use domain literals, e.g., <user@[1.2.3.4]>, if the IP address can't be mapped to a host name. 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')
Alternatively, you can allow specific addresses by adding them to the access map, e.g.,
From:unresolvable.domain OK From:[1.2.3.4] OK From:[1.2.4] OK
Notice: domains which are temporarily unresolvable are (temporarily) rejected with a 451 reply code. If those domains should be accepted (which is discouraged) then you can use
LOCAL_CONFIG
C{ResOk}TEMP
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')
Setting the DaemonPortOptions modifier 'u' overrides the default behavior, i.e., unqualified addresses are accepted even without this FEATURE. If this FEATURE is not used, the DaemonPortOptions modifier 'f' can be used to enforce fully qualified domain names.
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')
Notice: the access database is applied to the envelope addresses and the connection information, not to the header.
The FEATURE macro can accept as second parameter the key file definition for the database; for example
FEATURE(`access_db', `hash -T<TMPF> /etc/mail/access_map')
Notice: If a second argument is specified it must contain the option `-T<TMPF>' as shown above. The optional parameters may be
`skip' enables SKIP as value part (see below).
`lookupdotdomain' another way to enable the feature of the same name.
`relaytofulladdress' enable entries of the form To:user@example.com. RELAY to allow relaying to just a specific e-mail address instead of an entire domain.
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. Note that IPv6 addresses must be prefaced with "IPv6:". For example,
From:spammer@aol.com REJECT From:cyberspammer.com REJECT Connect:cyberspammer.com REJECT Connect:TLD REJECT Connect:192.168.212 REJECT Connect:IPv6:2002:c0a8:02c7 RELAY Connect:IPv6:2002:c0a8:51d2::23f4 REJECT
would refuse mail from spammer@aol.com, any user from cyberspammer.com (or any host within the cyberspammer.com domain), any host in the entire top level domain TLD, 192.168.212.* network, and the IPv6 address 2002:c0a8:51d2::23f4. It would allow relay for the IPv6 network 2002:c0a8:02c7::/48.
Entries in the access map should be tagged according to their type. Three tags are available:
Connect: connection information (${client_addr}, ${client_name})
From: envelope sender
To: envelope recipient
Notice: untagged entries are deprecated.
If the required item is looked up in a map, it will be tried first with the corresponding tag in front, then (as fallback to enable backward compatibility) without any tag, unless the specific feature requires a tag. For example,
From:spammer@some.dom REJECT To:friend.domain RELAY Connect:friend.domain OK Connect:from.domain RELAY From:good@another.dom OK From:another.dom REJECT
This would deny mails from spammer@some.dom but you could still send mail to that address even if FEATURE(`blacklist_recipients') is enabled. Your system will allow relaying to friend.domain, but not from it (unless enabled by other means). Connections from that domain will be allowed even if it ends up in one of the DNS based rejection lists. Relaying is enabled from from.domain but not to it (since relaying is based on the connection information for outgoing relaying, the tag Connect: must be used; for incoming relaying, which is based on the recipient address, To: must be used). The last two entries allow mails from good@another.dom but reject mail from all other addresses with another.dom as domain part.
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. "Accept" does not mean "relay", but at most acceptance for local recipients. That is, OK allows less than RELAY.
RELAY Accept mail addressed to the indicated domain (or address if `relaytofulladdress' is set) 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 or recipient with a general purpose message.
DISCARD Discard the message completely using the $#discard mailer. If it is used in check_compat, it affects only the designated recipient, not the whole message as it does in all other cases. This should only be used if really necessary.
SKIP This can only be used for host/domain names and IP addresses/nets. It will abort the current search for this entry without accepting or rejecting it but causing the default action.
### any text where ### is an RFC 821 compliant error code and "any text" is a message to return for the command. The entire string should be quoted to avoid surprises: "### any text" Otherwise sendmail formats the text as email addresses, e.g., it may remove spaces. This type is deprecated, use one of the two ERROR: entries below instead.
ERROR:### any text as above, but useful to mark error messages as such. If quotes need to be used to avoid modifications (see above), they should be placed like this: ERROR:"### any text"
ERROR:D.S.N:### any text where D.S.N is an RFC 1893 compliant error code and the rest as above. If quotes need to be used to avoid modifications, they should be placed like this: ERROR:D.S.N:"### any text"
QUARANTINE:any text Quarantine the message using the given text as the quarantining reason.
For example:
From:cyberspammer.com ERROR:"550 We don't accept mail from spammers" From:okay.cyberspammer.com OK Connect:sendmail.org RELAY To:sendmail.org RELAY Connect:128.32 RELAY Connect:128.32.2 SKIP Connect:IPv6:1:2:3:4:5:6:7 RELAY Connect:suspicious.example.com QUARANTINE:Mail from suspicious host Connect:[127.0.0.3] OK Connect:[IPv6:1:2:3:4:5:6:7:8] OK
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 relaying mail from and to any hosts in the sendmail.org domain, and allow relaying from the IPv6 1:2:3:4:5:6:7:* network and from the 128.32.*.* network except for the 128.32.2.* network, which shows how SKIP is useful to exempt subnets/subdomains. The last two entries are for checks against ${client_name} if the IP address doesn't resolve to a hostname (or is considered as "may be forged"). That is, using square brackets means these are host names, not network numbers.
Warning: if you change the RFC 821 compliant error code from the default value of 550, then you should probably also change the RFC 1893 compliant error code to match it. For example, if you use
To:user@example.com ERROR:450 mailbox full
the error returned would be "450 5.0.0 mailbox full" which is wrong.
Use "ERROR:4.2.2:450 mailbox full" instead.
Note, UUCP users may need to add hostname.UUCP to the access database or class {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} 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:
From:FREE.STEALTH.MAILER@ ERROR: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:
To:badlocaluser@ ERROR:550 Mailbox disabled for badlocaluser To:host.my.TLD ERROR:550 That host does not accept mail To:user@other.my.TLD ERROR:550 Mailbox disabled for this recipient
This would prevent a recipient of badlocaluser in any of the local domains (class {w}), any user at host.my.TLD, and the single address user@other.my.TLD from receiving mail. Please note: a local username must be now tagged with an @ (this is consistent with the check of the sender address, and hence it is possible to distinguish between hostnames and usernames). Enabling this feature will keep you from sending mails to all addresses that have an error message or REJECT as value part in the access map. Taking the example from above:
spammer@aol.com REJECT cyberspammer.com REJECT
Mail can't be sent to spammer@aol.com or anyone at cyberspammer.com. That's why tagged entries should be used.
There are several DNS based blacklists which can be found by querying a search engine. These are databases of spammers maintained in DNS. To use such a database, specify
FEATURE(`dnsbl', `dnsbl.example.com')
This will cause sendmail to reject mail from any site listed in the DNS based blacklist. You must select a DNS based blacklist domain to check by specifying an argument to the FEATURE. The default error message is
Rejected: IP-ADDRESS listed at SERVER
where IP-ADDRESS and SERVER are replaced by the appropriate information. A second argument can be used to specify a different text or action. For example,
FEATURE(`dnsbl', `dnsbl.example.com', `quarantine')
would quarantine the message if the client IP address is listed at `dnsbl.example.com'.
By default, temporary lookup failures are ignored and hence cause the connection not to be rejected by the DNS based rejection list. This behavior can be changed by specifying a third argument, which must be either `t' or a full error message. For example:
FEATURE(`dnsbl', `dnsbl.example.com', `',
`"451 Temporary lookup failure for " $&{client_addr} " in dnsbl.example.com"')
If `t' is used, the error message is:
451 Temporary lookup failure of IP-ADDRESS at SERVER
where IP-ADDRESS and SERVER are replaced by the appropriate information.
This FEATURE can be included several times to query different DNS based rejection lists.
Notice: to avoid checking your own local domains against those blacklists, use the access_db feature and add:
Connect:10.1 OK Connect:127.0.0.1 RELAY
to the access map, where 10.1 is your local network. You may want to use "RELAY" instead of "OK" to allow also relaying instead of just disabling the DNS lookups in the blacklists.
The features described above make use of the check_relay, check_mail, and check_rcpt rulesets. Note that check_relay checks the SMTP client hostname and IP address when the connection is made to your server. It does not check if a mail message is being relayed to another server. That check is done in check_rcpt. 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. 2312343@bigisp.com), you would use Local_check_mail and the 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. Other results starting with $# are interpreted by sendmail and may lead to unspecified behavior. Note: do NOT create a mailer with the name OK. Return values that do not start with $# are ignored, i.e., normal processing continues.
Delay all checks
By using FEATURE(`delay_checks') the rulesets check_mail and check_relay will not be called when a client connects or issues a MAIL command, respectively. Instead, those rulesets will be called by the check_rcpt ruleset; they will be skipped if a sender has been authenticated using a "trusted" mechanism, i.e., one that is defined via TRUST_AUTH_MECH(). If check_mail returns an error then the RCPT TO command will be rejected with that error. If it returns some other result starting with $# then check_relay will be skipped. If the sender address (or a part of it) is listed in the access map and it has a RHS of OK or RELAY, then check_relay will be skipped. This has an interesting side effect: if your domain is my.domain and you have
my.domain RELAY
in the access map, then any e-mail with a sender address of <user@my.domain> will not be rejected by check_relay even though it would match the hostname or IP address. This allows spammers to get around DNS based blacklist by faking the sender address. To avoid this problem you have to use tagged entries:
To:my.domain RELAY Connect:my.domain RELAY
if you need those entries at all (class {R} may take care of them).
FEATURE(`delay_checks') can take an optional argument:
FEATURE(`delay_checks', `friend') enables spamfriend test FEATURE(`delay_checks', `hater') enables spamhater test
If such an argument is given, the recipient will be looked up in the access map (using the tag Spam:). If the argument is `friend', then the default behavior is to apply the other rulesets and make a SPAM friend the exception. The rulesets check_mail and check_relay will be skipped only if the recipient address is found and has RHS FRIEND. If the argument is `hater', then the default behavior is to skip the rulesets check_mail and check_relay and make a SPAM hater the exception. The other two rulesets will be applied only if the recipient address is found and has RHS HATER.
This allows for simple exceptions from the tests, e.g., by activating the friend option and having
Spam:abuse@ FRIEND
in the access map, mail to abuse@localdomain will get through (where "localdomain" is any domain in class {w}). It is also possible to specify a full address or an address with +detail:
Spam:abuse@my.domain FRIEND Spam:me+abuse@ FRIEND Spam:spam.domain FRIEND
Note: The required tag has been changed in 8.12 from To: to Spam:. This change is incompatible to previous versions. However, you can (for now) simply add the new entries to the access map, the old ones will be ignored. As soon as you removed the old entries from the access map, specify a third parameter (`n') to this feature and the backward compatibility rules will not be in the generated .cf file.
Header Checks
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_CONFIG HMessage-Id: $>CheckMessageId LOCAL_RULESETS SCheckMessageId R< $+ @ $+ > $@ OK R$* $#error $: 553 Header Error
The alternative format:
HSubject: $>+CheckSubject
that is, $>+ instead of $>, gives the full Subject: header including comments to the ruleset (comments in parentheses () are stripped by default).
A default ruleset for headers which don't have a specific ruleset defined for them can be given by:
H*: $>CheckHdr
Notice:
1. All rules act on tokens as explained in doc/op/op.{me,ps,txt}.
That may cause problems with simple header checks due to the
tokenization. It might be simpler to use a regex map and apply it
to $&{currHeader}.
2. There are no default rulesets coming with this distribution of
sendmail. You can write your own, can search the WWW for examples,
or take a look at cf/cf/knecht.mc.
3. When using a default ruleset for headers, the name of the header
currently being checked can be found in the $&{hdr_name} macro.
After all of the headers are read, the check_eoh ruleset will be called for any final header-related checks. The ruleset is called with the number of headers and the size of all of the headers in bytes separated by $|. One example usage is to reject messages which do not have a Message-Id: header. However, the Message-Id: header is *NOT* a required header and is not a guaranteed spam indicator. This ruleset is an example and should probably not be used in production.
LOCAL_CONFIG
Kstorage macro
HMessage-Id: $>CheckMessageId
LOCAL_RULESETS
SCheckMessageId
# Record the presence of the header
R$* $: $(storage {MessageIdCheck} $@ OK $) $1
R< $+ @ $+ > $@ OK
R$* $#error $: 553 Header Error
Scheck_eoh
# Check the macro
R$* $: < $&{MessageIdCheck} >
# Clear the macro for the next message
R$* $: $(storage {MessageIdCheck} $) $1
# Has a Message-Id: header
R< $+ > $@ OK
# Allow missing Message-Id: from local mail
R$* $: < $&{client_name} >
R< > $@ OK
R< $=w > $@ OK
# Otherwise, reject the mail
R$* $#error $: 553 Header Error
is a usenet newsgroup where you can go to get help.
Next Section: Mail Filtering - 25 of 32