HP OpenVMS Systems Documentation

Content starts here HP TCP/IP Services for OpenVMS

HP TCP/IP Services for OpenVMS
Management


Previous Contents Index


Chapter 18
Configuring and Managing SMTP

The Simple Mail Transfer Protocol (SMTP) is a standard protocol that provides a reliable and efficient mail delivery system between systems communicating in a TCP/IP network. SMTP specifies the format of control messages sent between two machines to exchange electronic mail, but it does not specify the mail interface.

The TCP/IP Services product implements SMTP as an OpenVMS symbiont that works with the OpenVMS Mail utility.

This chapter reviews key concepts and describes:

See the HP TCP/IP Services for OpenVMS User's Guide for information about using SMTP to send and receive mail.

18.1 Key Concepts

To be reliable, electronic mail systems must be able to cope with situations where the recipient is temporarily unavailable, for example, if the recipient's host is down or off line. Mail must also be able to handle situations where some of the recipients on a distribution list are available and some are not.

SMTP is a store-and-forward mail protocol that accepts mail from an originating host and forwards it through one or more intermediate hosts before it reaches its final destination. Note that this behavior differs from OpenVMS Mail, where mail is sent directly from the originating node to the destination node.

Local mail is mail destined for a local system. If SMTP receives mail for any local systems, it delivers the mail using OpenVMS Mail rather than forwarding it on to another system.

18.1.1 How SMTP Clients and Servers Communicate

In most implementations, SMTP servers listen at port 25 for client requests. In the TCP/IP Services implementation of SMTP, the SMTP receiver is invoked by the auxiliary server when an inbound TCP/IP connect comes in to port 25 (if the SMTP service is enabled). The auxiliary server runs the command procedure specified in the SMTP service database entry that runs the receiver. The receiver image is SYS$SYSTEM:TCPIP$SMTP_RECEIVER.EXE. The receiver process runs in the TCPIP$SMTP account.

The SMTP symbiont processes all mail on the host. It receives jobs one at a time from the generic SMTP queue and delivers them either locally by means of OpenVMS Mail, or remotely by means of SMTP.

The configuration procedure TCPIP$CONFIG sets up the SMTP queues for you. See Section 18.2 for more information on configuring SMTP.

After receiving a client request, the SMTP server responds, indicating its status (available or not available). If the server is available, it starts an exchange of control messages with the client to relay mail. (Like FTP, SMTP does not define a message format. SMTP commands are sent as ASCII text, and the SMTP server at the remote host parses the incoming message to extract the command.)

The following steps occur:

  1. The auxiliary server listens for requests, starts the SMTP receiver, and accepts the TCP connection.
  2. The client identifies itself by sending its fully qualified domain name.
  3. The server replies with its own fully qualified domain name.
  4. The client sends the full mail address of the sender enclosed in angle brackets; if the server is able to accept the mail, it returns a readiness code.
  5. The client sends the full mail address (also enclosed in angle brackets) of the message's intended recipients.
  6. The client sends the body of the message.

A minimum of five control message commands are required to conduct the preceding sequence. Table 18-1 describes these commands.

Table 18-1 SMTP Client Commands
Command Description
HELO Identifies the originating host to the server host. Use the /DOMAIN qualifier to provide the name of the originating host.
MAIL FROM:< reverse-path> Identifies the address at which undeliverable mail should be returned. Usually is the originating host.
RCPT TO:< forward-path> Address of the intended receiver. If sending mail to multiple recipients, use one RCPT TO command for each recipient.
DATA Signals the end of the RCPT TO commands and tells the recipient to prepare to receive the message itself.
QUIT Indicates no more commands.

These commands are described in RFC 821.

18.1.2 Understanding the SMTP Control File

With TCP/IP Services SMTP, each mail message is packaged into a special-purpose binary file called a control file. This control file is submitted to a generic SMTP queue to be processed by the SMTP symbiont. Each control file contains one SMTP mail message. Note that an SMTP message addressed to multiple recipients is stored in one control file.

Control file names provide information about the mail contained within. The format for the control file name is as follows:

yymmddmmshh_user-name_pid.TCPIP_scnode

where:

yymmddmmshh is the timestamp taken when the file is created.
user-name is the user name of the process in which the control file was created. Values for this name include:
  • TCPIP$SMTP --- Inbound mail handled by the SMTP receiver. Control files are stored in the directory referenced by the TCPIP$SMTP_COMMON logical name.
  • MAIL$SERVER --- Mail from DECnet. Control files are stored in the user's default OpenVMS Mail directory.
  • SYSTEM --- Bounced messages. Control files are stored in the directory referenced by the TCPIP$SMTP_COMMON logical name.
  • username --- Mail directed by SFF (Send From File). Control files are stored in the user's default OpenVMS Mail directory.
pid is the process identification.
scnode is the value of the SYSGEN SCSNODE parameter.

18.1.3 Understanding OpenVMS Sender Headers

The OpenVMS Mail utility provides one sender mail header: the From: header. However, SMTP supports a large set of sender headers, including:

  • Resent-Reply-To:
  • Resent-From:
  • Reply-To:
  • Resent-Sender:
  • Sender:
  • ReturnPath:

When it composes an OpenVMS Mail message from an SMTP mail message, SMTP supplies the first SMTP header that it finds for the OpenVMS Mail From: header.

18.1.4 Understanding SMTP Addresses

SMTP addresses are of the form userID@domain.name, where domain.name refers to a domain for which there is a DNS MX record. Mail Exchange (MX) records tell SMTP where to route the mail for the domain.

18.1.5 How SMTP Routes Mail

To find a destination address, SMTP routing looks up addresses in this order:

  1. Local MX database
  2. BIND MX records
  3. BIND A records
  4. Local hosts database

Most messages are routed using the BIND records. Local MX records are useful if you want to customize your system's mail routing. DNS-based records are networkwide. If you have local MX records, remember that they are case sensitive and are available on the local node only.

18.1.5.1 Using MX Records

SMTP uses the information stored in MX records, if available, to route mail. MX tells the SMTP where to route mail for a particular destination domain. The DNS (such as BIND) maintains the MX records, but SMTP makes use of them. Each MX record contains the following fields:

Destination domain Matches the domain portion of the address. This is the key field of the MX record. For example, if mail is to be sent to jones@xyzcorp.com , MX lookup is done on the destination domain xyzcorp.com .

Multiple MX records for the same destination are allowed. Therefore, in a sense, the destination domain field allows duplicate keys.

Gateway host name Specifies the name of the host through which mail sent to the destination domain should be routed.
Preference Prioritizes multiple MX records for the same destination domain. The lower the preference value, the higher the priority for the MX record. That is, lower-preference MX records are attempted before higher-preference records.

Multiple MX records to the same domain can have the same preferences.

Creating multiple MX records for the same destination domain provides the following advantages:

  • Enables load balancing between mail routers. In this case, use the same preferences for all the MX records with the same destination domain.
  • Ensures that mail can still be delivered even if one of the routers becomes unavailable.
  • Provides MX-based routes for mail inside and outside a firewall.

18.1.5.2 Using SMTP Zones and Alternate Gateways

When you configure SMTP, you supply the name of the domain for your environment with the /ZONE qualifier to the SET CONFIGURATION SMTP command. If you do not include this qualifier, the zone defaults to your local domain.

Mail for delivery outside of your zone is sent to its destination by the alternate gateway, as defined by the /GATEWAY qualifier. If you define an alternate gateway, SMTP routes mail to destinations outside the SMTP zone defined on the alternate gateway. SMTP uses MX records for routing mail within the zone and, if no alternate gateway is defined, elsewhere as well.

The following example defines the alternative gateway MY.ALT.MYZONE.COM and the zone MYZONE.COM.


TCPIP> SET CONFIGURATION SMTP/GATEWAY=ALTERNATE=MY.ALT.MYZONE.COM
TCPIP> SET CONFIGURATION SMTP/ZONE=MYZONE.COM

See the HP TCP/IP Services for OpenVMS Management Command Reference manual for a detailed desciption of the SET CONFIGURATION SMTP command.

To send mail to the alternate gateway, SMTP does an MX lookup on the alternate gateway and uses the resulting list of MX records to get the mail to the alternate gateway. To understand the advantages of this method over a simple lookup of A records, consider the following example.

The alternate gateway and zone are configured as follows:


TCPIP> SHOW CONFIGURATION SMTP
...
Alternate gateway:  relay.abc.com
...
Zone:               abc.com
...

Further, there is no A record configured for the destination domain relay.abc.com. Therefore, relay.abc.com is not a valid host name. This is demonstrated by the following command:


TCPIP> SHOW HOST RELAY.ABC.COM
%TCPIP-W-NORECORD, Information not found
-RMS-E-RNF, record not found

There is no such host as relay.abc.com because relay.abc.com is only an MX destination domain with multiple records at the same preference.

MX records have been set up accordingly. For example:


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

In this example, when SMTP receives a mail message destined for a domain outside of the abc.com domain, it uses the list of MX records to send the mail to the entity called relay.abc.com . Even when mail is routed through the alternate gateway, the MX lookup list is used.

This type of configuration provides redundancy. Even if one or more of the systems pointed to by the MX records is down, mail can be routed through one of the systems that is running.

If the alternate gateway was reached through a simple A record (hostname) lookup and the host was down or could not be reached, all outbound mail outside the zone would have to wait until the host came back on line.

You can define the alternate gateway using an IP address; this bypasses the MX lookup logic. For example:


TCPIP> SET CONFIGURATION SMTP/ALTERNATE=GATEWAY=1.2.3.4

In this case, all mail destined for the alternate gateway will go to the specified IP address (1.2.3.4) with no MX lookup.

18.2 Configuring SMTP

Use the configuration procedure TCPIP$CONFIG to set up SMTP on your host. If you need to reconfigure or further refine your SMTP environment, use the SET CONFIGURATION SMTP command. With this command, you can change the way SMTP:

  • Relays messages
  • Determines the route
  • Determines how many times it retries a relay and the length of time between delivery attempts
  • Sends and receives timeouts

For a complete description of this command, its qualifiers, and options, see the HP TCP/IP Services for OpenVMS Management Command Reference manual.

18.2.1 Mail Utility Files

Table 18-2 lists the utility files created during the SMTP configuration.

Table 18-2 Default SMTP Utility Files
File Name Description
LOGIN.COM Used by the auxiliary server.
TCPIP$SMTP_RECV_RUN.COM Used by the auxiliary server, and stored in the TCPIP$SYSTEM directory.
TCPIP$SMTP_LOGFILE.LOG Log of mail queue and symbiont activities.
TCPIP$SMTP_RECV_RUN.LOG Log of incoming mail.

To analyze the consistency of the SMTP queues against the directories containing the SMTP utility files, enter the ANALYZE MAIL command.

18.2.2 Creating a Postmaster Account

SMTP requires that the system be able to receive mail addressed to the user name POSTMASTER. This user name is the destination for bounced mail messages.

A bounced mail message is a mail message that has been returned by a remote server because neither the recipient specified in the original mail message, nor the original sender can be found by the local SMTP server.

By default, bounced mail is delivered to the following SMTP address:


TCPIP$SMTP@node.domain

To ensure that the POSTMASTER account is set up to receive SMTP mail, use OpenVMS Mail to specify forwarding of mail addressed to POSTMASTER to the SYSTEM account. For example:


$ SET PROC/PRIV=SYSPRV
$ MAIL
MAIL> SET FORWARD/USER=POSTMASTER SYSTEM
MAIL> SET FORWARD/USER=TCPIP$SMTP SYSTEM
MAIL> SET FORWARD/USER=UCX_SMTP   SYSTEM

This ensures that bounced mail messages are sent to the SYSTEM user (usually the system manager).

You can modify the user name associated with POSTMASTER by defining the following logical name:


$ DEFINE /SYSTEM TCPIP$SMTP_POSTMASTER_ALIAS user-name

In this example, user-name is the user name. For more information, see Section 18.5.

18.3 Creating a Local Alias File

You can used a local alias to define a list of domains that SMTP will interpret as local. If SMTP receives mail for any of the domains specified as local aliases, it will deliver the mail on the local system using OpenVMS Mail rather than forward it on to another system.

This is useful in an OpenVMS Cluster environment, where you want mail sent to any of the cluster hosts to be delivered locally rather than take the extra step of relaying it from one cluster node to another. It is also useful if you want to set up your OpenVMS host to receive inbound mail either for different domains unrelated to the actual domain of your host or for alias names of your host.

For example, if your host was a.b.com and you had entries for x.y.com and y.z.com in your local alias file, any mail to x.y.com and y.z.com would be delivered locally on your host. (To implement this fully, set up DNS MX records so that mail to the x.y.com and y.z.com domains is routed to your host.) For more information about setting up DNS records, see Appendix D.

To define a list of domains that SMTP interprets as local, create the file TCPIP$SMTP_LOCAL_ALIASES.TXT containing a list of domain names that are to be recognized as local. The domain names should have a maximum of 64 characters with one line per name, up to a maximum of 255 names. For example:


!
! This is the local alias file.
!
ourdomain.edu
ourdomain1.edu
ourdomain2.edu
ourdomain3.edu

Copy the TCPIP$SMTP_LOCAL_ALIASES.TXT file to one of the following locations:

  • TCPIP$SMTP_COMMON, where each host listed in the TCPIP$SMTP_LOCAL_ALIASES.TXT file receives clusterwide messages
  • SYS$SPECIFIC:[TCPIP$SMTP] (local system use)

Stop and then restart SMTP for the change to take effect.

If SMTP cannot locate the TCPIP$SMTP_LOCAL_ALIASES.TXT file, it looks for the file TCPIP$SMTP_COMMON:UCX$SMTP_LOCAL_ALIASES.TXT. This ensures functionality for mixed clusters (that is, clusters running the current version of TCP/IP Services and earlier versions of the product (UCX)), where the TCPIP$SMTP_COMMON and UCX$SMTP_COMMON logicals point to the same directory. Note that when SMTP looks for UCX$SMTP_LOCAL_ALIASES.TXT it looks for it in the TCPIP$SMTP_COMMON: directory rather than in the UCX$SMTP_COMMON: directory.

18.4 Managing SMTP

Table 18-3 summarizes the commands you use to monitor and manage SMTP.

Table 18-3 SMTP Management Commands
Command Function Required Privilege
ANALYZE MAIL Verifies the consistency of the SMTP queues against the SMTP working directory. SYSPRV or BYPASS.
DISABLE SERVICE SMTP Stops SMTP service. Follows OpenVMS file protection rules.
ENABLE SERVICE SMTP Initializes communications for SMTP. Follows OpenVMS file protection rules.
REMOVE MAIL Deletes the specified mail entries from the SMTP queues.  
SEND MAIL SMTP requeues a mail message for delivery. SYSPRV or BYPASS for messages other than yours.
SET CONFIGURATION SMTP Modifies the characteristics of the SMTP sender and receiver. SYSPRV or BYPASS.
SHOW CONFIGURATION SMTP Displays the system characteristics for SMTP. Follows OpenVMS file protection rules.
SET SERVICE SMTP Defines, modifies, or deletes the SMTP service in the services database. SYSPRV or BYPASS.
SHOW MAIL Displays information about mail for the specified user. SYSPRV or BYPASS.
SHOW SERVICE SMTP Displays statistical information about the SMTP server. Follows OpenVMS file protection rules.
START MAIL Starts the SMTP queuing mechanism. SYSPRV or BYPASS.
STOP MAIL Stops the SMTP queuing mechanism. SYSPRV or BYPASS.


Previous Next Contents Index