HP TCP/IP Services for OpenVMS

Previous Contents Index

17.3 Security Considerations

Because R commands can bypass normal password verification, it is important to configure these applications carefully to avoid compromising system security. In a complex networking environment, improperly configured R commands can open access to your host to virtually anyone on the network.

A properly configured environment grants remote access to preauthorized clients. You can limit access by adding an entry to the proxy database (TCPIP$PROXY.DAT) for each user authorized to access your host. This entry, called a communication proxy, provides the user name and name of the remote host. To add a communication proxy, enter:


For each host, be sure to define the host name and any aliases.

Users with communication proxies cannot use virtual terminals. Therefore, if the logical name TCPIP$RLOGIN_VTA is set, users logging in by proxies will observe that the terminal device they are assigned is displayed as TNAnnn rather than VTAnnn. For more information, see Section 17.2.2.

17.3.1 Registering Remote Users

For users on UNIX hosts, the following information must be listed in at least one of the following databases:
Database File Type of Information
/etc/hosts.equiv Host name and user name
(in the user's home directory)
Host name and user name

For users on OpenVMS clients running TCP/IP Services, check that the appropriate proxy information is in the remote system's proxy database.

You can also restrict remote printing to specific users by entering:


With this flag set, the R commands use the communication entries in the proxy database for authentication.

To reject access from a remote host, use the SET SERVICE service /REJECT command. For example:


17.3.2 Case-Sensitivity Flag

The proxy database is case sensitive for remote user names. The case you use for communications entries affects the way users access your host, so use case in a consistent fashion. In the proxy database, if the user name is in:

If the flag CASE_INSENSITIVE is set, the server matches an incoming user name with an all-lowercase or an all-uppercase remote user name in the proxy database.

The case-sensitivity flag for RLOGIN, RSH, and RCP defaults to CASE_INSENSITIVE. With this setting, the server accepts both all-uppercase and all-lowercase user names.

Ensure that RSH is enabled, because no RCP service exists. Instead, RCP uses the RSH server process. (RCP uses RSH or REXEC to do its work. RSH must be configured properly for RCP to work.)

17.4 Creating a Welcome Message

To modify the welcome message displayed by the RLOGIN server, define the TCPIP$RLOGIN_MESSAGE logical name and specify the text. For example, the following command defines a welcome message for RLOGIN clients when they log in to the server:


17.5 Remote Magnetic Tape and Remote CD-ROM (RMT/RCD)

The Remote Magnetic Tape/Remote CD-ROM (RMT/RCD) server provides remote system access to local OpenVMS magnetic tape and CD-ROM drives. The tape or CD-ROM drives appear to the RMT client users as if they were mounted locally. The RMT server fully implements the UNIX commands rdump and rrestore and the OpenVMS commands MOUNT, BACKUP, COPY, and EXCHANGE.

This section assumes that you are familiar with device mounting and server access conditions relevant to the R command services.

17.5.1 Preparing Drives for Remote Mounts

Perform the following tasks to make sure the remote client can access the tape or CD-ROM drive:

  1. Enable the RSH, REXEC, and RMT services.
  2. Load a magnetic tape or CD-ROM into the device.
    With a tape device, the client mounts and allocates the tape; you do not need to perform this task.
    With a CD-ROM device, you need to make the device accessible by entering a MOUNT /SYSTEM command.
  3. Make sure the remote shell command (RSH) works from the UNIX root account.
  4. Make sure the rsh command works from the user's account on the remote UNIX host.
  5. For the OpenVMS account ROOT, suppress SYS$LOGIN and LOGIN.COM in batch job output by entering the following commands in the command procedure:

    $ RMT_VERIFY = 'F$VERIFY(0) 

17.5.2 Client Utilities

On the remote host, a user can use rdump to dump files to OpenVMS tapes, or rrestore to restore files from OpenVMS tapes. The functionality of rdump and rrestore depends entirely on the type of UNIX system you use and not on the RMT service. For example, not all UNIX systems let you restore files selectively using rrestore .

When you enter these remote dump and restore commands, you must specify either a valid OpenVMS magnetic-tape device name, or a file name.

See the sections on dump, rdump, restore , and rrestore in your client system's documentation for details. Be careful about the order in which you specify options on the command line.

Here is an example of an rdump command:

> /etc/rdump 0f lilac:mua0:/nomount/density=1600 /usr 

In the example, the remote user requests to remotely dump the /usr file system onto device mua0: on system lilac and specifies the /nomount qualifier and a tape density of 1600 bits per inch.

You can specify the qualifiers described in Table 17-2 with magnetic-tape device names.

Table 17-2 RMT Magtape Qualifiers
Qualifier Description
/[NO]ASSIST Specifies whether to use operator assistance to mount the volume. The default is /NOASSIST.
/BLOCKSIZE= n Specifies the block size for magnetic tape volumes. The default is 65534 bytes.
/CD Indicates that the remote device is a CD-ROM device.
/COMMENT= "string" Specifies additional information included with the operator request when the mount operation requires operator assistance (/ASSIST). The comment appears in the OPCOM message for the operator.
/DENSITY= n Specifies the density (in bits per inch) at which to write a foreign or unlabeled magnetic tape. The default is the current density.
/[NO]MOUNT Specifis whether to use the OpenVMS MOUNT service to mount the tape. /NOMOUNT gains access to the tape directly without mounting it. Use this for UNIX utilities that expect the tape drive to hold its position (not rewind) if the utility closes it. The default is /MOUNT.
/[NO]REWIND Specifies whether to rewind the drive when it is closed. The default is /REWIND.
/[NO]STREAM Specifies whether to read the tape in record mode (/NOSTREAM) or byte-stream mode (/STREAM). The default is /STREAM.
/[NO]UNLOAD Specifies whether to unload the drive when it is closed. The default is /UNLOAD.
/[NO]WRITE Specifies whether you can write to the magnetic tape. The default is /WRITE.

17.5.3 Client Examples

The following steps perform rdump and rrestore functions from a UNIX client system. These commands dump two UNIX directories to the tape with separate rdump commands. These commands then restore files selectively from the tape to the UNIX client system:

  1. Put the directories on the tape by entering two rdump commands. Specify the /nomount/norewind/nounload qualifiers to prevent OpenVMS from rewinding the tape. Although the UNIX system reports that the tape was rewound, it was not actually rewound. The commands are:

    UNIX> /etc/rdump 0f vax:device/nomount/norewind/nounload dir1 
    UNIX> /etc/rdump 0f vax:device/nomount/norewind/nounload dir2 

  2. Restore the files selectively from the tape using rrestore . Be sure the tape is loaded and rewound. Use either the interactive or noninteractive command syntax.

The rrestore command might display messages such as "You have not read any volumes yet" and then ask you to specify the next volume. Although these messages might appear, rrestore should work properly.

In the following example, rrestore extracts the file specified by file_name from dump file number 2 on the tape:

UNIX> /etc/rrestore fsx vax:device/nomount/nounload/norewind 2 file-name

In the following example, rrestore invokes the interactive utility to let the user specify particular files that were put on the tape in dump file 2. The add command then adds the files to the extraction list and the extract command restores them:

UNIX> /etc/rrestore fis vax:device/nomount/nounload/norewind 2 
restore> add file_name
restore> extract 

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 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:

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

When the network serves multiple email domains, as when the network is a merging of multiple legacy networks each with their own email domains, you may want to specify a list of zones.

To specify a list of zones, include the list in quotation marks. For example:

TCPIP> set conf smtp/zone="dec.com,hp.com,compaq.com,digital.com" 

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.


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:

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-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:

                                 BIND MX database 
   Server:          host.abc.com 
   Gate address     Preference       Gate name          100              mail11.abc.com          100              mail13.abc.com          200              mail2.abc.com          200              mail1.abc.com          300              mail21.abc.com          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:


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

Previous Next Contents Index