HP OpenVMS Systems Documentation

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.

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

18.6.7.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 the Antispam checking, 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!

SMTP allows you to create a mail message in a file and send it to the SMTP mailer to be delivered with headers you specify. Using SFF, you can create automated tools that compose and send mail messages.

SFF is also useful for forwarding nontext (MIME) files because it prevents the mailer from encapsulating the MIME and SMTP headers in the body of a new mail message. In this way, SMTP functions like the redirect command on your personal computer.

18.7.1 SFF Security Measures

The ability to create messages with arbitrary headers could be used to spoof message headers. To limit this, SFF adds a Received: header to the headers you supply. This tells you the origin of an attempted spoofed message.

You can invoke SFF from an application or from DCL, as described in the following sections.

18.7.2 Invoking SFF from an Application

TCPIP$SMTP_MAILSHR.EXE contains a routine called TCPIP$SMTP_SEND_FROM_FILE. This routine is declared as follows:

unsigned int TCPIP$SMTP_SEND_FROM_FILE(infile_name, logfd, log_level)
char *infile_name;
FILE *logfile_name;
int log_level;

The parameters for this routine are:

• infile_name
  Specifies the name of the text file that contains the RFC 822 mail message and SMTP protocol information. For more information, refer to the HP TCP/IP Services for OpenVMS User's Guide.
• logfile_name
  The name of the file to which diagnostic messages will be logged. This file must be opened by the caller before calling this routine. If no log file is specified, output goes to SYS$OUTPUT. This parameter is optional.
• log_level
  The debug log level: either 1 (on) or 0 (off). The default is 0 (no logging). This parameter is optional.

To call the routine, link with TCPIP$SMTP_MAILSHR.EXE/SHARE.

18.7.3 Invoking SFF from DCL

The SMTP_SFF command allows you to invoke SFF. To define SMTP_SFF as a foreign command so that you can use it from DCL, enter the following command:

$ SMTP_SFF:==$TCPIP$SYSTEM:TCPIP$SMTP_SFF.EXE

This command takes UNIX style parameters and passes them to SFF.

The command format is:

SMTP_SFF infile_name [-log logfile_name] [-loglevel log_level]

The parameters to this command are:

• infile_name
  Specifies the name of the text file that contains the RFC 822 mail message and SMTP protocol information. For more information, refer to the HP TCP/IP Services for OpenVMS User's Guide.
• logfile_name
  The name of the file to which to log diagnostic messages. If no log file is specified, the default is SYS$OUTPUT. This parameter is optional.

• log_level
  The debug log level: either 1 (on) or 0 (off). The default is 0 (no logging). This parameter is optional.