HP OpenVMS Systems Documentation
HP TCP/IP Services for OpenVMS
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:
Together, these lists define the "known good world" to the SMTP server for relay purposes. They are used to prevent spam routing as follows:
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:
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: 126.96.36.199/16, 188.8.131.52/24, 184.108.40.206, relay.abc.com
This Good-Clients list contains two IP networks (220.127.116.11 and 18.104.22.168),
an IP address (22.214.171.124), and a DNS entry (
). An entry that does not follow the standard IP address or network
format is assumed to be a DNS entry.
126.96.36.199 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:
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: 188.8.131.52 host.abc.com Gate address Preference Gate name 184.108.40.206 100 mail11.abc.com 220.127.116.11 100 mail13.abc.com 18.104.22.168 200 mail2.abc.com 22.214.171.124 200 mail1.abc.com 126.96.36.199 300 mail21.abc.com 188.8.131.52 300 mail12.abc.com
To include the addresses listed as MX gateways in this example, enter
in the Good-Clients list.
184.108.40.206 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
. When an unknown host tries to relay mail to
through VMShost, and the Relay-Based-On-Mx option is enabled, the SMTP
server on VMShost searches for MX records for
. 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.
220.127.116.11 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
domain. Because of implied wildcarding, domains like
match against this list.
18.104.22.168 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: 22.214.171.124/16, 126.96.36.199/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.
<<<RCPT TO:<email@example.com> >>>550 User not local, Relay disabled.
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: 188.8.131.52, 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.
184.108.40.206 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: 220.127.116.11/8 Good-Clients: 18.104.22.168
When an SMTP connection comes in from IP address 22.214.171.124, which is in
the 126.96.36.199 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:
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.
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.
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.
Accept-Mail-From: *@notabadguy.xyz.com, firstname.lastname@example.org
In this example, the entry email@example.com allows mail from the sender address firstname.lastname@example.org , even though it matches the entry *the_internet* from the Reject-Mail-From list. Likewise, it accepts mail from email@example.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:
MAIL FROM:<somebody> MAIL FROM:<somebody@someplace>
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.
188.8.131.52 Reporting Spam Events
You can customize the SMTP server to report a spam event in the following ways. The SMTP server can:
To configure the way SMTP reports the event, use the SPAM-Action field in SMTP.CONFIG. The legal values are:
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:
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:
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:
The following are the fields and default messages for the FRIENDLY option:
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
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
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:
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:
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: