HP OpenVMS Systems Documentation

HP TCP/IP Services for OpenVMS
Management

SPAM is the Internet equivalent of junk mail and is a growing source of annoyance to Internet users. Antispam is a function of SMTP that is designed to inhibit the transmission of spam.

SMTP Antispam is implemented in the SMTP receiver which, for the purposes of this discussion, is called the SMTP server. The following sections describe how to enable and configure SMTP Antispam.

18.6.1 Enabling and Managing SMTP Antispam

To enable and manage SMTP Antispam, create or edit the following file:

TCPIP$SMTP_COMMON:SMTP.CONFIG

The logical name TCPIP$SMTP_COMMON is defined at TCP/IP Services startup. For more information, see Section 18.5.

The SMTP.CONFIG file should be owned by TCPIP$SMTP and protection should be set to (W:RE).

The file SMTP_CONFIG.TEMPLATE is provided to help you create this file; it contains guidelines on how to configure Antispam.

For guidelines about specifying configuration options in the SMTP.CONFIG file, see Section 1.1.5.

18.6.1.1 SMTP Antispam Field Names

Table 18-5 describes the field names and values for Antispam configuration.

.

The following sections provide further information about the configuration options.

18.6.2 Preventing Spam Route-Through

Senders of spam routinely use unaware Internet hosts as route-through hosts for their spam. This illicit use of other SMTP servers is known as SPAM route-through.

Spam mailing lists contain the of addresses and sending a spam takes a great deal of time. Therefore, senders of spam prefer to use hosts other than their own to send the message. The victim is a host not protected by a firewall or by software that is aware of spam. The SMTP client software that generates spam connects to the victim SMTP server host and issues multiple RCPT TO commands, which may number in the thousands. The SMTP client then sends the message to the victim host and closes the link. It is now left to the victim host to do the real work of relaying the spam to the thousands of recipients.

Fortunately, the route-through attack can often be detected. Most or all of the recipients of the spam will not be within the victim's own domains or IP networks. They will be somewhere outside in the expanse of the Internet. You must trap for the situation where an unknown SMTP client is trying to use your system to relay mail to recipients in domains outside its own. If you specify the "known world" and the "unknown world," the SMTP server can detect this type of spam attack.

SMTP allows you to configure two lists:

• Good-Clients, a list of the IP addresses, IP networks, DNS host names, and DNS MX domains of known good SMTP clients.
• Relay-Zones, a list of the SMTP domains to which SMTP will relay mail even if it is from an unknown client.

Together, these lists define the "known good world" to the SMTP server for relay purposes. They are used to prevent spam routing as follows:

1. The SMTP server checks the IP address of the client against the Good-Clients list. If a match occurs, the client is considered "known good" and it is free to use the local system to relay without further checking. However, if no match against the Good-Clients list occurs, the client is considered "unknown" and the process goes to step 2.
2. When the client is unknown, the domain of the address in each RCPT TO command is checked against the Relay-Zones list. If a match occurs, the RCPT TO command is accepted, because it is a relay from the unknown world to the known world (for example, e-mail from the Internet). If a match does not occur, the RCPT TO is considered unacceptable for route-through.
   The SMTP server allows an SMTP client to attempt route-through twice; if a third attempt is made, the SMTP server rejects the RCPT TO command, disconnects the link, and reports a spam event. For more information about spam event reporting, see Section 18.6.7.

If neither Good-Clients nor Relay-Zones is configured, relay checking depends on the setting of the SMTP configuration relay flag. If the relay flag is set, all relays are allowed; if it is not set, relays are not allowed.

To use Good-Clients and Relay-Zones lists, you must still set the SMTP configuration relay flag. Use the following command:

TCPIP> SMTP SET CONFIGURATION/OPTION=RELAY

The Good-Clients list is a comma-separated list of clients, specified as one of the following:

• IP address
• IP network
• DNS hostname
• DNS MX domain

To enter an IP network, use standard CIDR notation (n.n.n.n/m, where n.n.n.n is the IP network and m is the number of bits in the subnet mask). For example:

Good-Clients: 1.2.0.0/16, 2.3.4.0/24,
              2.3.4.5, relay.abc.com

This Good-Clients list contains two IP networks (1.2.0.0 and 2.3.4.0), an IP address (2.3.4.5), and a DNS entry ( relay.abc.com ). An entry that does not follow the standard IP address or network format is assumed to be a DNS entry.

18.6.2.2 Processing DNS Entries in the Good-Clients List

The SMTP server uses the Good-Clients list to match the IP addresses of SMTP clients. Therefore, entries are stored internally as IP addresses. DNS hostname and MX domain entries are stored as IP addresses, determined by the following process:

1. An entry that is not apparently an IP address or IP network is assumed to be a DNS host name, and the matching IP address is stored in the list.
2. For an entry that cannot be resolved as a DNS host name, the SMTP server looks for MX records.

For configurations where the generic mail server name does not have an associated DNS host name, the SMTP server uses the MX records, which specify mail relay hosts. The following example demonstrates this configuration:

TCPIP> show host relay.abc.com
%TCPIP-W-NORECORD, information not found
-RMS-E-RNF, record not found

TCPIP> show mx relay.abc.com

                         BIND MX database

Server:          1.2.3.4          host.abc.com

Gate address     Preference       Gate name

1.3.4.5          100              mail11.abc.com
1.3.5.6          100              mail13.abc.com
2.4.5.6          200              mail2.abc.com
2.4.5.7          200              mail1.abc.com
3.4.5.6          300              mail21.abc.com
3.4.6.7          300              mail12.abc.com

To include the addresses listed as MX gateways in this example, enter relay.abc.com in the Good-Clients list.

18.6.2.3 Mail Relay to MX Gateways

You can configure the SMTP server to relay mail from an unknown SMTP client to a domain that does not match the entries Relay-Zones but that has an MX record naming the local host as an MX gateway. To enable this feature, set the Relay-Based-On-Mx option to TRUE in SMTP.CONFIG.

For example, the Relay-Zones list is not specified on example host VMShost.abc.com . When an unknown host tries to relay mail to podunk.def.com through VMShost, and the Relay-Based-On-Mx option is enabled, the SMTP server on VMShost searches for MX records for podunk.def.com . If one of PODUNK's MX records lists VMShost as the MX gateway, the relay is accepted, even though the SMTP client is unknown and the RCTP TO address did not match the Relay-Zones list.

18.6.2.4 Specifying the Relay-Zones List

The Relay-Zones list specifies the domains to which the SMTP server will relay mail from unknown SMTP clients. Do not use wildcards in the entries in this list; wildcarding is implicit (that is, *.domain is implied). For example:

Relay-Zones: def.com,
        abc.com,
        company.com

This example specifies the relay of mail from unknown SMTP clients to any host within the def.com , abc.com , or company.com domain. Because of implied wildcarding, domains like VMShost.abc.com match against this list.

18.6.2.5 Examples of Specifying Good-Clients and Relay-Zones

In the following examples, host.abc.com is the host, and Good-Clients and Relay-Zones lists are configured as follows:

Good-Clients: 1.2.0.0/16, 2.3.0.0/16, relay.abc.com
Relay-Zones:  def.com, abc.com, company.com

The Good-Clients list specifies clients whose IP addresses are in the 1.2 or 2.3 subnets or whose IP addresses match the relay.abc.com .

The following examples assume that host.abc.com is not protected by a firewall and has direct Internet connectivity.

1. The following example explains the process of handling a mail message where the client is unknown and RCPT TO address is unknown.
   A host with the IP address 2.2.3.5 connects to VMShost's SMTP server. The client sends a RCPT TO address of jones@someplace.else.com . The SMTP server:
   1. Fails to find a matching IP address in the Good-Clients list. The client is considered unknown.
   2. Fails to find the domain of the RCPT TO address in the Relay-Zones list.
   3. The RCPT TO command is rejected with the following message:

      <<<RCPT TO:<jones@someplace.else.com> >>>550 User not local, Relay disabled.

2. This example shows the process of handling a mail message for which the client is unknown but the RCPT TO address is accepted.
   A host with the IP address 2.2.3.5 connects to VMShost's SMTP server. This IP address does not match Good-Clients, so the client is considered unknown.
   However, if the client sends a RCPT TO address of smith@foobar.xxx.def.com , the domain of the RCPT TO address is matched against the Relay-Zones list. The RCPT TO address foobar.xxx.def.com matches the Relay-Zones list, so the RCPT TO command is accepted.
3. In this example, the client with IP address 1.2.1.2 connects to VMShost's SMTP server. This IP address matches Good-Clients (it is in subnet 1.2). Therefore, the client is considered known. The SMTP server does not check the domains of the RCPT TO addresses.

You can configure the SMTP server to automatically reject any mail transactions with specified SMTP clients. To enable this feature, configure the Bad-Clients list in SMTP.CONFIG. The syntax of the Bad-Clients list is the same as the Good-Clients list. For example:

Bad-Clients: 1.2.3.5, 100.101.102.103

If Bad-Clients is configured, the SMTP server checks the IP address of the client against the list. If a match occurs, the SMTP client is considered "known bad;" the server sends a failure message to the client and then disconnects the link.

18.6.3.1 Resolving Conflicts between Bad-Clients and Good-Clients

The Bad-Clients and Good-Clients lists are not mutually exclusive. If an SMTP client's IP address may be resolved in both lists, the entry that most closely matches the client's IP address is used.

For example, the following lists are configured:

Bad-Clients: 1.0.0.0/8
Good-Clients: 1.2.3.6

When an SMTP connection comes in from IP address 1.2.3.6, which is in the 1.0.0.0 subnet, the client may be considered a known bad client. But because the specific IP address is specified in the Good-Clients list, the message is accepted.

18.6.4 Real-Time Black Hole Lists (RBL)

The Internet community maintains a list of IP addresses of senders of spam. This is called the Real-time Blackhole List (RBL) and contains DNS A records. For more information and to register to use the RBL, go to the following web site:

www.blackholes.mail-abuse.org

To use the RBL, configure the RBLs list in the SMTP.CONFIG file (described in Section 18.6.1). The RBLs configuration option lists the domains providing RBL services. You can specify a list of RBLs, thereby accommodating individual RBLs and additional Internet-provided RBLs along with the current one.

For example:

RBLs: blackholes.mail-abuse.org, rbl.ourcompany.com

If the SMTP server matches the IP address of the client with an entry in any of the RBLs in the list, the server sends a failure message to the client and disconnects the link.

If a client IP address matches one in the Good-Clients list, the message is accepted; the SMTP server does not check the RBLs.

18.6.5 Translating Client IP Addresses

You can configure SMTP to translate the client's IP address to a host name, and to disconnect the link if no host name exists. To enable this feature, set the Reject-Unbacktranslatable-IP option in SMTP.CONFIG. Translation is not performed if the SMTP client's IP address matches an entry in the Good-Clients list.

18.6.6 Blocking Mail from Specified Senders

You configure SMTP to reject mail based on the address of the sender. The sender's address is specified in the MAIL FROM command. (The terms "sender address" and "MAIL FROM address" are synonymous.) To specify sender addresses from whom mail will always be rejected, include the Reject-Mail-From list in the SMTP.CONFIG file.

The Reject-Mail-From list includes wildcarded patterns that are checked against the sender address. If the SMTP server matches the sender address against a pattern in the Reject-Mail_From list, the MAIL FROM command is rejected and the link is disconnected. Wildcarded patterns may include the standard asterisk (*) and percent sign (%) wildcard characters.

For example:

Reject-Mail-From: *.xyz.com, known.spammer@*, *the_internet*

To specify hosts from which to allow mail, even if the address matches that specified in the Reject-Mail-From list, include them in the Accept-Mail-From list in SMTP.CONFIG.

The Accept-Mail-From list includes wildcarded patterns that are checked against the sender address. If the SMTP server finds that the MAIL FROM address matches an entry in the Reject-Mail-From list, it then checks the Accept-Mail-From list also. You can use this list to allow mail from legitimate senders in the domains listed in the Reject-Mail-From list.

For example:

Accept-Mail-From: *@notabadguy.xyz.com, the_internet_news@somehwere.com

In this example, the entry the_internet_news@somehwere.com allows mail from the sender address the_internet_news@somehwere.com , even though it matches the entry *the_internet* from the Reject-Mail-From list. Likewise, it accepts mail from jones@notabadguy.xyz.com , even though it matches the entry *.xyz.com in the Reject-Mail-From list.

In addition to the Accept-Mail-From list, you can specify the following configuration options in SMTP.CONFIG to allow mail from senders in the Reject-Mail-From list:

• Accept-Unqualified-Senders
  By default, if the TCP/IP Services SMTP server receives a message with an unqualified sender address, or with a sender address with no domain at all, it will reject the MAIL FROM command and disconnect the link.
  For example, the following sender addresses would be rejected by default:

  MAIL FROM:<somebody> MAIL FROM:<somebody@someplace>

  
  The first address has no domain and the second has an unqualified domain.
  To accept mail with these types of sender addresses, set Accept-Unqualified-Senders in SMTP.CONFIG, as follows:

  Accept-Unqualified-Senders: TRUE

  
  When the Accept-Unqualified-Senders option is set, the SMTP server does not check whether the sender address either has a domain or is fully qualified.

• Accept-Unresolvable-Domains
  By default, if the SMTP server fails to find an MX record for the sender address, it rejects the MAIL FROM command and disconnects the link.
  You can specify that messages with unresolvable domains be accepted by setting the Accept-Unresolvable-Domains configuration option to TRUE in SMTP.CONFIG, as follows:

  Accept-Unresolvable-Domains: TRUE

  
  When Accept-Unresolvable-Domains is set, the SMTP server will not perform an MX lookup on the sender address.