Add an entry to the /etc/mail/access text file for each recipient who should be allowed to receive junk mail. Use the tag Spam: and the recipient address to create the key field of the entry. Use the keyword FRIEND as the return value for each entry. Run makemap to build a hash type database from the text file.

Create a sendmail configuration containing the access_db feature and the delay_checks feature with the optional friend argument. Make sure that the access_db FEATURE macro precedes the delay_checks FEATURE macro in the configuration. Here are the lines that would be added to the sendmail configuration:

dnl Use the access database

FEATURE(`access_db')

dnl Check for spam friends before rejecting the mail

FEATURE(`delay_checks', `friend')

Rebuild the sendmail.cf file, copy the new sendmail.cf file to /etc/mail, and restart sendmail

Someone on your system—the postmaster, a security expert, a developer writing mail filters—might need to receive junk mail that is normally blocked by sendmail. The delay_checks feature allows this by changing the order in which spam checks are applied. The delay_checks feature allows the envelope recipient address to be checked before the envelope sender address or the connection address, which, in turn, makes it possible for mail addressed to specific recipients to bypass the other two checks. To use the delay_checks feature in this way, it must be invoked with the friend argument, as shown in the Solution section.

The specific recipients allowed to receive junk mail are defined in the access database using the Spam: tag and the FRIEND return value. Here is an example access database:

Connect:example.com                  REJECT

Spam:uce@wrotethebook.com            FRIEND

Spam:clark+junk@wrotethebook.com     FRIEND

Given the sendmail configuration described in the Solution section, this access database rejects mail from example.com unless it is addressed to uce@wrotethebook.com or to clark+junk@wrotethebook.com.

Run the auth service (identd) to provide account information that cannot be hidden by masquerading or other email techniques.

The IDENT protocol is defined in RFC 1413, Identification Protocol. The protocol provides a means for determining the identity of the user who initiated a network connection. The identd daemon implements the IDENT protocol on Unix systems. Run identd to provide additional information to remote system administrators to aid them in tracking down the cause of problems. In the context of sendmail, this information might help them track down a spammer, if one sets up shop on your system. For example, assume a user on a system running identd tries to perpetrate a forgery by issuing the SMTP EHLO command using a false hostname:

ehlo www.ora.com

250-rodent.wrotethebook.com Hello IDENT:r+9Gemj2wip8fAJDU8kDZlyUiReTZjYc@chef.

wrotethebook.com [192.168.0.8], pleased to meet you

When the remote system, in this case rodent.wrotethebook.com, responds to the EHLO command, it ignores the forged www.ora.com hostname. Instead it says “hello” to the host it finds at the connection address 192.168.0.8. It responds with the hostname associated with that address, which is chef.wrotethebook.com, and the identification information provided by the identd service running on chef. This information is propagated in the mail in a Received: header, as shown below:

Received: from www.ora.com

(IDENT:r+9Gemj2wip8fAJDU8kDZlyUiReTZjYc@chef [192.168.0.8])

by rodent.wrotethebook.com (8.12.9/8.12.9) with ESMTP id gB4N6T301540

for <craig@rodent.wrotethebook.com>; Wed, 4 Dec 2002 18:06:40 -0500

The information provided by the identd service running on the host at 192.168.0.8 identifies the user who sent the mail. The string provided by identd, r+9Gemj2wip8fAJDU8kDZlyUiReTZjYc in the example, is not a simple username. In this case, the identd information is encrypted.

identd monitors port 113. When identd is running, the remote server can request information about any TCP connections from your server to the remote server by sending the source and destination port pair to the identification server. identd then responds by sending either the requested information associated with the connection or an error. This information allows remote mail servers to put a real username on the Received: header in incoming email. People who abuse the mail system do not like to have their real usernames known. Providing their names to their victims makes it hard for them to stay in business. Unfortunately, many firewalls block port 113 because the security people fear that too much information is given out by the identd service. This fear is unfounded when the identd information is encrypted, as it is in this example. However, many security administrators prefer to play it safe, so they block the port. If it is blocked at your firewall, you might not be able to use identd.

The IDENT protocol is also known by the service name auth, as this grep of /etc/services shows:

$ grep ^auth /etc/services

auth    113/tcp    ident   # User Verification

Most sendmail administrators prefer to call the service ident or identd to avoid confusing it with the ESMTP AUTH keyword. Additionally, identd is not an authentication tool—it is an auditing tool. Real spammers, who control their own systems, can put anything they want in an identd response, so the response cannot be trusted for real authentication. You, however, are not a spammer. You run identd to provide additional audit trail information to track down users who abuse your system.

Many Unix systems run identd on-demand from inetd or xinetd. The following line added to inetd.conf would implement ‘blocking spam with the access database’ on a system using inetd and an on-demand identd service:

auth stream tcp nowait nobody /usr/sbin/in.identd in.identd -t120

This, of course, is just an example. You would need to customize the program pathname and the command-line arguments to fit your system and your needs. You should also check the identd manpage for options that prevent the user from disabling identd.

Some other Unix systems run identd as part of the system startup process. Our sample Red Hat Linux system is an example. A chkconfig command adds identd to the boot process, and a service command starts identd immediately:

# chkconfig --list identd

identd          0:off   1:off   2:off   3:off   4:off   5:off   6:off

# chkconfig --level 35 identd on

# chkconfig --list identd

identd          0:off   1:off   2:off   3:on    4:off   5:on    6:off

# service identd start

Generating ident key:                                      [  OK  ]

Starting identd:                                           [  OK  ]

The first chkconfig command shows that identd is not included in the boot process on this sample Linux system. The second chkconfig command adds it to the startup process for run levels 3 and 5—the run levels associated with networked, multiuser operation on most Linux systems. The final chkconfig command shows the effect of this change. Of course, there is no reason to reboot the system just to start identd, so the service command is used to run the identification service immediately.

This is the first time that identd has been started on this server. Notice the first line of output from the service command. It tells us that a key is being generated for identd. This key is used to encrypt the information sent to the remote system. The administrators of the remote system cannot decrypt the information because they do not have the key. If they suspect a problem, they must send you the encrypted string, which you can then decrypt using the /etc/identd.key file and the idecrypt command. The information from the identd server is encrypted for security reasons. Security people dislike identd because it exposes information about systems and users that can be misused by spammers and intruders. Encrypting the identd response allows you to run the identification daemon without any significant security risks.

For example, the Received: header shown earlier in this section displays the 32 character, BASE64 encoded string r+9Gemj2wip8fAJDU8kDZlyUiReTZjYc that the remote system received from our sample system in response to the IDENT query. This does not provide any information that can be exploited by a spammer or an intruder, but it can be used by you to obtain information about the local user who sent the mail. When the remote system administrator contacts you with a problem report, obtain the 32-byte string, enclose it in square brackets, and decode it with the idecrypt command, as shown:

# idecrypt 

[r+9Gemj2wip8fAJDU8kDZlyUiReTZjYc] 

Wed Dec  4 17:00:24 2002 500 192.168.0.8 1029 192.168.0.3 25  Ctrl-D 

The decoded string provides:

• The date and time the connection was made
• The UID of the user who initiated the connection (500 in this example)
• The IP address of the source of the connection (192.168.0.8)
• The source port (1029)
• The destination IP address (192.168.0.3)
• The destination port of the connection (25, which is the SMTP port)

All of this information is useful in tracking who is abusing your system. However, identd does have major limitations. It only returns a useful UID if the user actually logs into your system. If it is being misused in some other way, the information provided might not be useful. Additionally, running identd adds some processing overhead to each piece of mail. As with most things, identd has both pluses and minuses.

On our sample Red Hat Linux system, the identd service is preconfigured in the /etc/identd.conf file. Additionally, the identd service can be configured from the command line using command-line options. On a Red Hat Linux system, the identd command-line options used during startup are defined as values for the IDENTDOPTS variable in the /etc/sysconfig/identd file. See the identd manpage for specifics on the identd.conf configuration commands and the command-line options.

Add custom code to the end of the master configuration file. Add the K command that defines the regular expression to the local information section of the sendmail.cf file using the LOCAL_CONFIG macro, and use a LOCAL_RULESETS macro to add a custom ruleset to access the regular expression. The Discussion section provides an example of how these commands are used.

Build the sendmail.cf file, copy it to /etc/mail/sendmail.cf, and restart sendmai.

Regular expressions are defined using the sendmail.cf K command, which is the same command used to define a database. The regular expression is then accessed from within the configuration in the same manner as a normal database. The following example taken from the knecht.mc file, illustrates how a regular expression is defined and used:

LOCAL_CONFIG

#

#  Regular expression to reject:

#    * numeric-only localparts from aol.com and msn.com

#    * localparts starting with a digit from juno.com

#

Kcheckaddress regex -a@MATCH

^([0-9]+<@(aol|msn)\.com|[0-9][^<]*<@juno\.com)\.?>

LOCAL_RULESETS  SLocal_check_mail

# check address against various regex checks

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

R$+                             $: $(checkaddress $1 $)

R@MATCH                         $#error $: "553 Header error"

First, the LOCAL_CONFIG macro is added to the m4 master configuration file. The LOCAL_CONFIG macro marks the start of code that is to be added to the local information section of the sendmail.cf file. The K command that defines the regular expression follows this macro. The syntax of the K command is:

Kname type arguments

where K is the command, name is the internal name used to access the database defined by this command, type is the database type, and the arguments define the database being used. The arguments have the format:

flags description

where the flags define options used by the database and description identifies the database being used. The description, in most cases, is a path to an external database, either a local database or a map accessible through a database server. For a regular expression, however, the description is the definition of the regular expression against which input data is matched. The K command in the example is:

Kcheckaddress regex -a@MATCH     ^([0-9]+<@(aol|msn)\.com|[0-9][^<]*<@juno\.com)\.?>

In this example:

• K is the command.
• checkaddress is the internal name.
• regex is the type.
• -a@MATCH is a flag that tells sendmail to return the value @MATCH when a match is found.
• ^([0-9]+<@(aol|msn)\.com|[0-9][^<]*<@juno\.com)\.?> is a regular expression. This is a basic regular expression that could be used with tools such as egrep and awk. This regular expression matches email addresses from aol.com, msn.com, and juno.com that contain numeric usernames.

The K command defines the regular expression, but a rewrite rule is needed to use it. The LOCAL_RULESETS macro is used to insert a custom ruleset into the sendmail.cf file. At the heart of the sample Local_check_mail ruleset are three R commands:

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

R$+                             $: $(checkaddress $1 $)

R@MATCH                         $#error $: "553 Header error"

The address passed to the Local_check_mail ruleset is first processed through ruleset 3 (also called the canonify ruleset), and the result of that process is then passed through the Parse0 ruleset. Note that both of these rulesets are called by the first rewrite command. This processing puts the address into its canonical form. The address is then pattern matched against the checkaddress regular expression by the second rewrite rule. If it matches the regular expression, the address is replaced by the string @MATCH. The third rewrite rule checks to see if the workspace contains that string. If it does, a header error is returned.

A few tests show how the regular expression and the ruleset work:

# sendmail -bt

ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)

Enter <ruleset> <address>

> Local_check_mail 123@aol.com

Local_check_mail   input: 123 @ aol . com

canonify           input: 123 @ aol . com

Canonify2          input: 123 < @ aol . com >

Canonify2        returns: 123 < @ aol . com . >

canonify         returns: 123 < @ aol . com . >

Parse0             input: 123 < @ aol . com . >

Parse0           returns: 123 < @ aol . com . >

Local_check_mail returns: $# error $: "553 Header error"

> Local_check_mail win@aol.com

Local_check_mail   input: win @ aol . com

canonify           input: win @ aol . com

Canonify2          input: win < @ aol . com >

Canonify2        returns: win < @ aol . com . >

canonify         returns: win < @ aol . com . >

Parse0             input: win < @ aol . com . >

Parse0           returns: win < @ aol . com . >

Local_check_mail returns: win < @ aol . com . >

> /quit

The first test passes the address 123@aol.com to the Local_check_mail ruleset. This address should match the checkaddress regular expression. The error returned by the Local_check_mail ruleset shows that it does. The second test is run to show that valid addresses from aol.com do not generate the error.

This example, taken from the knecht.mc file, is not a recommendation that you filter out numeric aol.com addresses. It is an example of how a regular expression is defined and used. The LOCAL_CONFIG macro, the LOCAL_RULESET macro, and the syntax of the K command are the same for the custom regular expressions and rulesets that you create as they are for this simple example.

Build a mailertable that routes mail bound for specific domains through the procmail mailer.

Create a file in the /etc/procmailrcs directory that defines the specific filtering needed. Multiple filters can be used.

Create a sendmail configuration that enables the mailertable feature and adds procmail to the list of available mailers. Here are the lines that should be added to the sendmail configuration:

dnl Enable support for the mailertable

FEATURE(`mailertable')

dnl Add procmail to the list of available mailers

MAILER(procmail)

Build the sendmail.cf file, copy it to /etc/mail/sendmail.cf

The MAILER(procmail) macro adds the procmail mailer definition to the sendmail.cf file. The procmail mailer is not related to the local_procmail feature. A system can use the procmail mailer without using procmail as a local mailer, and procmail can be used as a local mailer without adding the MAILER(procmail) macro to the configuration.

The MAILER(procmail) macro does not add any code to the configuration to use the procmail mailer. You must either add custom sendmail.cf rules to reference the mailer, or route mail through the procmail mailer using the mailertable. Using the mailertable is the easiest and the recommended way to access the mailer. Here we add mailertable entries that invoke procmail:

# cd /etc/mail 

# cat >> mailertable 

example.com       procmail:/etc/procmailrcs/spam-filter

wrotethebook.net  procmail:/etc/procmailrcs/spam-filter

fake.ora.com      procmail:/etc/procmailrcs/uce-filter  

Ctrl-D 

# makemap hash mailertable < mailertable 

The example adds three entries to the mailertable that route mail through the procmail mailer. The first field in a mailertable entry is the key against which the recipient address is matched. The second field is the mailer value and the host value that sendmail uses to build the mail delivery triple. In this example, mail with a matching recipient address is routed through the procmail mailer. A few tests of a system running show this:

# sendmail -bv crooks@example.com

crooks@example.com... deliverable: mailer procmail, host /etc/procmailrcs/

spam-filter, user crooks@example.com

# sendmail -bv spammers@wrotethebook.net

spammers@wrotethebook.net... deliverable: mailer procmail, host /etc/procmailrcs/

spam-filter, user spammers@wrotethebook.net

# sendmail -bv thieves@fake.ora.com  thieves@fake.ora.com... deliverable: mailer procmail,

 host /etc/procmailrcs/  uce-filter, user thieves@fake.ora.com

When mail is routed to the procmail mailer, the host value ($h) must contain the pathname of the rc-file that procmail should use to filter the mail. In the example above, two different filters, spam-filter and uce-filter, are passed to procmail depending on the destination of the email. sendmail calls procmail from the procmail mailer using the following command:

procmail -Y -m $h $f $u

The -Y flag tells procmail to use the Berkeley Unix mailbox format. The -m flag runs procmail as a general-purpose mail filter. The first argument that follows the -m flag must be the path of the rc-file that contains the procmail filter. sendmail assigns the host value returned by the mailertable lookup to the $h macro, which it then passes to procmail as the first argument after the -m flag. Therefore, the host field of a mailertable entry that uses the procmail mailer must contain the full pathname of an rc-file.

The next two arguments passed to procmail are the envelope sender email address ($f) and the envelope recipient email address ($u). These values are available inside the procmail rc-file as variables $1 and $2, respectively.

One common technique for avoiding a loop is to add the pseudodomain .PROCMAIL to the recipient address when mail is resent to the original recipient. The pseudodomain ensures that the recipient address no longer matches a value in the mailertable, which breaks the loop. The pseudodomain is added by procmail commands in the rc-file. However, a properly configured rc-file is not the complete solution. .PROCMAIL is not a real domain, so code must be added to the sendmail.cf file to ensure that the pseudodomain is properly handled. The following m4 macros and sendmail.cf code, added to the end of the this recipe’s master configuration file, handle the .PROCMAIL pseudodomain, if one is added by the rc-file:

LOCAL_CONFIG

# Add .PROCMAIL to the pseudo-domain list

CP.PROCMAIL

LOCAL_RULE_0

# Strip .PROCMAIL and send via esmtp

R$+ < @ $+ .PROCMAIL . >        $#esmtp $@ $2 $: $1<@$2>

The LOCAL_CONFIG macro marks the start of code that is to be added to the local information section of the sendmail.cf file. In this example, we add a comment and a C command to the local information section. The C command adds .PROCMAIL to class P. Class P lists pseudodomains that sendmail should not attempt to lookup in the DNS. Adding .PROCMAIL to class P avoids the delays and wasted resources that occur when sendmail looks up a domain name that does not exist.

The LOCAL_RULE_0 macro marks the start of sendmail.cf code that is added to ruleset 0—more commonly called the parse ruleset. Specifically, the code that follows the LOCAL_RULE_0 macro is added to the ParseLocal ruleset, which is a hook into the parse ruleset where locally defined rules are addedThe parse ruleset rewrites the delivery address to a mail delivery triple.

The code that follows the LOCAL_RULE_0 macro in the example is a comment and a rewrite rule. The R command matches input addresses of the form user@domain.PROCMAIL, and rewrites those addresses into a mail delivery triple where the mailer is esmtp, the host value is domain, and the user value is user@domain. After rebuilding the configuration with the new master configuration file, running a sendmail -bv test shows the impact of this rewrite rule:

# sendmail -bv crooks@example.com.PROCMAIL

crooks@example.com.PROCMAIL... deliverable: mailer esmtp, host example.com,

user   crooks@example.com

Add the local_procmail feature to the sendmail configuration, placing the FEATURE macro after the OSTYPE macro and before the MAILER(`local’) line in the master configuration file. Values for the local mailer are usually set in the OSTYPE file. Carefully review the file for your operating system. Add the local_procmail feature to your master configuration file only if local_procmail is not already included in the OSTYPE file.

Create an /etc/procmailrc file containing the filters you want to apply to local mail.

Build and install the new configuration

The linux.m4 OSTYPE file contains the local_procmail feature because procmail is the local mailer used by default on most Linux systems. On a Linux system, just running a configuration that uses the linux.m4 OSTYPE file is sufficient. Other systems are not so easy. For example, assume you have a Solaris 8 system. The solaris8.m4 OSTYPE file uses the local_lmtp feature to set mail.local as the local mailer. To change the local mailer to procmail, override the local_lmtp feature by placing the local_procmail feature in the master configuration file. Here is an example based on the generic-solaris.mc file:

VERSIONID(`Solaris with local_procmail added’)
OSTYPE(solaris2)
DOMAIN(generic)
dnl Add the local_procmail feature
FEATURE(`local_procmail’)
MAILER(local)
MAILER(smtp)

Because the local_procmail feature occurs after the OSTYPE macro, it overrides the local_lmtp feature defined in the OSTYPE file. The local_procmail feature is enabled once the sendmail.cf file is built, copied to sendmail.cf, and sendmail is restarted.

When the local_procmail feature is used, sendmail passes local mail to procmail for delivery. procmail processes the mail, first using the commands defined in the /etc/procmailrc file and then using the commands defined in the .procmailrc file in the recipient’s home directory. If no rc file is defined, procmail writes the mail to the user’s mailbox unaltered. Note that the user’s .procmailrc file is applied to mail delivered by the local_procmail feature. When local_procmail is used, it is not necessary for the user to call the procmail program from the .forward file. All the user needs to do is create a .procmailrc file and it will be applied to the mail. Using procmail as a local mailer allows both the system administrator and the user to filter inbound mail with procmail.

When procmail is used as the local mailer, sendmail runs it with three arguments: -Y, -a, and -d. The -Y argument tells procmail to use the standard Berkeley Unix mailbox format. The -d argument provides procmail with the username of the local recipient who is to receive the mail (in the mail delivery triple this is the user value). The -a argument passes an optional value to procmail that is accessible inside the procmail as the $1 variable; in the mail delivery triple, this is the host value. sendmail only passes a value through -a when either the +detail syntax is used or mail is routed to the local mailer via the mailertable. In the case of the +detail syntax, the detail value is passed. In the case of the mailertable, the input address that was the key to the mailertable entry is the value passed. In all other cases, no value is passed by the -a argument and the $1 variable is unassigned.

Add an entry to the /etc/mail/access text file for each recipient whose mail must pass all checks before it is delivered. Use the tag Spam: and the recipient address to create the key field of the entry. Use the keyword HATER as the return value for each entry. Run makemap to build a hash type database from the text file.

Create a sendmail configuration containing the access_db feature and the delay_checks feature with the optional hater argument. Make sure that the access_db FEATURE macro precedes the delay_checks FEATURE macro in the configuration. Here are the lines that would be added to the sendmail configuration:

dnl Use the access databaseFEATURE(`access_db')

dnl Apply all checks to spam hater mail

FEATURE(`delay_checks', `hater')

Rebuild the sendmail.cf file, copy the new sendmail.cf file to /etc/mail, and restart sendmail

The delay_checks feature changes the order in which checks are applied by first checking the envelope recipient address. When the delay_checks feature is invoked with the hater argument, as shown in the Solution section, the envelope recipient address must be found in the access database, and it must return the value HATER before the envelope sender address or the connection address are checked. If the envelope sender address is not found in the access database or does not return the value HATER, the check of the envelope sender address performed by check_mail, and the check of the connection address performed by check_relay, are bypassed.

To apply the check_mail and check_relay checks to a recipient’s mail, the specific recipients must be defined in the access database using the Spam: tag and the HATER return value. Here are example entries:

Connect:example.com                  REJECT

Spam:jay@wrotethebook.com            HATER

Spam:alana@wrotethebook.com          HATER

Using this sendmail configuration, this access database will reject mail from example.com when it is addressed to jay@wrotethebook.com or to alana@wrotethebook.com. Other users are allowed to receive mail from example.com.

Add an entry to the /etc/mail/access text file for each recipient who should be allowed to receive junk mail. Use the tag Spam: and the recipient address to create the key field of the entry. Use the keyword FRIEND as the return value for each entry. Run makemap to build a hash type database from the text file.

Create a sendmail configuration containing the access_db feature and the delay_checks feature with the optional friend argument. Make sure that the access_db FEATURE macro precedes the delay_checks FEATURE macro in the configuration. Here are the lines that would be added to the sendmail configuration:

dnl Use the access database

FEATURE(`access_db')

dnl Check for spam friends before rejecting the mail

FEATURE(`delay_checks', `friend')

Rebuild the sendmail.cf file, copy the new sendmail.cf file to /etc/mail, and restart sendmail

Someone on your system—the postmaster, a security expert, a developer writing mail filters—might need to receive junk mail that is normally blocked by sendmail. The delay_checks feature allows this by changing the order in which spam checks are applied. The delay_checks feature allows the envelope recipient address to be checked before the envelope sender address or the connection address, which, in turn, makes it possible for mail addressed to specific recipients to bypass the other two checks. To use the delay_checks feature in this way, it must be invoked with the friend argument, as shown in the Solution section.

The specific recipients allowed to receive junk mail are defined in the access database using the Spam: tag and the FRIEND return value. Here is an example access database:

Connect:example.com                  REJECT

Spam:uce@wrotethebook.com            FRIEND

Spam:clark+junk@wrotethebook.com     FRIEND

Given the sendmail configuration described in the Solution section, this access database rejects mail from example.com unless it is addressed to uce@wrotethebook.com or to clark+junk@wrotethebook.com.

Add the spam addresses you want blocked to the /etc/mail/access text file. Use To: and From: tags to prevent mail from being sent to spammers or from being accepted from spammers. Run makemap to build a hash database from the text file.

Create a sendmail configuration that enables the access database with the access_db feature. The required sendmail FEATURE command is:

dnl Use the access database

FEATURE(`access_db')

Rebuild the sendmail.cf file, copy the new sendmail.cf file to /etc/mail, and restart sendmail

By default, the access database applies to source addresses. The action defined in the database entry is taken based on the source of the email. For example, mail from anyone at example.com is rejected with an “Access denied” error. However, the access database does not prevent mail from the local host being sent to someone at example.com.

Adding the To:tag to an access database entry applies the action defined in the entry to recipient addresses that match the key, while the From: tag specifically requests that the action be applied to matching source addresses. Here is the access database rewritten with To: and From: tags:

From:example.com          REJECT

To:example.com            ERROR:5.7.1:550 Mail to this site is not allowed

From:wrotethebook.net     ERROR:5.7.1:550 Invalid mail source

To:wrotethebook.net       ERROR:5.7.1:550 Mail to this site is not allowed

From:fake.ora.com         DISCARD

To:fake.ora.com           ERROR:5.7.1:550 Mail to this site is not allowed

Because the action for the From: example.com entry is REJECT, mail from that site is rejected. With the addition of the To: entry, mail addressed to example.com is also rejected, as this test shows:

# telnet localhost smtp

Trying 127.0.0.1...  Connected to localhost.

Escape character is '^]'.

220 chef.wrotethebook.com ESMTP Sendmail 8.12.9/8.12.9; Fri, 22 Aug 2003 12:01:37 -  0400

HELO localhost

250 chef.wrotethebook.com Hello IDENT:UWSRv+Jij66J8vALUBVBECbGPVoU8OQe@localhost   [127.0.0.1], pleased to meet you

MAIL From:<craig@chef.wrotethebook.com>

250 2.1.0 <craig@chef.wrotethebook.com>... Sender ok  

RCPT To:<crook@example.com>

550 5.7.1 <crook@example.com>... Mail to this site is not allowed

QUIT

221 2.0.0 chef.wrotethebook.com closing connection  Connection closed by foreign host.

Alternatives

The blacklist_recipients feature is an alternative way to block outbound mail to known spammers. The blacklist_recipients feature applies every untagged entry in the access database to recipient addresses. The following lines added to the sendmail configuration enable the access database and apply the database to recipient addresses:

dnl Use the access database

FEATURE(`access_db')

dnl Also apply the access database to recipient addresses

FEATURE(`blacklist_recipients')

The blacklist_recipients feature works well, and it is very easy to use. However, because it applies to every untagged entry in the access database, it does not provide the level of configuration control provided by the To: tag. Additionally, tags are self-documenting. Anyone looking at the sample access database just shown understands that mail to example.com is not allowed when they see the To: tag and the error in the action field.

On the sendmail system, create a configuration containing the dnsbl feature. Identify the local DNS blackhole list on the dnsbl command line. Here is an example:

dnl Point dnsbl to our local DNS blackhole list

FEATURE(`dnsbl', `dnsbl.wrotethebook.com')

Rebuild the sendmail.cf file, copy the new sendmail.cf file to /etc/mail, and restart sendmail.

Using a blackhole list service is simple but inflexible because you can’t choose which sites are listed. This means that mail from a friendly site might be blocked just because the administrator at that site misconfigured relaying. For this reason, some organizations decide to build their own DNS-based blackhole list. Creating your own blackhole server ensures that connectivity to all of the sites you want to reach is under your direct control, but it requires both sendmail and DNS expertise.

The DNS administrator uses a zone statement in the DNS server’s named.conf file to load the blackhole database. Assuming that the blacklisted hosts are defined in a zone file named blacklisted.hosts, which provides the data for a domain named dnsbl.wrotethebook.com, the following zone statement would be used:

zone "dnsbl.wrotethebook.com" IN {

type master;

file "blacklisted.hosts";

allow-update { none; };

};

Blackhole entries for addresses 10.0.187.215 and 192.168.0.3 defined in the blacklisted.hosts file would be the following:

215.187.0.10                 IN A 127.0.0.2

3.0.168.192                  IN A 127.0.0.2

The newly created DNS domain is referenced as the source for blackhole list data on the dnsbl feature command line in the Solution section. Mail from any site listed in the dnsbl.wrotethebook.com domain is rejected, as this attempt to send mail from 192.168.0.3 shows:

# telnet chef smtp

Trying 192.168.0.8...

Connected to 192.168.0.8.

Escape character is '^]'.

220 chef.wrotethebook.com ESMTP Sendmail 8.12.9/8.12.9; Fri, 22 Aug 2003 12:01:37 -  0400

helo rodent.wrotethebook.com

250 chef.wrotethebook.com Hello rodent.wrotethebook.com [192.168.0.3], pleased to   meet you

MAIL From:<craig@rodent.wrotethebook.com>

550 5.7.1 Rejected: 192.168.0.3 listed at dnsbl.wrotethebook.com

QUIT

221 2.0.0 chef.wrotethebook.com closing connection  Connection closed by foreign host.

The connection address 192.168.0.3 is found in the dnsbl.wrotethebook.com domain, so our server rejects the mail and returns the error message “550 5.7.1 Rejected: 192.168.0.3 listed at dnsbl.wrotethebook.com.” This default error message can be changed with an additional argument on the dnsbl feature command line. For example, the command:

FEATURE(`dnsbl', `dnsbl.wrotethebook.com', `"Mail rejected. "$&{client_addr}" is a   suspected spam relay."')

changes the error message to “Mail rejected. 192.168.0.3 is a suspected spam relay.” However, the standard message works well and provides the remote site with more information.

The small number of systems used in the blackhole list could much more easily have been handled by the access database. In most cases, using the access database to block unwanted mail connections is much easier than creating your own blackhole list. Creating and maintaining your own blackhole list is labor intensive. The systems that should be added to and removed from the list are constantly changing. Additionally, a great deal of information is needed to initially build a list. It is possible to use a mail filtering tool, such as procmail, to automatically collect suspected addresses directly from mail. However, it is difficult to create a system that collects the right information and keeps it up-to-date. Most administrators prefer to create their own blackhole list based on the blackhole list provided by a blackhole list service. The services already have large lists and they constantly maintain them. Most blackhole list services provide some way to download the entire list. For example, the DSBL list can be downloaded using rsync:

# rsync rsync.dsbl.org::dsbl/bind-list.dsbl.org.

Periodically downloading a list and customizing it is one way to create your own blackhole list. But even if you start with a preexisting list, creating your own blackhole list is not a task that should be undertaken lightly. Creating your own blackhole list is one of the most difficult techniques for controlling unwanted junk email.

As usual, the choice between using a blackhole list service or building your own blackhole list is a choice between simplicity and flexibility. Most sites choose simplicity. If you don’t have the available staff necessary to build and maintain your own blackhole list, stick with a standard blackhole list service.

dnl Use the DSBL blacklist service

FEATURE(`dnsbl', `list.dsbl.org')

Rebuild the sendmail.cf file, copy the new sendmail.cf file to /etc/mail, and restart sendmail.

The dnsbl feature adds the sendmail.cf code needed to enable a DNS blacklist service. The dnsbl feature uses a K command to define the dnsbl database as a host type database, which means lookups in dnsbl are really passed to DNS for resolution.The dnsbl feature also adds a few rules to the Basic_check_relay ruleset, which is called from the check_relay ruleset. The added rules lookup the connection address in the dnsbl database. If the connection address is found in the database, mail from that address is rejected with an error message. If the connection address is not found in the dnsbl database, the mail is passed on for further processing. A sendmail -bt test shows the impact of the added rewrite rules:

# sendmail -bt

ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)

Enter <ruleset> <address>

> .D{client_addr}192.168.111.68

> Basic_check_relay <>

Basic_check_rela   input: < >

Basic_check_rela returns: $# error $@ 5 . 7 . 1 $: "550 Rejected:

" 192 . 168 . 111 .  68 " listed at list.dsbl.org"

> /quit

Because there is no active connection—this is just a test—the first step is to statically define a connection address for the test. Next, the Basic_check_relay ruleset is called and passed to an empty workspace. The workspace passed to the ruleset in this test is unimportant because the first rule added to the ruleset by the dnsbl feature unconditionally replaces the workspace with the value found in ${client_addr}. Therefore, the value looked up in the dnsbl database is the connection address stored in the ${client_addr} macro. In this test, the address 192.168.111.68 is found in the blackhole list maintained at list.dsbl.org, so mail from that address is rejected. The mail is rejected with the error message:

550 Rejected: 192.168.111.68 listed at list.dsbl.org

The error message displays the address that was rejected and the service that recommended the rejection. This information is important. The administrators at 192.168.111.68 might need to contact the blackhole service to find out why their system is blacklisted and what they can do to get it removed from the blackhole list. Often, a system is blacklisted because of a configuration error that creates an open relay. As soon as the error is fixed, the administrator wants to get the system removed from the blackhole list. Knowing which services have blacklisted the system tells the administrator which services must be contacted to get full mail service restored.

This configuration uses the blackhole server at list.dsbl.org because that is the service specified with the dnsbl feature command, which is just an example; it is not a recommendation for the list.dsbl.org service. There are many blackhole services available. Go to each service’s web site and evaluate their policy for listing hosts in the database. Select the service whose policy most closely matches the policy you want to enforce on your server.

When no service is specified on the dnsbl feature command line, sendmail defaults to using blackholes.mail-abuse.org, which is the same service that was used by the deprecated sendmail rbl feature.

The enhdnsbl feature could be used as an alternative to dnsbl. However, the enhdnsbl feature provides no real advantage in this particular case.