HP OpenVMS Systems Documentation

SPAM mailing lists contain thousands of addresses and sending a SPAM takes a great deal of time. Therefore, SPAMmers prefer to use hosts other than their own to send the message. SPAMmers routinely use unaware Internet hosts as route-through hosts for their SPAM. The victim is a host not protected by a firewall or by SPAM-aware software. The SPAMming SMTP client software connects to the victim SMTP server host and issues multiple RCPT TO commands, which may number in the thousands. The SPAMing 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 nets, DNS hostnames 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.

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

Although the configuration of both Good-Clients and Relay-Zones at the same time makes sense for most configurations, it is not required that both be configured. If a Relay-Zones list is specified without a Good-Clients list, relay checking depends on the setting of the relay flag. Information in the Relay-Zones list is ignored.

If you specify a Good-Clients list but no Relay-Zones list, the host will relay mail from SMTP clients matching the Good-Clients list but will not relay any mail from unknown SMTP client hosts. The host will accept mail only from an unknown SMTP client host if it is local mail (mail destined to the local host or a host listed in the local aliases list). If you want the host to accept relay mail from unknown SMTP client hosts, you must specify Relay-Zones or enable Relay-Based-On-Mx (described in Section 17.6.3.3).

17.6.3.1 Specifying the Good-Clients List

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 the n.n.n.n/m syntax, 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.0.0/16,
              2.3.4.5, relay.abc.com

This Good-Clients list contains two IP networks (1.2.0.0 and 2.3.0.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.

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

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

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

17.6.3.5 Rejecting Route-Through Attempts

If the SMTP server does not resolve the a route-through attempt using the Good-Clients list and the Relay-Zones list, it rejects the RCPT TO command. It 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 17.6.8.

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

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

In a case where the exact IP address is specified in both the Good-Clients list and the Bad-Clients list, the SMTP server accepts the message.

17.6.5 Real-Time Black Hole Lists (RBL)

To prevent SPAM route-through from clients dialed through an ISP and connecting directly to the destination hosts, the Internet community maintains a list of known SPAMming IP addresses at domain rbl.maps.vix.com . This is called the Realtime Blackhole List (RBL) and contains DNS A records.

To determine whether a specific IP address is in the RBL list, perform these steps:

1. Reverse the IP address.
2. Append the domain of the RBL.
3. Do a DNS A record lookup.

For example, to check the IP address of 2.2.3.5, do a name lookup of 5.3.2.2.rbl.maps.vix.com . If the query returns something, then IP address 2.2.3.5 is in the rbl.maps.vix.com SPAMmer list. All RBLs are implemented this way.

To take advantage of the RBL, configure the RBLs list in SMTP.CONFIG. 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: rbl.maps.vix.com, 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.

17.6.5.1 Using Other RBL Lists

Other lists serve similar functions to the RBL list. For example:

• MAPS Dial-up User List --- A list of IP addresses that participating ISPs have allocated to them.
  If you want to include a check against this list, add dul.maps.vix.com to the RBL list.
  Even when SMTP is set up to reject all incoming SMTP connections from dial-up IP addresses, mail can still be received from someone who is dialed up to an Internet Service Provider (ISP). This is because they send their SMTP mail to their ISP's mail servers, and the ISP mail server connects to your mail server. The IP address of the ISP's mail server is not in an RBL, so this connection will not be rejected.
  This RBL list only prevents routing of e-mail from a dialup IP address directly to your host.
  You can allow your own dialup users to connect directly to your hosts without being rejected. If your dial-up addresses have been included in an RBL, you can exclude them from the RBL check by adding the IP addresses to the Good-Clients list.
  For more information about MAPS list, visit the following web site:

  http://maps.vix.com

• Open Relay Behavior modification (ORBS) list --- A list of SMTP servers that are known to permit third-party relay.
  To include this list, add relays.orbs.org to the RBLs list in SMTP.CONFIG.

  Caution If you include relays.orbs.org in the RBLs list, you will not receive mail from any host IP address in the ORBS list. This could prevent legitimate mail from coming in.

  
  For more information about the ORBS list, visit the following web site:

  http://www.orbs.org

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.

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

Whenever the TCP/IP Services SMTP server disconnects a link with a client, it generates an event message. You can control the way events are handled using the procedures in the following sections.

17.6.8.1 Reporting SPAM Events

You can customize the SMTP server to report a SPAM event in the following ways. The SMTP server can:

• Send an OPCOM message.
• Send a /TYPE=USER message to the accounting subsystem.

To configure the way SMTP reports the event, use the SPAM-Action field in SMTP.CONFIG. The legal values are:

• NONE
• OPCOM (the default)
• ACCOUNTING

You can specify multiple values for the SPAM-Action field. For example:

SPAM-Action: OPCOM, ACCOUNTING

This example causes both OPCOM and accounting messages to be sent for each SPAM event. To disable SPAM event reporting, enter a value of NONE for SPAM-Action in SMTP.CONFIG, as follows:

SPAM-Action: NONE

When the SMTP server disconnects the link with the client because of one of the antiSPAM checks, it sends a message back to the client. The text of the message is controlled by the Security field in SMTP.CONFIG. The legal values for this field are:

• SECURE (the default)
  If Security is set to SECURE, the messages do not indicate the cause of the disconnect.
• FRIENDLY
  If Security is set to FRIENDLY, the messages indicate the cause of the disconnect.

You can specify the rejection text message to be sent to the client. The field names for these options end in "-Text", and the values for them must be a single line of text. These fields override the default text associated with the specific SPAM event.

The following are the fields and default messages for the SECURE option:

• Unbacktranslatable-IP-Text: Closing transmission channel.
• Bad-Clients-Text: Closing transmission channel.
• Client-In-RBL-Text: Closing transmission channel.
• Reject-Mail-From-Text: Closing transmission channel.
• Unqualified-Sender-Text: Closing transmission channel.
• Unresolvable-Domain-Text: Closing transmission channel.
• SPAM-Relay-Text: User not local, Relay disabled.

The following are the fields and default messages for the FRIENDLY option:

• Unbacktranslatable-IP-Text: I can't backtranslate your IP address to a host name.
• Bad-Clients-Text: Your IP address or subnet is in my list of bad ones.
• Client-In-RBL-Text: Your IP address is in my RBL list.
• Reject-Mail-From-Text: That sender address is in my list of bad ones.
• Unqualified-Sender-Text: That sender address is unqualified.
• Unresolvable-Domain-Text: That sender address is unresolvable into a host name or MX domain.
• SPAM-Relay-Text: Both you and the recipient are unknown to me. I will not relay.

You can change one or more of the default messages by including the field and your message for a value. This will override the default setting for that field. For example:

Unbacktranslatable-IP-Text: Your IP address is unbacktranslatable. SPAMMER!