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 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.

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.