Using Anti Spam Rewrite Rules

Most administrators think of sendmail rewrite rules as a way to modify addresses on outbound e-mail that originates on the local system in the user's mailer. The anti-spam rulesets allow you to process the addresses and headers from incoming mail. sendmail provides three anti-spam rulesets specifically for your personal rules:

Local_check_relay A ruleset in which you can define rules for handling mail that is being relayed

Local_check_rcpt A ruleset in which you can define rules to process inbound mail based on the recipient address

Local_check_mail A ruleset in which you can define rules to process inbound mail, based on the sender address

Suppose that you have been receiving junk mail that is trying to masquerade as local mail by using a From address that contains only a username. Further, assume that you have configured your mail server so that the From address of local mail always includes the hostname. You could use Local_check_mail to check the sender address, as shown in Listing 11.7.

Listing 11.7: A Local_check_mail Example

SLocal_check_mail # Check for [email protected] [email protected]$+ [email protected]$#OK

The first line in this example is an S command that defines the ruleset named Local_check_ mail. The first R command matches the incoming address against the pattern $+ @ $+, which looks for one or more tokens ($+), a literal at sign (@), and one or more tokens. Any address in the form of [email protected] matches this pattern. The transformation says that if the address matches the pattern, exit the ruleset ([email protected]) and return the mailer name $#OK to the calling ruleset. ($#OK is a phony mailer used to indicate that the address is valid.)

The second R command matches every address that failed to match the first rule. For all of these addresses, the rule returns the mailer name $#error and the text of an error message. The $#error mailer is a special mailer that returns the mail to the sender along with an error message. An alternative to this would be the $#discard mailer, which silently discards the mail. Most administrators prefer to return an error message.

In addition to these rulesets, you can call a ruleset from a header definition to check the format of the headers your system receives. Sometimes spammers use malformed headers that indicate the mail is spam. Suppose that you get spammed by someone who forgets to create a valid-looking Message-ID header. You could use code such as the code shown in Listing 11.8.

Listing 11.8: An Example of Creating a Local Ruleset


HMessage-Id: $>check_MID_header

The LOCAL_RULESETS section contains an H command for the file. Unlike the H commands shown in Chapter 5, this one doesn't contain a header format. Instead, it uses the $> syntax to call a ruleset to process the header. This example calls a ruleset named check_MID_ header because that is the name of the new ruleset defined in Listing 11.8.

The Scheck_MID_header command is the first line of ruleset check_MID_header. This ruleset is essentially identical to the one described in the previous example. It checks to make sure that the Message-ID header contains both a unique message identifier and a hostname in the form [email protected] All other formats are rejected as errors.

These rewrite rules are simply examples created to illustrate the way local rulesets are defined and used. They are not applicable to a real configuration. Frankly, developing rewrite rules to fight spam is not widely recommended. First, rewrite rules can be complex and difficult to develop, making the cure worse than the disease. Second, the format of spam mail is constantly changing, making the rule written today useless tomorrow. Most administrators find it better to rely on the blackhole list, the access database, and the ability of the user's mailer to filter mail.

Was this article helpful?

0 0

Post a comment