HP OpenVMS Systems Documentation
HP TCP/IP Services for OpenVMS
To monitor the mail queues, examine the TCPIP$SMTP_LOGFILE.LOG and the
18.4.2 Changing the Number of Mail Queues
To change the number of SMTP queues, follow these steps:
TCPIP> DISABLE SERVICE SMTP TCPIP> STOP MAIL
TCPIP> SET CONFIGURATION SMTP/QUEUES=new_number
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.
18.4.4 SMTP Logging
SMTP logs mail queue and mail symbiont events to the following files:
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.
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:
To preserve site-specific parameter settings and commands, create the following files. These files are not overwritten when you reinstall TCP/IP Services:
The SMTP services can be started automatically using the TCPIP$CONFIG configuration procedure, or manually using the following command:
To stop SMTP, enter:
You can modify the SMTP configuration by defining logical names that are translated at queue startup time. Characteristics you can control include:
To store the settings of logical names, include the DEFINE command in one of the following command procedures:
When you redefine the value of a logical, you must restart SMTP. Use the following command procedures to shut down and restart SMTP:
Each SMTP logical name changes a configuration setting for handling SMTP mail operations. Some SMTP logical names enable or disable configuration options. If you define the logical name, the option is considered to be enabled. If the logical name is not defined, the option is disabled.
To disable this type of configuration option, simply remove the logical name.
To define this type of logical, set its value to 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
Always use the /SYSTEM qualifier when you define an SMTP logical name, except where noted in Table 18-4.
SMTP consists of three main components:
Each logical name can be used by one or more of the SMTP components.
18.5.2 SMTP Logical Names
Table 18-4 lists the SMTP logical names and, for each, describes the purpose, valid settings, and components that use it.
Sets the log level, according to the value you supply:
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.
|TCPIP$SMTP_NOSEY||Symbiont||Used with TCPIP$SMTP_LOG_LEVEL to print the full subject RFC headers information. If not defined, the header is logged as SUBJECT:<omitted> .|
|Writes line numbers to SMTP logs.|
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
n is the hexadecimal value of the character. For example,
command lines and replies are terminated with a
that appear in the log file as follows:
send buf=MAIL FROM:<email@example.com>\d\a
In this message, \d\a is the <CR><LF> .
|TCPIP$SMTP_RECV_TRACE||Receiver||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.|
|TCPIP$SMTP_RECV_DEBUG||Receiver||Logs full diagnostics, similar to the TCPIP$SMTP_LOG_LEVEL 5 logical name.|
|TCPIP$SMTP_VMSMAIL_SEND||MAIL$PROTOCOL||Logs diagnostic messages to a file named DEBUG.TXT in the default directory. This logical name is reserved for use by HP.|
|Causes the SMTP address parsing code to log diagnostics. This logical name is reserved for use by HP.|
Enables snapshot logging for the symbiont. The value you assign to this
logical specifies the size of the snapshot buffer in OpenVMS blocks (1
block = 512 bytes).
In addition to enabling snapshot logging, you must also specify the type of logging using the TCPIP$SMTP_LOG_LEVEL logical name.
When you enable snapshot buffering for the symbiont, it takes some time for the symbiont process to stop when you enter the STOP MAIL command or when 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
Enables snapshot logging for the receiver. The value you assign to this
logical name specifies the size of the snapshot buffer in OpenVMS
blocks (1 block = 512 bytes). When you enable snapshot buffering, you
must also specify the type of logging, using the TCPIP$SMTP_RECV_DEBUG
and TCPIP$SMTP_RECV_TRACE logical names.
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
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, define the logical name TCPIP$SMTP_NO_SUBS_DOMAIN_INBOUND.
Specifies the default SMTP common directory for an OpenVMS Cluster. By
default, the SMTP common directory is SYS$SPECIFIC:[TCPIP$SMTP]. This
directory is used to store bounced mail control files, receiver control
files, symbiont log files, distribution lists, and the local aliases
If you define a different directory to be used as the SMTP common directory, make sure the directory you specify allows read (R) and write (W) access. Copy the distribution lists and the local aliases files to the directory you specify.
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.
|TCPIP$SMTP_JACKET_LOCAL||Symbiont||Puts the SMTP jacket on local mail to provide sufficient information to the POP server.|
Disables use of the the RFC
header as the text of the OpenVMS Mail
header and the
header as the text of the
line. Instead, the RFC
headers are used.
If the TCPIP$SMTP_INBOUND_NOXVMS option is not defined, the X-VMS-To and X-VMS-CC headers (if present) are used for the mail header lines.
|TCPIP$SMTP_VMSDEF_TO||Symbiont||Causes OpenVMS callable mail to use the default text for the To: field (the user name). Overrides the TCPIP$SMTP_INBOUND_NOXVMS option for the To: field.|
|TCPIP$SMTP_MTS_ALLIN1||Symbiont||Used for compatibility with older versions of MR/MRGATE. 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 Version 3.3A.|
Enables mail bounced by the local host to appear to be from a user name
other than TCPIP$SMTP@
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
node.domain rather than from TCPIP$SMTP@
Be sure to set up a forwarding entry for the user name you specify. (For more information, see Section 18.2.2.)
|TCPIP$SMTP_REWRITE_MTS_FROM||Symbiont||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||Symbiont||Sends all mail that is destined for another system (nonlocal mail) to the alternate gateway. A zone check is not performed.|
|TCPIP$SMTP_MX_IF_NOALTGATE||Symbiont||Use MX records to connect to a host if the alternate gateway cannot be reached.|
|TCPIP$SMTP_NO_MX||Symbiont||Does not 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||Symbiont||Uses only the contents of the local alias file for determining whether a mail message is local.|
|TCPIP$SMTP_PROHIBIT_USER_HEADERS||MAIL$PROTOCOL||Disables outbound alias processing. This prevents the use of the TCPIP$SMTP_FROM logical.|
|TCPIP$SMTP_SFF_REQUIRES_PRIV||MAIL$PROTOCOL||Requires users to set either SYSPRV, BYPASS or OPER privileges before using the Send From File (SFF) feature. For more information about this feature, see Section 18.7.|
Enables SMTP to accept 8BITMIME requests from SMTP clients, preventing
remote clients from converting the message into a 7-bit format before
sending the mail message to the SMTP server. On some displays, such as
that used by OpenVMS Mail (a character-cell based mailer), certain
8-bit strings, such as accented characters, are converted and displayed
in coded sequences.
To prevent this behavior, set the following logical:
$ DEFINE/SYS/EXEC TCPIP$SMTP_8BITMIME_HACK 1
|When this logical is set, the SMTP receiver tells remote SMTP clients that 8-bit characters are supported. In this case, the client does not convert them to 7-bit format.|
|Prevents SMTP from revealing TCP/IP Services version information.|
|Requires users to set either SYSPRV, BYPASS or OPER privileges before using SFF.|
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:
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.
Table 18-5 describes the field names and values for Antispam configuration.
Controls whether the EXPN command can be used. Specify one of the
Controls whether the VRFY command can be used. Specify one of the
|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|
TRUE or FALSE.
If TRUE, the SMTP server rejects any mail from an SMTP client whose IP address cannot be backtranslated to a hostname.
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.
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.
|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.|
Allows you to configure the way SMTP reports a spam event. Specify a
comma-separated list including one or more of the following:
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.
|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 220.127.116.11 for more information.|