To monitor the mail queues, examine the TCPIP$SMTP_LOGFILE.LOG and the TCPIP$SMTP_RECV_RUN.LOG files.

17.4.2 Changing the Number of Mail Queues

To change the number of SMTP queues, follow these steps:

1. Stop SMTP and MAIL on the root node by entering the following commands:

   TCPIP> DISABLE SERVICE SMTP TCPIP> STOP MAIL

2. Change the SMTP configuration by entering the following command:

   TCPIP> SET CONFIGURATION SMTP/QUEUES=new_number

   
   The maximum number of queues set with this command is 10.

3. Restart SMTP and MAIL by entering the following commands:

   TCPIP> START MAIL TCPIP> ENABLE SERVICE SMTP

To display SMTP routing information, use the SHOW MX_RECORDS command. If you omit destination from the command line, you see the entries in the local MX database.

If you specify destination, you see all the entries in all the databases that the SMTP mailer would look at, if necessary, to route mail to the destination. The local MX database and the DNS MX database are usually as far as TCP/IP Services needs to search.

17.4.4 SMTP Logging

SMTP logs mail queue and mail symbiont events to the following files:

• TCPIP$SMTP_LOGFILE.LOG
• TCPIP$SMTP_RECV_RUN.LOG

The symbiont and receiver contain a feature called snapshot logging, which allows you to run with full diagnostics enabled but to write the diagnostics to the log file only if an error is signaled. This feature saves disk space and allows the receiver or the symbiont, or both, to run at a normal speed. As each line of diagnostic text is generated, it is saved in an internal snapshot buffer rather than to the disk. The buffer is circular in that once it fills up, new lines of text start to overwrite the old data already there. This functionality provides a snapshot of the last lines of diagnostic text.

Logical names are available to modify the way SMTP logs information and the type of information it reports. These are described in Section 17.5.

17.4.5 Starting and Stopping SMTP

SMTP consists of two components: the sender (the queuing mechanism) and the receiver. You must start the sender before enabling the receiver. The receiver is activated by the auxiliary server.

The SMTP can be shut down and started independently. This is useful when you change parameters or logical names that require the service to be restarted.

The following files are provided:

• SYS$STARTUP:TCPIP$SMTP_STARTUP.COM allows you to start up the SMTP independently.
• SYS$STARTUP:TCPIP$SMTP_SHUTDOWN.COM allows you to shut down the SMTP independently.

To preserve site-specific parameter settings and commands, create the following files. These files are not overwritten when you reinstall TCP/IP Services:

• SYS$STARTUP:TCPIP$SMTP_SYSTARTUP.COM can be used as a repository for site-specific definitions and parameters to be invoked when the SMTP is started.
• SYS$STARTUP:TCPIP$SMTP_SYSHUTDOWN.COM can be used as a repository for site-specific definitions and parameters to be invoked when the SMTP is shut down.

The SMTP services can be started automatically using the TCPIP$CONFIG configuration procedure, or manually using the following command:

$ @SYS$STARTUP:TCPIP$SMTP_STARTUP.COM

To stop SMTP, enter:

$ @SYS$STARTUP:TCPIP$SMTP_SHUTDOWN.COM

17.5 Modifying the SMTP Configuration

You can modify the SMTP configuration by defining logical names that are translated at queue startup time. Characteristics you can control include:

• Event-and error-logging diagnostics
• How mail headers are displayed
• How mail is routed
• How SMTP interacts with OpenVMS Mail

Some SMTP logical names are used to either enable or disable a configuration option and do not require a value. If you define the logical name, the option is considered to be enabled. If not defined, the option is disabled. To disable an option, remove the logical name. By convention you should define these logicals to a value of 1.

For example, to enable message logging for messages received from SMTP clients, define the TCPIP$SMTP_RECV_TRACE as follows:

$ DEFINE/SYSTEM TCPIP$SMTP_RECV_TRACE 1

Other logical names require that you supply a value. For example, to enable logging that provides information about symbiont activity during control file processing, define the logical name TCPIP$SMTP_LOG_LEVEL with a value of 3. For example:

$ DEFINE/SYSTEM TCPIP$SMTP_LOG_LEVEL 3

When you redefine the value of a logical, you must restart SMTP using the STOP MAIL and START MAIL commands. Use the following files to store logical settings:

• SYS$STARTUP:TCPIP$SMTP_SYSTARTUP.COM
• SYS$STARTUP:TCPIP$SMTP_SYSHUTDOWN.COM

The following descriptions indicate where a value is required.

• TCPIP$SMTP_LOG_LEVEL value
  Writes diagnostic information to the log file. Valid numeric values are:

  Value 2	Enables logging of all information when the symbiont starts up. The Next Open File message is printed, giving the name of each control file before processing begins. All mail headers and mail recipients in a control file are logged after control file processing is complete.
  Value 3	Provides additional information about symbiont initialization and activity during control file processing.
  Value 5	Enables full symbiont diagnostics. For use only under the advice of Compaq's customer support.

• TCPIP$SMTP_NOSEY
  Used with TCPIP$SMTP_LOG_LEVEL to print the full subject RFC headers information. If not defined, the header is logged as SUBJECT:<omitted> .
• TCPIP$SMTP_LOG_LINE_NUMBERS
  Writes line numbers to SMTP logs. Includes the symbiont, receiver, and MAIL$PROTOCOL (DEBUG.TXT) logs.
• TCPIP$SMTP_SYMB_TRACE
  Logs all messages received from and transmitted to remote SMTP servers. Used to trace the SMTP application layer protocol. Any nonprinting characters or control characters that are sent or received are printed as \n , where n is the hexadecimal value of the character. For example, command lines and replies are terminated with a <CR><LF> that appear in the log file as follows:

  send buf=MAIL FROM:<jones@acme.com>\d\a recv buf=250 <jones@acme.com>... Sender OK\d\a

  
  In this message, \d\a is the <CR><LF> .

• TCPIP$SMTP_RECV_TRACE
  Logs all messages received from and transmitted to remote SMTP clients. Used to trace the SMTP application layer protocol. The same conventions for logging nonprinting characters or control characters are used. The logical name UCX$SMTP_PROTO_TRACE is obsolete.
• TCPIP$SMTP_RECV_DEBUG
  Logs full diagnostics, similar to the TCPIP$SMTP_LOG_LEVEL 5 logical name. Obsoletes the logical name TCPIP$SMTP_PROTO_DEBUG.
• TCPIP$SMTP_VMSMAIL_SEND
  Instructs the MAIL$PROTOCOL process to log diagnostics to a file named DEBUG.TXT in the default directory. (Used primarily by Compaq.)
• TCPIP$SMTP_VMSMAIL_PARSE
  Causes the SMTP address parsing code to log diagnostics. The symbiont, receiver, and MAIL$PROTOCOL code are sensitive to this logical name, which is used primarily by Compaq.
• TCPIP$SMTP_SYMB_SNAPSHOT_BLOCKS n
  Enables snapshot logging for the symbiont. The value you assign (n) specifies the size of the snapshot buffer in OpenVMS blocks (1 block being 512 bytes). Use with TCPIP$SMTP_LOG_LEVEL.
  When you enable snapshot buffering for the symbiont, it takes some time for the symbiont process to stop when you enter a TCPIP STOP MAIL command or you stop the queue. The delay depends on the size of the snapshot buffer and the speed of the system and its disks.
  For example, the following command lines set the log level to 5 and enable snapshot logging for the SMTP symbiont with a snapshot buffer of 200 blocks:

  $ DEFINE/SYSTEM TCPIP$SMTP_LOG_LEVEL 5 $ DEFINE/SYSTEM TCPIP$SMTP_SYMB_SNAPSHOT_BLOCKS 200

• TCPIP$SMTP_RECV_SNAPSHOT_BLOCKS n
  Enables snapshot logging for the receiver. The value you assign (n) specifies the size of the snapshot buffer in OpenVMS blocks (1 block being 512 bytes). Use with TCPIP$SMTP_LOG_LEVEL.
  For example, the following command line sets all of the receiver diagnostics on and enables snapshot logging for the receiver with a snapshot buffer of 200 blocks:

  $ DEFINE/SYSTEM TCPIP$SMTP_RECV_DEBUG 1 $ DEFINE/SYSTEM TCPIP$SMTP_RECV_TRACE 1 $ DEFINE/SYSTEM TCPIP$SMTP_RECV_SNAPSHOT_BLOCKS 200

• TCPIP$SMTP_NO_SUBS_DOMAIN_INBOUND
  Instructs SMTP not to consider mail that is sent to the substitute domain as local mail.
  By default, SMTP recognizes mail that is addressed to the substitute domain as local mail. To change this default:
  1. Define the system logical name TCPIP$SMTP_NO_SUBS_DOMAIN_INBOUND.
  2. Stop and start the SMTP mail queue using the STOP MAIL and START MAIL commands.
• TCPIP$SMTP_COMMON common-directory
  Specifies the default cluster common directory. By default, SMTP looks for distribution list (.DIS) and local alias (TCPIP$SMTP_LOCAL_ALIASES.TXT) files in the SYS$SPECIFIC:[TCPIP$SMTP].
  You must:
  • Define this logical name before SMTP startup.
  • Create the directory with read (R) and write (W) access. If the directory is shared between a system running a previous version of the product (UCX) and this version, granting G:RWE privilege is sufficient, because the UCX_SMTP and TCPIP$SMTP accounts are in the same group.
  • Move the .DIS or .TXT file, or both, to the directory.
  
  You can also use this logical name as a search list. For example, you might want SMTP to look at the clusterwide directory and then the SYS$SPECIFIC:[TCPIP$SMTP] directory, as follows:

  $ DEFINE/SYSTEM TCPIP$SMTP_COMMON WORKDISK:[SMTP_DIS], - _$ SYS$SPECIFIC:[TCPIP$SMTP]

  
  Note that other files such as control files and log files reside in the SYS$SPECIFIC:[TCPIP$SMTP] directory.

• TCPIP$SMTP_JACKET_LOCAL
  Instructs the symbiont to put the SMTP jacket on local-to-local mail to provide sufficient information to the POP server.
• TCPIP$SMTP_INBOUND_NOXVMS
  Instructs the symbiont not to use the RFC X-VMS-To header as the text of the OpenVMS Mail To: header and the X-VMS-CC header as the text of the CC: line. Instead, the RFC To: and CC: headers are used. If the TCPIP$SMTP_INBOUND_NOXVMS option is not defined, the SMTP symbiont uses the text of the X-VMS-To and X-VMS-CC headers for the mail header lines.
  SMTP accepts inbound mail from a non-SMTP user for a user who has forwarded mail through SMTP on the local system.
  SMTP sets the OpenVMS Mail CC: header.
  If an X-VMS-To or X-VMS-Cc RFC header is not present, SMTP puts the header in the OpenVMS Mail To: header.
  If you do not want to put these headers in the OpenVMS Mail To: and CC: headers:
  1. Define the system logical name TCPIP$SMTP_INBOUND_NOXVMS.
  2. Stop and start the SMTP execution queue using the STOP MAIL and START MAIL commands.
• TCPIP$SMTP_VMSDEF_TO
  Instructs the symbiont not to pass any text for the To: line to OpenVMS callable mail when delivering local mail. This option causes OpenVMS callable mail to use the default text for the To: line (the user name). Overrides the TCPIP$SMTP_INBOUND_NOXVMS option for the To: field.

• TCPIP$SMTP_MTS_ALLIN1
  Used in older versions of TCP/IP Services. When relaying mail from the SMTP environment to MTS (the message router), the symbiont puts TCPIP$SMTP into the From: field. Otherwise, older versions of MR/MRGATE send the mail back with a Return path too complicated error. No longer needed if you are running MR and MRGATE Versions 3.3A.
• TCPIP$SMTP_POSTMASTER_ALIAS user-name
  Enables mail bounced by the local host to appear to be from a user name other than TCPIP$SMTP@node.domain. Specify the user name portion of the address, not including the host name. For example:

  $ DEFINE/SYSTEM TCPIP$SMTP_POSTMASTER_ALIAS "Postmaster"

  
  In this example, bounced mail sent from the local host appears to be from Postmaster@node.domain rather than from TCPIP$SMTP@node.domain.
  Be sure to set up a forwarding entry for the user name you specify (see Section 17.2.2).

• TCPIP$SMTP_REWRITE_MTS_FROM
  If you have most or all of your users' mail forwarded to ALL-IN-1, use this logical name to instruct the symbiont to parse the user name out of the complex MTS address and append the local host name instead. As a result, only a simple address is sent to the Internet and any replies are relayed correctly to MTS.
• TCPIP$SMTP_ALTGATE_ALWAYS
  Instructs the symbiont to send all mail that is destined for another system (nonlocal mail) to the alternate gateway. Zone check is not performed.
• TCPIP$SMTP_MX_IF_NOALTGATE
  Instructs the symbiont to use MX records to connect to a host if the alternate gateway cannot be reached.
• TCPIP$SMTP_NO_MX
  Instructs the SMTP symbiont not to use MX records to route mail. Attempts to translate the domain part of each SMTP address into a host name and send the mail directly to that address. If the host name does not translate to an address, the mail is returned. If the host is not available, the mail is queued again.
• TCPIP$SMTP_LOCAL_ALIAS_ONLY
  Instructs the SMTP symbiont to use only the contents of the local alias file for determining whether a mail message is local.
• TCPIP$SMTP_PROHIBIT_USER_HEADERS
  Disables outbound alias processing. This prevents the use of the TCPIP$SMTP_FROM logical.
• TCPIP$SMTP_SFF_REQUIRES_PRIV
  This Boolean logical, if defined, requires users to set either SYSPRV, BYPASS or OPER privileges before using the Send From File (SFF) feature. See Section 17.7 for more information about this feature.

• TCPIP$SMTP_MIME_HACK
  When set, SMTP accepts 8BITMIME requests from SMTP clients, preventing the clients from converting the message into a 7-bit format. For more information, see Section 17.9.2.

SPAM is the Internet equivalent of junk mail and is a growing source of annoyance to Internet users. TCP/IP Services SMTP contains antiSPAM, which 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.

17.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 (see Section 17.5).

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

SMTP.CONFIG is an ASCII text file consisting of one or more lines formatted as follows:

Field1: Value1 Field2: Value2 . . .

In this format:

• Field names start in column 1, are terminated with a colon (:), and are not case sensitive.
• Values vary depending on the field. Limitations and restrictions are described in Table 17-4.
  If a value consists of a list of items, specify them on multiple lines by pressing the Tab key before continuing the value on the subsequent lines. For example:

  Field1: Item1, [Tab]Item2, [Tab]Item3 Field2: Value2

  
  Or specify each value as a separate instance of same field. For example:

  Field1: Item1 Field1: Item2 Field1: Item3

  
  An alternative format is:

  Field1: Item1, Item2, Item3

  
  The maximum number of characters in a value is 500 characters. Unless otherwise noted, a field's value is not case sensitive.
  Fields described as Boolean have the following legal values:

  To turn the feature on:	To turn the feature off:
  ON	OFF
  TRUE	FALSE
  1	0
  YES	NO

To comment out a line, enter an exclamation point (!) in column 1.

The file SMTP_CONFIG.TEMPLATE is provided to help you create this file; it contains guidelines on configuring antiSPAM.

17.6.1.1 SMTP AntiSPAM Field Names

Table 17-4 describes the field names and values for antiSPAM configuration.

.

Table 17-4 AntiSPAM Configuration Options

Field Name	Value	Default
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.	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	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 17.6.8.3 for more information.

The following sections provide further information about the configuration options.