SMTP allows you to create a mail message in a file and send it to the SMTP mailer to be delivered with headers you specify. Using SFF, you can create automated tools that compose and send mail messages.

SFF is also useful for forwarding nontext (MIME) files because it prevents the mailer from encapsulating the MIME and SMTP headers in the body of a new mail message. In this way, SMTP functions like the redirect command on your personal computer.

17.7.1 SFF Security Measures

The ability to create messages with arbitrary headers could be used to spoof message headers. To limit this, the SFF mechanism includes the following security measures:

• Allows you to define the TCPIP$SMTP_SFF_REQUIRES_PRIV logical. If the logical is defined as 1, the process must have either BYPASS, SYSPRV, or OPER privilege set in order to use SFF.
• To help you track messages, SFF adds a Received: header to the headers you supply. This tells you the origin of an attempted spoofed message.

You can invoke SFF from an application or from DCL, as described in the following sections.

17.7.2 Invoking SFF from an Application

TCPIP$SMTP_MAILSHR.EXE contains a routine called TCPIP$SMTP_SEND_FROM_FILE. This routine is declared as follows:

unsigned int TCPIP$SMTP_SEND_FROM_FILE(infile_name, logfd, log_level) char *infile_name; FILE *logfd; int log_level;

The parameters for this routine are:

• infile_name
  Specifies the name of the text file that contains the RFC 822 mail message.
• logfd
  Specifies the file to which to log diagnostic messages. This file must be opened by the caller before calling this routine. If no log file is specified, output goes to SYS$OUTPUT. This parameter is optional.
• log_level
  Specifies the level of diagnostics to use: either 1 (on) or 0 (off). The default is 0 (no logging). This parameter is optional.

To call the routine, link with TCPIP$SMTP_MAILSHR.EXE/SHARE.

17.7.3 Invoking SFF from DCL

The SMTP_SFF command allows you to invoke SFF. To define SMTP_SFF as a foreign command so that you can use it from DCL, enter the following command:

$ SMTP_SFF:==$TCPIP$SYSTEM:TCPIP$SMTP_SFF.EXE

This command takes UNIX style parameters and passes them to SFF.

The command format is:

SMTP_SFF infile_name [-log logfile_name] [-loglevel log_level]

The parameters to this command are:

• infile_name
  Specifies the name of text input file containing the SMTP mail to send.
• logfile_name
  Specifies the name of the log file for diagnostic messages. The default is SYS$OUTPUT. This parameter is optional.
• log_level
  Specifies the debug log level: either 1 (on) or 0 (off). The default is 0 (no logging). This parameter is optional.

Users can specify an outbound alias that is applied to mail as it is sent and specifies the network address to which a reply will be sent. The outbound alias is defined using the TCPIP$SMTP_FROM logical, as described in Section 17.5.

To disable outbound alias processing (prevent the use of the TCPIP$SMTP_FROM logical), define the following system logical:

$ DEFINE/SYSTEM TCPIP$SMTP_PROHIBIT_USER_HEADERS 1

17.9 Solving SMTP Problems

To isolate an SMTP problem, follow these steps:

1. Check the directory SYS$SPECIFIC:[TCPIP$SMTP] for the following log files:
   • TCPIP$SMTP_LOGFILE.LOG
     This log file monitors queue activity.
   • TCPIP$SMTP_RECV_LOGFILE.LOG
     This log file is created with every message received.
   
   Purge the directory regularly.
2. Use the TCPIP$SMTP_LOG_LEVEL logical, as described in Section 17.5.
3. Check the mail in the TCPIP$SMTP account.
   Forward TCPIP$SMTP mail to the SYSTEM account for monitoring. By default, remote login to TCPIP$SMTP is not allowed.
4. Check the directory SYS$SPECIFIC:[TCPIP$SMTP] for lost mail.
   If an incoming mail message was undeliverable and the error message was also undeliverable, the SMTP control file is left in this directory, not in the queue.
5. Check the consistency of the SMTP queues against the directories with the SMTP utility files.
   Enter the ANALYZE MAIL command (see Section 17.9.1).

Use the ANALYZE MAIL command to verify the correspondence of the SMTP queues with SMTP control files. This command does the following:

• Checks that all the current entries in the SMTP queues have a supporting control file in the mail directory of a user. You can specify a user or analyze the mail of all users.
• Checks that there are no lost control files in the SMTP working directory.
• The /DELETE qualifier deletes each control file lacking a corresponding queue entry.
• The /REPAIR qualifier fixes these errors:
  • Resubmits for delivery each valid control file in the SMTP directory with no entry in an SMTP queue.
  • Deletes each invalid control file (fails the internal consistency check) and the corresponding queue entry.
  • Either requeues or deletes messages placed on hold.

The following examples show how to use the ANALYZE MAIL command:

1. The following command encounters a problem, displays a description and solution, and then requests confirmation before fixing each record.

   TCPIP> ANALYZE MAIL /REPAIR /CONFIRM %TCPIP-E-ANA_SUP_BADIICGSIZE, Problem: Bad initial inode cell group size: bad_value Solution: Will be replaced by default size: good_value CONFIRM [Y/N/G]:

2. The following command creates a summary of SMTP entries and control files for user DRAKE.

   TCPIP> ANALYZE MAIL DRAKE %TCPIP-I-ANA_RUNING, ANALYZE runs on node DODO %TCPIP-I-ANA_NOENTR, no queue entry found for file NEST3$:[DRAKE]93042311394417_DRAKE.UCX_DODO;1 %TCPIP-I-ANA_COMPLE, ANALYZE completed on node DODO %TCPIP-I-ANA_FEPAIR, found 0 file-queue entry pairs %TCPIP-I-ANA_DELQEN, deleted 0 queue entries %TCPIP-I-ANA_FILNOQ, found 1 files with no queue entries %TCPIP-I-ANA_FILHLD, holding 0 files in directory %TCPIP-I-ANA_FILDEL, deleted 0 files from the Postmaster directory %TCPIP-I-ANA_SUBFIL, submitted 0 files to the generic queue %TCPIP-I-ANA_FILACE, encountered 0 file access errors %TCPIP-I-ANA_NONCFF, found 0 non-unknown files in Postmaster directory %TCPIP-I-ANA_FILCOR, found 0 corrupted CF files in Postmaster directory

3. The following command:
   • Creates a summary of SMTP entries and control files for user DRAKE.
   • Requeues control files lacking corresponding queue entries.
   • Deletes control files created before November 24, 1999.

   TCPIP> ANALYZE MAIL DRAKE /REPAIR /DELETE=BEFORE=24-NOV-1999

You can prevent the SMTP client from converting 8-bit characters to 7-bit characters 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 set, the SMTP receiver tells SMTP clients that 8-bit characters are supported. In this case, the client does not convert them to 7-bit format.

The Post Office Protocol (POP) server and the Simple Mail Transfer Protocol (SMTP) server software work together to provide reliable mail management in a client/server environment.

The POP server acts as an interface to the mail repository. It accepts and stores mail messages for you, even when your client system is not connected, and forwards those messages to you at your request. POP is used mostly by PC clients to ensure that mail is received and retained even when the system is not connected to the network.

After the POP server is enabled on your system, you can modify the default characteristics by defining logical names.

This chapter reviews key POP concepts and describes:

• How to start up and shut down the POP server ( Section 18.2)
• How to modify POP server characteristics ( Section 18.3)
• How to enable MIME mail using POP ( Section 18.4)
• How to solve POP problems ( Section 18.5)

The POP server is an implementation of the Post Office Protocol Version 3 server (the public domain IUPOP3 server) specified in RFC 1725.

The POP server is intended to be used as a mail repository for:

• PC systems that may not be connected to a network for periods of time
• Smaller nodes that may not have sufficient resources to keep an SMTP server and associated local mail delivery system resident and continuously running

With POP, mail is delivered to a shared mail server, and a user periodically downloads unread mail. Once delivered, the messages are deleted from the server.

The POP server is assigned port 110, and all POP client connections are made to this port.

The following sections review the POP process and describe how the TCP/IP Services software implements POP. If you are not familiar with POP, refer to RFC 1725 or introductory POP documentation for more information.

18.1.1 POP Server Process

The POP server is installed with SYSPRV and BYPASS privileges and runs in the TCPIP$POP account, which receives the correct quotas from the TCPIP$CONFIG procedure. The POP server is invoked by the auxiliary server.

The POP server uses security features provided in the protocol and in the OpenVMS operating system, as well as additional security measures. These methods provide a secure process that minimizes the possibility of inappropriate access to a user's mail file on the served system.

You can modify the POP server default characteristics and implement new characteristics by defining the system logical names outlined in Section 18.3.

18.1.2 How to Access Mail Messages from the POP Server

To access mail messages from the POP server, you configure a user name and password, or the POP shared secret-password string, into your client mail application.

Your client system opens the TCP connection and attempts to access the server by entering applicable POP commands such as USER (user name) and PASS (password), or APOP (shared secret password). In addition, POP supports the UID command, which some POP clients use, where the UID (user identification) that POP creates for each mail message is a concatenation of the user name and the date of arrival.

Once your client system opens the TCP connection, the POP server issues the following greeting:

+OK POP server ready TCPIP V5.1 [hostname and IP_Address]

By default, the POP server reads mail from the user's OpenVMS NEWMAIL folder. If you do not instruct the POP server to delete the mail, the server either moves the mail to the MAIL folder (if the logical name TCPIP$POP_USE_MAIL_FOLDER is defined) or keeps it in the NEWMAIL folder (if the logical name TCPIP$POP_LEAVE_IN_NEWMAIL is defined). These logical names are described in Section 18.3.

18.1.3 How the POP Server Initiates and Manages a TCP Connection

The POP server starts the service by listening on TCP port 110. The client initiates a connection when it wants to make use of the POP service. The POP server sends either a greeting message confirming the connection (a message with the +OK prefix) or a message that the connection was not successful (a message with the -ERR prefix).

POP permits only two user name and password authorization attempts per TCP connection. After the second failure, POP closes the connection. Once connected, the client and server exchange commands and responses.

When the POP server detects a blocked TCP connection, it suspends output to the connection for 2 seconds to allow it to unblock. Upon retry, if the connection is still blocked, the POP server waits 4 seconds before trying again, and so on up to 32 seconds. If the connection is still blocked after 32 seconds, the POP server shuts down the connection and sends an error message to the log file, allowing other client connections to continue to operate.

18.1.4 How the POP Server Handles Foreign Message Formats

POP contains minimal support for mail messages that contain foreign formats. Such messages are usually binary and therefore are not transferred to the POP client. Instead, the POP server transfers the message headers, along with a brief message instructing the user to log in and extract the foreign message into a file. Foreign messages are moved into your MAIL folder; they are never deleted by the POP server.

18.1.5 How the POP Server Authorizes Users

Table 18-1 outlines the methods the POP server process uses to authorize user access.

Table 18-1 POP User Authorization Methods

Method	Description
Shared secret-password string	Most secure POP server access method. Initiated by the client system through the APOP command. Allows a user to become authorized by the POP server without the need to send a password over the network. Eliminates a potential path for unauthorized users to obtain a password and break into the system. POP requires a shared secret string from any user who wants to read mail using the APOP authorization method. For information about creating the shared secret string, see the DIGITAL TCP/IP Services for OpenVMS User's Guide.
User name and password	Least secure POP server access method. Initiated by the client system through the USER and PASS commands. The POP server authorizes the client to access the desired mailbox based on receipt of a valid user name and password. The user configures a user name and password into the POP client system. Each POP client has its own method of configuring. Note that the user name and password pair is the user name and password for the TCP/IP Services system, not for the POP client system. The POP client sends the user name and password pair to the server, and the server confirms the pair against that in the OpenVMS SYSUAF file. Note that the password is sent unencrypted over the TCP connection, which might cause security problems for some environments. Upon authorization, the POP server allows access to the user's OpenVMS mailbox.
OpenVMS SYSUAF settings on user accounts	Access to the POP server is not permitted if: Either the DISMAIL or DISUSER flags are set for the account. The account has expired according to the SYSUAF expiration date. Access has been denied because of an incorrect user name and password.
Ability to disable the USER and PASS commands	Allows the system manager to use the APOP authorization method for all POP clients, the more secure means of user authorization. When you disable the USER and PASS commands (by defining the logical name TCPIP$POP_DISUSERPASS), the POP server responds to the commands with a failure message.

18.1.6 Understanding POP Message Headers

Mail message headers sent by the POP server must conform to the standard specified for SMTP in RFC 822. Because many of the messages received on an OpenVMS system are not in the SMTP format (for example, DECnet mail or mail from another message transport system), the POP server builds a new set of headers for each message based on the OpenVMS message headers.

The headers on mail messages forwarded by the POP server are as follows:

POP Message Header	Obtained From
Date:	Arrival date of message. Changed to UNIX format.
From:	OpenVMS message From: field. Rebuilt to ensure RFC 822 compatibility. See Section 18.1.6.1.
To:	OpenVMS Mail To: field. Not rebuilt.
CC:	OpenVMS Mail CC: field. Not rebuilt.
Subject:	OpenVMS Mail Subj: field. Not rebuilt.
X-VMS-From:	OpenVMS Mail From: field. Not rebuilt.
X-POP3-Server:	Server host name and POP version information. Sent only if logical name TCPIP$POP_SEND_ID_HEADERS is defined.
X-POP3-ID:	Message UID. Sent only if logical name TCPIP$POP_SEND_ID_HEADERS is defined.

The POP server sends these message headers to the POP client unless all of the following conditions are true:

• The TCPIP$POP_IGNORE_MAIL11_HEADERS logical name is defined (see Section 18.3).
• The From: address is an SMTP address.
• The SMTP qualifier /OPTION=TOP_HEADERS is set.

Note that the POP server checks the SMTP configuration database to ensure that it has been configured with the qualifier /OPTION=TOP_HEADERS so that headers print at the top of the message. If the POP logical name TCPIP$POP_IGNORE_MAIL11_HEADERS is defined, the SMTP option TOP_HEADERS must also be set. If not, the POP server issues a warning in the log file and does not acknowledge the TCPIP$POP_IGNORE_MAIL11_HEADERS definition.

18.1.6.1 How POP Rebuilds the OpenVMS Mail From: Field

The most important message header is the From: header, because it can be used as a destination address if a reply is requested from the POP client. Therefore, the POP server rebuilds the OpenVMS Mail From: field in compliance with RFC 822 before sending the header to the POP client.

The different types of addresses that can appear in the OpenVMS Mail From: field are as follows:

Address Type	Address Format
SMTP	SMTP%" legal-address," where legal-address is an address that is compliant with RFC 822 and is commonly in the user@domain format
DECnet	node::username
User name	username
DECnet address within quotation marks	node::"user@host"
Cluster-forwarding SMTP address	node::SMTP% "user@domain"

A host name is local if one of the following is true:

• The host name is the same as the substitute domain specified in the SMTP configuration.
• The host name is found in the TCPIP$SMTP_LOCAL_ALIASES.TXT file.

Some POP client systems are confused by the use of personal names when you attempt to reply to a mail message or when the name contains commas or other special characters. If you define the TCPIP$POP_PERSONAL_NAME logical name outlined in Section 18.3, make sure you test the configuration carefully with your POP client systems.

The following sections describe how POP rebuilds the message From: field for each type of address.

18.1.6.1.1 SMTP Address

The POP server uses the SMTP address within the quotation marks to rebuild the From: field of an SMTP address. For example, message header From: SMTP%"james.jones@federation.gov" becomes:

From: james.jones@federation.gov

SMTP hides nested quotation marks by changing them to cent sign (¢) characters before passing them to OpenVMS Mail and then changing them back after a reply. The POP server removes any cent signs that designate double quotation marks. For example, the following message header:

From: SMTP%"¢ABCMTS::MRGATE::\¢ABCDEF::VIVALDI \¢¢@xyz.org"

Becomes:

From: "ABCMTS::MRGATE::\"ABCDEF::VIVALDI\""@xyz.org"

18.1.6.1.2 DECnet Address

The TCPIP$POP_DECNET_REWRITE logical name values define how the POP server rebuilds a DECnet address, as shown in the following list:

• GENERIC
  The entire address is changed to the SMTP format. For example, from host widgets.xyzcorp.com , the message header From: ORDERS::J_SMITH becomes:

  From: "ORDERS::J_SMITH"@widgets.xyzcorp.com

• NONE
  The From: line is sent to the POP client unmodified. For example:

  From: ORDERS::J_SMITH

  
  You cannot reply to this type of message because the SMTP server does not accept an address in this form.

• TRANSFORM
  The POP server attempts to translate the DECnet node name to a TCP/IP host name. If the name can be translated, the POP server checks to see whether the translated host name is local. If so, the From: header becomes an address in the form user@substitute-domain. If not, the From: header becomes an address in the form user@hostname. Note that the POP and SMTP servers call the same routine to determine if a host name is local.
  The following examples show some ways the POP server translates DECnet node names to TCP/IP node names. In these examples:
  • The local host name is orders.acme.widgets.com
  • ORDERS translates to "orders.acme.widgets.com"
    • The message header From: ORDERS::J_SMITH becomes:

      From: j_smith@orders.acme.widgets.com

    • For a substitute domain of acme.widgets.com , the message header From: ORDERS::J_SMITH becomes:

      From: j_smith@acme.widgets.com

    • If HOST12 translates to host12.acme.widgets.com , which is not local on orders.acme.widgets.com , the message header From: HOST12::J_JONES becomes:

      From: j_jones@host12.acme.widgets.com

    • If HOST13 does not translate and host orders.acme.widgets.com has no substitute domain defined, the message header From: HOST13::J_JONES becomes:

      From: "HOST13::J_JONES"@orders.acme.widgets.com