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.

.

Table 18-5 Antispam Configuration Options

Field Name	Value	Default
Allow-EXPN	Controls whether the EXPN command can be used. Specify one of the following: NEVER to prevent use of the EXPN command regardless of the whether the client is in the Good-Clients list. ALWAYS to allow use of the EXPN command regardless of the whether the client is in the Good-Clients list. LOCALLY to allow use of the EXPN command only if the remote SMTP client's IP address matches the Good-Clients list.	LOCALLY
Allow-VRFY	Controls whether the VRFY command can be used. Specify one of the following: NEVER to prevent use of the VRFY command regardless of the whether the client is in the Good-Clients list. ALWAYS to allow use of the VRFY command regardless of the whether the client is in the Good-Clients list. LOCALLY to allow use of the VRFY command only if the remote SMTP client's IP address matches the Good-Clients list.	LOCALLY
Good-Clients	A list of the IP addresses, IP nets, DNS hostnames, and DNS MX domains of known good SMTP clients.	If not defined, SMTP will not check IP address of SMTP client against this list.
Bad-Clients	A list of the IP addresses, IP nets, DNS hostnames, and DNS MX domains of known bad SMTP clients.	If not defined, SMTP will not check IP address of SMTP client against this list.
Relay-Zones	A list of the SMTP domains to which the system will relay mail even if it is from an unknown client.	If not defined, SMTP will not check recipient address of mail against this list.
RBLs	A list of domains that maintain RBL lists. For more information, see Section 18.6.4.	If not defined, SMTP will not check IP address of SMTP client against any RBL lists.
Relay-Based-On-Mx	TRUE or FALSE. If TRUE, the SMTP server accepts relays from unknown clients to recipients where the recipient's domain has an MX record naming the local host as a gateway.	FALSE
Reject-Unbacktranslatable-IP	TRUE or FALSE. If TRUE, the SMTP server rejects any mail from an SMTP client whose IP address cannot be backtranslated to a hostname.	FALSE
Accept-Unqualified-Senders	TRUE or FALSE. If TRUE, the SMTP server accepts mail for which the sender address (the address from the MAIL FROM command) has no domain or an unqualified domain.	FALSE
Accept-Unresolvable-Domains	TRUE or FALSE. If TRUE, the SMTP server accepts mail for which the sender address (the address from the MAIL FROM command) has a domain that cannot be resolved using MX lookup.	FALSE
Reject-Mail-From	A list of wildcarded patterns that are matched against the sender address. If a match occurs, the MAIL FROM command is rejected and the link is disconnected.	If not defined, SMTP will not check the sender address of the mail against the list.
Accept-Mail-From	A list of wildcarded patterns that are matched against the sender address if the sender address has matched one of the entries in the Reject-Mail-From list. If the sender address matches the Accept-Mail-From list, the message is sent on.	If not defined, SMTP will not check the sender address of the mail against the list.
SPAM-Action	Allows you to configure the way SMTP reports a spam event. Specify a comma-separated list including one or more of the following: NONE OPCOM ACCOUNTING	OPCOM
Security	FRIENDLY or SECURE. This value specifies the type of error text sent to the SMTP client when disconnecting a link because of a spam event. A value of SECURE means to send purposely unhelpful error text. A value of FRIENDLY means to send helpful error text.	SECURE
Unbacktranslatable-IP-Text Bad-Clients-Text Client-In-RBL-Text Reject-Mail-From-Text Unqualified-Sender-Text Unresolvable-Domain-Text SPAM-Relay-Text EXPN-Used-Text VRFY-Used-Text	These individual fields (one for each type of SPAM event) hold the error text to be sent to the SMTP client. These override values set in the Security field.	The default for each of these is set according to the value of the Security field. See Section 18.6.7.3 for more information.
Symbiont-Checks-Delivery	TRUE or FALSE Specifies whether the receiver checks to see if the recipient email address in the RCPT TO SMTP protocol command is deliverable. This solves the problem where SPAM arrives on the host for a non-existent user and is bounced by your host's symbiont process to the email address in the SPAM's Return-Path: header. The SPAM's Return-Path: header contains an invalid email address, so the bounced SPAM is in turn bounced back to your host's POSTMASTER account. The POSTMASTER account's mail is forwarded to the SYSTEM account, which means that the SYSTEM user must constantly separate these doubly bounced SPAMs from their valid email. The default setting (FALSE) causes the SMTP receiver to check for undeliverable email. This prevents the problem by not letting the SPAM for the unknown user onto the host in the first place. To restore the old behavior (symbiont checks delivery), set this option to TRUE.	FALSE

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

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