Configuring Sendmail to Reject Unsolicited Mail

You can set up Sendmail so that unsolicited or spam mail (mail sent to large number of users) is not transmitted to or received by users on the network.

The first step in configuration is to enable the anti-spamming rulesets. You then edit other configuration files to control mail transmission. This section describes how to:

Accept or reject mail from particular senders
Prevent your machine from being used as a relay machine
Accept or reject connections from specific users’ host names based on domains or IP addresses
Enable or disable mail transfers from specific senders and recipient pairs

The anti-spamming features enable you to control the users who can send, receive, or relay mail messages on the network. This section discusses the following topics:

Enabling Anti-Spamming Security Features

You must run the gen_cf script to turn on relaying, validating, and checking features.

The access database also allows you to control the message flow. See the section “Using the Access Database to Allow or Reject Mail Messages” for more information.

Running the gen_cf Script

Follow these steps to run the gen_cf script:

Log in as root.
Go to the directory that contains the script:
cd /usr/newconfig/etc/mail/cf/cf/gen_cf
Run gen_cf.
A list of options is displayed. Select the appropriate option.

A message is displayed to inform you when the file is successfully built.

Using the Access Database to Allow or Reject Mail Messages

You can control the flow of mail messages coming in from certain domains. The Access Database enables you to allow or reject mail from specific domains. By default, names listed in the database as OK are domain names, not host names.

Following are the steps to allow or reject messages:

Create an access database text file.
Create a database map.

You must understand a few basic facts about the Access Database format and structure before creating the Access Database file or database map.

Access Database Format

This section includes a few key points about the database and describes the format of the database.

Every line of the access database file has a key and a value pair.
The value part of the database can be any of the values listed in Table 2-3 “Access Database Format”.

The key can be an IP address, a domain name, a host name or an e-mail address.

Table 2-3 Access Database Format

Value	Description
`OK`	Accepts mail even if other rulesets rejects it. For example, if the domain name is unresolvable.
`RELAY`	Accepts mail addressed to the specified domain or received from the specified domain for relaying through your SMTP server. RELAY also serves as an implicit OK for the other checks.
`REJECT`	Rejects the sender or recipient with a general-purpose message.
`DISCARD`	Discards the message completely using the $#discard mailer delivery agent. This only works for sender addresses. That is, it indicates that you must discard anything received from the specified domain.
`### "any text"`	Where `###` is an RFC 821-compliant error code and “`any text`" is a message to return for the command.
ERROR: ### “any text”	Same as stated for ### “any text”, but useful to mark error messages
ERROR:D.S.N:### “any text”	Same as stated for ### “any text”. D.S.N is an RFC 1893-compliant error code.

Creating the Access Database Text File

You must edit the Access Database text file manually. The default Access Database file is /etc/mail/access. However, you can specify another file in the sendmail.cf file.

Table 2-4 “Access Database Text File Example” contains a sample access database file, /etc/mail/access.

Table 2-4 Access Database Text File Example

`cyberspammer.com`	`550 We don’t accept mail from spammers`
`okay.cyberspammer.com`	`OK`
128.32	`RELAY`
`spammer@aol.com`	`REJECT`
192.168.212	`DISCARD`

In the example Access Database text file, all mail messages from the cyberspammer.com domain are rejected and the error message 550 We don’t accept mail from spammers is displayed. All mail messages from the okay.cyberspammer.com domain are accepted. Messages can be relayed through 128.32. All mail messages from spammer@aol.com are rejected. All mail messages from the 192.168.212 domain are discarded.

Creating Finer Spam Control Using Tags

You can also tag entries in the access map based on their type. The following tags are available:

Connect: connection information (${client_addr}, ${client_name})
From: sender
To: recipient

When the required item is looked up in a map, it is tried with the corresponding tag in front, then without any tag (as fallback to enable backward compatibility). 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

Creating the Database Map

After creating the Access Database text file, you must use the /usr/sbin/makemap utility to create the database map. Type the following command to create the database:

makemap dbm /etc/mail/access < /etc/mail/access

The makemap utility takes /etc/mail/access file as input. It then stores the results back into the /etc/mail/access.db file.

Enabling Anti-Spamming Relay Features

The gen_cf shell script distributed with Sendmail enables you to turn on one or more of the following anti-spamming relay features:

Promiscuous Relay: Relaying from Any Host to Any Host
Relay Entire Domain: Relaying from Any Host in the Domain
Relay Hosts Only: Relaying from Hosts Only
Relaying Based on MX Records
Relay from Local
Check Loose Relay

Promiscuous Relay: Relaying from Any Host to Any Host

Promiscuous relay allows you to configure your site to allow mail relaying from any one site to any other site. This feature is not enabled by default.

You can enable promiscuous relay by choosing it as an option when running the gen_cf script distributed with Sendmail. When you enable this option, Sendmail does not check for relaying. Spammers may then relay mail through your site.

Relay Entire Domain: Relaying from Any Host in the Domain

By default, only hosts listed as RELAY in the Access Database are allowed to relay messages. The hosts must be defined in the m class ($=m) macro to relay. However, this feature allows any host in your domain to relay mail messages.

Relay Hosts Only: Relaying from Hosts Only

By default, host names that are listed as RELAY in both the Access Database and the class R ($=R) macro can relay messages. When using this feature, specify host names. This feature enables Sendmail to look up individual host names and relay messages to the host.

See “Checking Headers” for information on using the R class.

Relaying Based on MX Records

This feature allows relaying based on the MX records of the host portion of an incoming recipient. If an MX record for host foo.com points to your site, you will accept and relay mail addressed to foo.com.

Relay from Local

With this feature, a sender who is a valid user on a particular host can relay messages to other users on different hosts.




	IMPORTANT: Use caution when using this feature. Using this feature opens a window for spammers. Specifically, spammers can send mail to your mail server that claim to be from your domain (either directly or via a routed address), and your machine will relay it out to any hosts on the Internet.

Check Loose Relay

This feature turns off the default behavior, which rechecks all recipients using % addressing. For example, if the recipient address is user%site@othersite, and othersite is in class R macro, Sendmail strips the @othersite portion and rechecks user@site for relaying.

Validating Senders

Sendmail provides a stringent check of mail message senders to ensure that they are legitimate. Sendmail refuses mail if the MAIL FROM: parameter has an unresolvable domain. You can work around this. If you want to continue accepting mail from such domains, use the features described in this section. You can enable any of the following features when you run the gen_cf script:

Accept Unresolvable Domains
Accept Unqualified Senders
Blacklist Recipients
Realtime Blackhole List

Accept Unresolvable Domains

This feature enables Sendmail to accept all MAIL FROM: parameters that are not fully qualified, for example, a mail message whose host part of the argument to the MAIL FROM: parameter cannot be located in the host name service, such as DNS.

Accept Unqualified Senders

This feature allows you to accept all mail where the sender’s mail address does not include a domain name.

Normally, the MAIL FROM: commands in the SMTP session are refused if the connection is a network connection and the sender address does not include a domain name.

Blacklist Recipients

This feature enables Sendmail to block incoming mail messages destined for certain recipient user names, host names, or addresses. This feature also restricts you from sending mail messages to addresses with an error message or REJECT value in the Access Database file.

Example 1

For example, given the following entries in the Access Database file:

`badlocaluser`	`550 Mailbox disabled for this username`
`host.mydomain.com`	`550 That host does not accept mail`
`user@otherhost.mydomain.com`	`550 Mailbox disabled for this recipient`

Recipient of badlocaluser@mydomain.com, any user at host.mydomain.com, and the single address user@otherhost.mydomain.com will not receive mail.

Example 2

spammer@aol.com       REJECT
cyberspammer.com        REJECT

Mail cannot be sent to spammer@aol.com or to anyone at cyberspammer.com.

Realtime Blackhole List

This feature rejects hosts listed in the Realtime Blackhole List, which is found in the Realtime Blackhole List server. The server is blackholes.mail-abuse.org.To use this feature, you must add the following line to the DNS database:

1.5.5.192.blackholes.mail-abuse.org IN A 127.0.0.2

You can specify the Realtime Blackhole List servers in the sendmail.cf file.

Checking Headers

With header checking, you can reject mail messages based on the contents of their mail headers. Sendmail provides the syntax for limited header syntax checking. A configuration line of the form: HHeader: $>Ruleset causes the specified ruleset to be invoked on the header when read. Following is an example of header checking:

Validity of a Message-ID: header
#LOCAL_RULESETS
HMessage-Id: $>CheckMessageId
SCheckMessageId
R< $+ @ $+ >            $@ OK
R$*                     $#error $: 553 Header Error

If the previous lines are included in the sendmail.cf file, then all header messages of the form Message-Id: will call the ruleset SCheckMessageID, which checks for the validity of the Message-Id header.

Discard Mailer

Sendmail has defined a special internal delivery agent called discard. You can use this agent with the header-checking ruleset and check rulesets: check_mail, check_rcpt, check_relay, or check_compat.

If any of the check rulesets (check_mail, check_rcpt, check_relay, or check_compat) or the header-checking ruleset resolves a mail address to the $#discard mailer, then all the SMTP commands are accepted, but the message is discarded. If only one of message recipients address resolves to the $#discard mailer, none of the recipients will receive the mail message.

Regular Expressions

You can use regular expressions with the new map class regex. Use the regex map to see if an address matches a certain regular expression. By using such a map in a check rulesets (check_mail, check_rcpt, check_relay, or check_compat), you can block a certain range of addresses that would otherwise be considered valid.

For example, if you want to block all senders with all numeric user names, such as 2312343@bigisp.com, you would use SLocal_check_mail and the new regex map:

#LOCAL_CONFIG
 Kallnumbers regex -a@MATCH ^[0-9]+$
 LOCAL_RULESETS 
 SLocal_check_mail          # check address against\
                             various regex checks
 R$*                        $:  $>Parse0 $>3 $1 
 R$+ < @ bigisp.com.  >48   $:  $(allnumbers $1 $)
 R@MATCH                    $#error $:553 Header Error

Defining Hosts Allowed to Relay: Class R

You can use the $=R macro to define the hosts that are allowed to relay. The default file Sendmail uses to read values for the $=R macro is /etc/mail/relay-domains.

Queue Changes

This section describes miscellaneous enhancements to the queue option:

The queue option allows multiple -qI, -qR, or -qS queue run limiters.
For example, using Sendmail -qRfoo -qRbar will deliver mail to recipients with foo or bar in their address.
The map flag -Tx appends x to lookups that return temporary failure. This is similar to the -ax flag, which appends x to lookups that return success.
The QueueSortOrder option is case sensitive.

Spam Control Using the Message Submission Agent (RFC 2476)

Sendmail supports RFC 2476, a protocol for message submission. The anti-spam rulesets have been enhanced to improve the anti-spam capabilities. The RFC proposes a new standard for the Message Submission Agent (MSA). This is designed to replace the more general-purpose Mail Transfer Agent (MTA) as the first service to which a Mail User Agent (MUA) connects to deliver a mail message. The RFC also describes how the usual protocols for SMTP service must be tightened up at the point where mail enters the system, rather than being routed from one site to another. Sendmail also serves as a powerful tool to authenticate and control mail messages.

By default, MSA is defined in the sendmail.cf file as:

O DaemonPortOptions=Name=MSA, Port=587, M=E

where Port 587 is reserved for e-mail message submission.

An MSA still uses the same rulesets for processing the message (and therefore still allows message rejection via the check rulesets). In accordance with the RFC, the MSA ensures that all domains in the envelope are fully qualified if the message is relayed to another MTA. It also enforces the normal address syntax rules and log error messages. In addition, you can request authentication before the messages are accepted by MSA by using the M=a modifier in the DaemonPortOptions.




	NOTE: You can turn off MSA in the `sendmail.cf` file using the option, `no_default_msa` in the `gen_cf` script. For more information, see the `no_default_msa` option in “Modifying the Default Sendmail Configuration File”. The XUSR SMTP command and the `-U` (initial user submission) command-line option are deprecated. Mail user agents must use the MSA (Message Submission Agent) for initial user message submission. XUSR may be removed in future releases. The next release of Sendmail will assume that any message submitted from the command line is an initial user submission and act accordingly.

Sendmail Validation

The check_compat ruleset compares all sender and receiver pairs before mail is delivered. It validates the mail based on the results of the comparison. It checks to see if host A can legally send a message to host B. check_compat is called for all mail deliveries, not just SMTP transactions.

check_compat is used in the following situations:

A set of users who are restricted from sending mail messages to external domains need to send mail messages to internal domains. Both the sender and recipient addresses are checked to ensure that they are in the local domain.
A particular user needs to ensure that he or she does not receive mail messages from a specific source.
A particular host needs to ensure that external senders do not use that host as a a mail relay. The mail messages are screened based on the sender’s host name.