By default, the FTP server creates several log files you can use to monitor the service and user transactions. These log files are:

• SYS$SYSDEVICE:[TCPIP$FTP]TCPIP$FTP_RUN.LOG
• SYS$SYSDEVICE:[TCPIP$FTP]TCPIP$FTPD.LOG
  This log contains an abbreviated dialog of each new connection process. It is created by each new invocation of the server and is accessible only after an ongoing connection times out or is closed by the user.
• SYS$SYSDEVICE:[TCPIP$FTP]TCPIP$FTP_ANONYMOUS.LOG
  This log contains Anonymous FTP entries that show:
  • The user name and source host (FTP client) for the session
  • The time the session was initiated and terminated
  • The FTP command that was entered
  • A time notation for the command
  • The source and destination file names

• TCPIP$FTP.LOG
  This log is created in the user's default login directory.

The number of log files (one per FTP transaction) might become large. To limit the number of versions, enter:

$ SET FILE file /VERSION=n

DIGITAL TCP/IP Services for OpenVMS software includes client and server implementations of the Berkeley Remote (R) command applications: RCP, RLOGIN, RSH, REXEC, and RMT/RCD. These applications provide end users with the following capabilities:

RCP	Remote copy allows files to be copied to or from remote hosts. Its syntax is similar to the UNIX cp command, except that the path name can include the name of a remote host.
RLOGIN	Remote login provides interactive access to remote hosts. Its function is similar to TELNET.
RSH	Remote shell passes a command to a remote host for execution. Standard output from the remote execution is returned to the local host.
REXEC	Similar to the UNIX rsh command, remote execution authenticates and executes RCP and other commands. The authentication is based on password information stored in the OpenVMS system's user authorization file (UAF). REXEC is useful if the remote host does not have, or might not have, the authentication information that the RSH protocol requires.
RMT/RCD	Remote access to magnetic tape and CD-ROM drives

This chapter reviews key concepts and explains how to configure the R command applications on your local host. For information on using these applications, see the DIGITAL TCP/IP Services for OpenVMS User's Guide.

13.1 Reviewing Key Concepts

In addition to password authentication, the R commands use a system based on trusted hosts and users. Trusted users on trusted hosts are allowed to access the local system without providing a password. Trusted hosts are also called "equivalent hosts" because the software assumes that users given access to a remote host should be given equivalent access to the local host. The system assumes that user accounts with the same name on both hosts are "owned" by the same user. For example, the user logged on as molly on a trusted system is granted the same access as a user logged in as molly on the local system.

This authentication system requires databases that define the trusted hosts and the trusted users. On UNIX systems, these databases are:

• /etc/hosts.equiv defines the trusted hosts and users for the entire system
• .rhosts defines the trusted hosts and users for an individual user account. This file is located in the user's home directory.

On OpenVMS hosts, the proxy database TCPIP$PROXY.DAT defines trusted hosts and users for the entire system.

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

TCPIP> ADD PROXY user /HOST=host /REMOTE_USER=user

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

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 consistently. In the proxy database, if the user name is in:

• Uppercase, the user must use the /NOLOWERCASE qualifier.
• Lowercase, RSH and RLOGIN default to /LOWERCASE.

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.

13.2.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
.rhosts (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:

TCPIP> SET SERVICE service /FLAGS=APPLICATION_PROXY

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:

TCPIP> SET SERVICE RLOGIN /REJECT=HOSTS=(loon,ibis,tern)

13.2.2 Case-Sensitivity Flag

When users enter RSH and RLOGIN commands without the /LOWERCASE qualifier, the commands default to ON. 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.)

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

$ DEFINE /SYSTEM TCPIP$RLOGIN_MESSAGE "OpenVMS RLOGIN Server Version 5.0"

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

13.4.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.
   • Create the OpenVMS account named ROOT. This account must have PHYIO and VOLPRO privileges.
   • Create a communication proxy that associates the remote RMT client user with the OpenVMS account ROOT on the RMT server host. For example:

     TCPIP> add proxy root /HOST=host /REMOTE=user

     
     (See Section 13.2 for more information about communication proxies.)

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 output as follows:

   $RMT_VERIFY = 'F$VERIFY(0) . . . $IF (F$MODE() .NES. "OTHER") THEN $RMT_VERIFY = F$VERIFY(RMT_VERIFY)

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 the user restore files selectively using rrestore.

When the remote user enters these remote dump and restore commands, he or she must specify either the OpenVMS device name or a file name. If the user specifies a device name, it must be a valid OpenVMS type of magnetic tape device name.

See the sections on dump, rdump, restore, and rrestore in your particular client system's documentation for details. The user should be careful about the order in which he or she specifies 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.

The RMT/RCD server lets you specify the qualifiers with magnetic tape device names indicated in Table 13-1.

Table 13-1 RMT Magtape Qualifiers

Qualifier	Defines
/[NO]ASSIST	Whether to use operator assistance to mount the volume. /NOASSIST is the default.
/BLOCKSIZE= n	Default block size for magnetic tape volumes. The default is 65534 bytes.
/COMMENT= "string"	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	Density (in bits per inch) at which to write a foreign or unlabeled magnetic tape. The default is the current density.
/[NO]MOUNT	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	Whether to rewind the drive when it is closed. The default is /REWIND.
/[NO]STREAM	Whether to read the tape in record /NOSTREAM or byte-stream /STREAM mode. The default is /STREAM.
/[NO]UNLOAD	Whether to unload the drive when it is closed. The default is /UNLOAD.
/[NO]WRITE	Whether you can write to the volume. The default is /WRITE.

Table 13-2 indicates the supported option for remote access to the local CD-ROM drive.

Table 13-2 RMT CD-ROM Qualifiers

Qualifier	Defines
/CD	Indicates that the remote device is a CD-ROM device.

13.4.3 Client Examples

The following steps perform rdump and rrestore 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 keep OpenVMS from rewinding the tape. Although rdump on the UNIX system can report that OpenVMS rewound the tape, it did not actually do so. 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 can display messages such as "You have not read any volumes yet" and ask you to specify the next volume. Although the messages might appear, rrestore should work properly.

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

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

In the next 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

The Simple Mail Transfer Protocol (SMTP) is the standard protocol used as 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 does not specify the mail interface.

The DIGITAL TCP/IP Services for OpenVMS product implements SMTP as an OpenVMS symbiont that works with OpenVMS mail.

This chapter reviews key concepts and describes how to configure, customize, and manage the SMTP symbiont. See the DIGITAL TCP/IP Services for OpenVMS User's Guide for information on using SMTP to send and receive mail.

14.1 Reviewing Key Concepts

To be reliable, electronic mail systems must be able to cope with situations where the recipient is temporarily unavailable, for example, 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 reaching its final destination. Note that this behavior differs from OpenVMS mail, where mail is sent directly from the originating node to the destination node.

14.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 SMTP implementation, 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 which runs the receiver. The receiver image is SYS$SYSTEM:TCPIP$SMTP_RECEIVER.EXE. The receiver process runs in the TCPIP_SMTP account.

If configured, 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 14.3 for more information on configuring SMTP.

After receiving a client request, the SMTP server responds, indicating its status (available/not available) and if available, 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 and starts the SMTP symbiont and initiates a 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 email 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 recipient.
6. The client sends the body of the message.

A minimum of five control message commands are required to conduct the above sequence of events. Table 14-1 describes these commands.

Table 14-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.

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

yymmddhhsshh_username.TCPIP_scnode

where:

yymmddhhsshh	The timestamp taken when the file is created.
username	The user name of the process in which the control file was created. Values for this name include: TCPIP$SMTP --- The mail arrived through SMTP. The file was created by the SMTP receiver process running in the TCPIP$SMTP account. MAIL$SERVER --- The mail arrived over DECnet and was destined for an SMTP address. In this case, the control file is created by the DECnet MAIL11 network object that runs the MAIL$SERVER account. This happens when the user sets mail forwarding to an SMTP address. SYSTEM --- If the control file is in the TCPIP$SMTP account directory, this indicates the message is undeliverable mail. username --- Mail composed by the user and sent to an SMTP address.
scnode	Value of the SYSGEN SCNODE parameter.

14.1.3 Understanding SMTP Headers

• Resent-Reply-To
• Resent-From
• Reply-To
• Resent-Sender
• Sender
• Return-Path

SMTP scans the message headers, comparing them to the above list. The first header found is used for the OpenVMS mail header From:.

You can modify the following SMTP defaults related to SMTP headers:

• 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. Start the SMTP mail queue.
• 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: line.
  If an X-VMS-To or X-VMS-Cc RFC header is not present, SMTP puts the header in the OpenVMS mail To: line.
  If you do not want to put these headers in the OpenVMS mail To: and CC: lines:
  1. Define the system logical name TCPIP$SMTP_INBOUND_NOXVMS.
  2. Start the SMTP execution queue.

SMTP handles forwarded incoming mail even if the SMTP configuration database relay option is not set.