UNIX System Administration Handbook - Evi Nemeth [355]
Many sites use an access database to control spam. Our incoming master mail machine in the computer science department at the University of Colorado rejects mail from over 500 known spammers identified by addresses, domains, or IP networks.
Blacklisting users or sites
If you have local users or hosts that you want to block mail to, use
FEATURE('blacklist_recipients')
which supports the following types of entries in your access file:
nobody@ 550 Mailbox disabled for this user
printer.mydomain.edu 550 This host does not accept mail
user@host.mydomain.edu 550 Mailbox disabled for this user
These lines block incoming mail to user nobody on any host, to host printer, and to a particular user’s address on one machine.
To include the black hole lists from Paul Vixie’s MAPS (Mail Abuse Prevention System; see maps.vix.com) project—or any other DNS-style blocking list—use the dnsbl feature:
FEATURE('dnsbl')
See Chapter 16 for more information about DNS.
This feature causes sendmail to reject mail from any site whose IP address is in the Realtime Blackhole List of known spammers maintained by MAPS. Other lists catalog known dial-up spammers and sites that run open relays.
These blacklists are distributed through a clever tweak of the DNS system; hence the name dnsbl. For example, a special DNS resource record of the form
IP-address.rbl.maps.vix.com in a 127.0.0.2
put into the DNS database of the rbl.maps.vix.com domain would block mail from that host if the dnsbl feature was enabled (because sendmail would check explicitly to see if such a record existed). The IP-address in this example is a host address in its dotted quad form with the order of the octets reversed.
You can include the dnsbl feature several times to check different lists of abusers: just add a second argument to specify the blacklist name server and a third argument with the error message that you would like returned. If the third argument is omitted, a fixed error message from the DNS database containing the records is returned. Here are examples of three lists: rbl (the default), the dul list of dial-up users, and the rss list of open relays.
FEATURE('dsnbl', 'rbl.maps.vix.com', 'Rejected - see www.mail-abuse.org/rbl/')
FEATURE('dsnbl', 'dul.maps.vix.com', 'Dialup - see www.mail-abuse.org/dul/')
FEATURE('dnsbl', 'relays.mail-abuse.org', 'Relay - see www.mail-abuse.org/rss/')
Header checking
Header checking is a powerful spam-fighting mechanism that makes use of the low-level sendmail configuration file syntax, which we do not cover in this edition of UNIX System Administration Handbook. By using header checking, sendmail can look for patterns in headers (e.g., “To: friend@public.com”) and reject messages before they are delivered to your users’ mailboxes.
Header checking can also be used to recognize viruses carried by email provided that they have a distinctive header line. For example, the Melissa virus of 1999 contained the subject line “Important Message From ...”. Within hours of the Melissa virus being released and recognized, sendmail.com posted a local ruleset to identify it and discard it. When the fingerprint of a virus is distinctive and easy to express in sendmail rules, sendmail.com typically posts a fix for it (at both the sendmail.com and sendmail.org web sites) very quickly.
For a representative sample of filtering rules for spam and viruses, see the sendmail configuration for Eric Allman’s home machine, knecht. This configuration is included in the sendmail distribution as cf/cf/knecht.mc. Steal the spam-filtering rules and add them to the end of your .mc file.
In looking at various examples, we have seen header checking rules for
• Mail addressed to any user in the domain public.com
• Mail addressed to “friend” or “you”
• Mail with the X-Spanska header, which indicates the Happy99 worm
• Mail with subject “Important Message From ...” (the Melissa virus)
• Mail with subject “all.net and Fred Cohen ...” (the Papa virus)