|
|
Unsolicited email, or ``spam'', is an increasing problem on the Internet. The primary anti-spam features available in sendmail are listed below:
Relaying (transmission of messages from a site outside your host to another site except yours) is denied by default. You can allow specified domains to relay mail through your server by adding the domain name or IP address via the access database, /usr/lib/mail/access. This file consists of entries listed on separate lines. For example:
sendmail.org 128.32 1:2:3:4:5:6:7 host.mydomain.com
If source routing is used in the recipient address (for example, RCPT TO: <user%site.com@othersite.com>), sendmail checks user@site.com for relaying if othersite.com is an allowed relay host in the access database.
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).
sendmail will also refuse mail if the "Mail From:" parameter is not fully qualified (i.e., contains a domain as well as a user).
The ``access'' database enables you to accept or reject mail from selected domains. For example, you may choose to reject all mail originating from known spammers.
Because /usr/lib/mail/access is a database,
you must use makemap to create the database map
after creating the text file, as described below.
For example:
makemap hash /usr/lib/mail/access < /usr/lib/mail/access
The table itself uses e-mail addresses, domain names, and network numbers as keys. For example,
spammer@aol.com REJECT cyberspammer.com REJECT 192.168.212 REJECTwould refuse mail from spammer@aol.com, 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:
For example:
cyberspammer.com ERROR:"550 We don't accept mail from spammers" okay.cyberspammer.com OK sendmail.org RELAY 128.32 RELAY 1:2:3:4:5:6:7 RELAY [127.0.0.3] OK [1:2:3:4:5:6:7:8] OKwould 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 128.32.*.* network and the IPv6 1:2:3:4:5:6:7:* network. The latter 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").
user@example.com 450 mailbox fullthe error returned would be
450 4.0.0 mailbox full, which is wrong.
Use ``450 4.2.2 mailbox full'' or
``ERROR:4.2.2:450 mailbox full'' instead.
Note that UUCP users may need to add hostname.UUCP to the access database.
You can also use the access database to block sender addresses based on the username portion of the address. For example:
FREE.STEALTH.MAILER@ ERROR:550 Spam not accepted
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 the options listed so far are not sufficient for your purposes,
you can tag entries in the access map according to their type.
Three tags are available:
Connect: [connection information] (${client_addr}, ${client_name})
From: [envelope sender]
To: [envelope recipient]
If the required item is looked up in a map, it will be tried first with the corresponding tag in front, then without any 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. 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. Because relaying is based on the connection information for outgoing relaying, the "Connect:" tag 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.
You can also reject mail on the basis of the contents of mail 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: $>CheckMessageIdSCheckMessageId 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 that do not have a specific ruleset defined for them can be given by:
H*: $>CheckHdr
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 that 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
LOCAL_RULESETS
HMessage-Id: $>CheckMessageId
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