DIGITAL TCP/IP Services for OpenVMS
Management

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 this example, rrestore extracts the filename from dump file number 2 on the tape:

 
UNIX>/etc/rrestore fsx vax:device/nomount/nounload/norewind 2 
filename 
 

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

12.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 offline. Mail must also be able to handle situations where some of the recipients on a distribution 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.

12.1.1 How SMTP Clients and Servers Communicate

In most implementations, SMTP servers listen at port 25 for client requests. In the UCX SMTP implementation, the auxiliary server listens for client requests and starts the SMTP symbiont as needed.

If configured, the SMTP symbiont processes all mail on a UCX 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 UCX$CONFIG sets up the SMTP queues for you. See Section 12.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 12-1 describes these commands.

Table 12-1 SMTP Client Commands

Command	Description
HELO	Used to identify 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>	The 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.

12.1.2 Understanding the SMTP Control File

With UCX 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.UCX_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: UCX_SMTP --- The mail arrived via SMTP. The file was created by the SMTP receiver process running in the UXC_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 UCX_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

12.1.3 Understanding SMTP Headers

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

UCX 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 UCX$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 via 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 VMSmail To: and CC: lines:
  1. Define the system logical name UCX$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.

  12.1.4 Understanding SMTP Addresses

  SMTP addresses are of the form userID@domain.name, where domain.name refers to a valid DNS domain. Mail exchange (MX) records point electronic mail to a particular address (host and account) in that domain.

  12.1.5 How SMTP Routes Mail

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

  1. Local MX database
  2. Remote MX database
  3. BIND database
  4. Local hosts database

  MX routing first checks the local preference but tries it only once in the lookup process.

  12.1.5.1 Using MX Records

  SMTP uses the information stored in MX records to route mail. Each MX record contains a list of hosts that can accept mail for the specified destination. The list is in order of routing preference. Each MX record contains the following fields:

  Destination domain	Indicates the mail destination. Multiple MX records for the same destination are allowed.
  Gateway host name	The name of the host through which mail is routed.
  Preference	Prioritizes multiple MX records for the same destination domain. The lower the preference value, the higher the priority for the MX record.

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

  • Enables load balancing between mail routers.
  • Mail continues to be routed even if one mail router is unavailable (i.e., down).
  • Provides MX-based routes for mail internal and external to a firewall.

  Use the SET MX_RECORDS command to enter routing information to the MX database. See the DIGITAL TCP/IP Services for OpenVMS Management Command Reference for a detailed desciption of the SET MX_RECORDS command.

  12.1.5.2 Using SMTP Zone and Alternate Gateway

  When configuring 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 supply a domain name, the zone defaults to one level higher than your local domain. For example, if your local domain is a.b.com, the default value of /ZONE is b.com (assuming that, because UCX has been started, the domain is known).

  Mail for delivery outside of your zone is sent to its destination by the alternate gateway, as defined by the /GATEWAY qualifier. This is an alternate route through which SMTP sends mail if delivery fails. If you define an alternate gateway, SMTP checks if the gateway is part of or outside of your local domain and relays the mail accordingly. If you do not specify an alternate gateway, SMTP uses the MX records to determine which host should relay mail.

  For example, the following command assigns MERLIN as the gateway for CROW with a preference 100.

  UCX> SET MX_RECORDS CROW /GATEWAY=MERLIN /PREFERENCE=100 
  

  12.2 Starting and Stopping SMTP

  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 UCX auxiliary server.

  To start the SMTP sender, issue @SYS$MANAGER:UCX$SMTP_STARTUP.

  To enable the receiver, issue UCX ENABLE SERVICE SMTP.

  To stop SMTP, issue @SYS$MANAGER:UCX$SMTP_SHUTDOWN.

  12.3 Configuring SMTP

  Use the configuration procedure UCX$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 will retry 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 DIGITAL TCP/IP Services for OpenVMS Management Command Reference.

  12.3.1 Mail Utility Files

  Outgoing mail files are stored in the user profile default directory. Incoming mail files are temporarily stored by the receiving process in the SYS$SPECIFIC:[UCX_SMTP] directory. These files have names such as:

  92022509472729_USERNAME.UCX_HOSTNAME

  or

  92022509472729_SYSTEM.UCX_HOSTNAME

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

  Table 12-2 Default SMTP Utility Files

  File Name	Description
  LOGIN.COM	Used by the auxiliary server
  UCX_SMTP_RECV_STARTUP.COM	Used by the auxiliary server
  UCX_SMTP_LOGFILE.LOG	Log of mail queue and symbiont activities
  UCX_SMTP_RECV_LOGFILE.LOG	Log of incoming mail

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

  12.3.2 Creating a Postmaster Account

  The Postmaster account is a required account that receives all undelieverable mail. The SMTP process account serves as the Postmaster account by default. You can change this by specifying a different account name with the /POSTMASTER qualifier to the SET CONFIGURATION SMTP command.

  To set up a Postmaster account, follow these steps:

  1. Check that the spooling directory is in a SYS$SPECIFIC directory.
  2. Ensure that the Postmaster account can gain access to the spooling directory.
  3. Define the same user name and Postmaster in the SMTP service's definition.

  SMTP requires that the system be able to receive mail addressed to the user name POSTMASTER. To meet this requirement, do one of the following:

  • Set OpenVMS mail to forward the mail addressed to POSTMASTER to either the UCX_SMTP or the SYSTEM accounts.
  • Create a distribution file named POSTMASTER.DIS that contains the system manager's mailing address.

  12.4 Managing the SMTP Symbiont Queues

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

  Table 12-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.	¹
  ENABLE SERVICE SMTP	Initializes communications for SMTP.	¹
  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.	¹
  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.	¹
  START MAIL	Starts the SMTP queuing mechanism.	SYSPRV or BYPASS
  STOP MAIL	Stops the SMTP queuing mechanism.	SYSPRV or BYPASS

  ---

  ¹Indicates that the command follows OpenVMS file protection rules.
  

  ---

  12.4.1 Displaying Queues

  To monitor the mail queues, examine the UCX_SMTP_LOGFILE.LOG and the UCX_SMTP_RECV_STARTUP.LOG files.

  12.4.2 Changing the Number of Queues

  To change the number of SMTP queues, follow these steps:

  1. Stop SMTP and MAIL on the root node by entering the following commands:

     UCX> DISABLE SERVICE SMTP 
     UCX> STOP MAIL 
     

  2. Change the SMTP configuration by entering the command

      UCX> SET CONFIGURATION SMTP/QUEUES=new_number
     

  3. Restart SMTP and MAIL by entering the following commands:

     UCX> ENABLE SERVICE SMTP 
     UCX> START MAIL 
     

  12.4.3 Restarting a Stopped Queue

  To restart a stopped queue, run the CHECK_RESTART_SMTP_Q.COM command procedure. Issue:

  $ @CHECK_RESTART_SMTP_Q.COM 
  

  12.4.4 Displaying SMTP Routing Information

  To display SMTP routing information, use the SHOW MX_RECORDS command. If you:

  • Omit destination --- you see the entries in the local MX database.
  • Specify destination --- you see all the entries in all the databases that UCX would look at, if necessary to resolve the address. The local MX database and the BIND MX database are usually as far as UCX needs to search.

  Example 1:
  This example displays, in order of preference, the routing hops to reach host SWAN if an attempt fails. The local host tries to route through:

  1. WATER.PIPIT.WEBBED.FEET.COM
  2. bd-gw.purple.martin.com
  3. great.horned.owl.com
  4. bird.food.seeds.worms.com

  In the display:

  • The Gate name field tells where to relay the mail.
  • The Gate address field gives the gateway's IP address.
  • The Preference field gives each MX record a precedence. Lower preference number means higher precedence.

  UCX> SHOW MX_RECORDS SWAN 
                                BIND MX database 
   
  Server:          18.18.218.10     GREAT.HORNED.OWL.COM 
   
  Gate address     Preference       Gate name 
   
  18.18.218.10     50               WATER.PIPIT.WEBBED.FEET.COM 
  18.1.218.16      100              bd-gw.purple.martin.com 
  188.88.206.2     200              great.horned.owl.com 
  199.9.214.1      300              bird.food.seeds.worms.com 
   
   
                                BIND database 
   
  Server:          18.18.218.10     WATER.PIPIT.WEBBED.FEET.COM 
   
  Host address                      Host name 
   
  18.18.100.10                      SWAN.WEBBED.FEET.COM 
  

  Example 2:
  This example displays the MX records for destination host crow.com. In the display:

  • The Gate name field tells where to relay the mail.
  • The Gate address field gives the gateway's IP address.
  • The Preference field gives each MX record a precedence. Lower preference number means higher precedence.

  The local host is WATER, the alternate gateway is scare.crow.com, and the zone is crow.com. The first preference for delivering mail to crow.com is to try to send to cawcaw.crow.com.

  If you have not defined an alternate gateway, SMTP tries to relay the mail to scare.crow at IP address 158.228.12.253 in the zone, not the destination host name. Therefore, SMTP checks to see if cawcaw.crow is in the zone daw.com.

  UCX> SHOW MX_RECORDS CROW.COM 
                               BIND MX database 
   
  Server:          18.18.218.10     WATER.PIPIT.WEBBED.FEET.COM 
   
  Gate address     Preference       Gate name 
   
  159.228.12.253   1                cawcaw.crow.com 
  159.228.12.254   2                scare.crow.com 
  

  Example 3:
  The following example shows the local MX configuration for destinations JUNCO and ubird.edu.

  • Messages from JUNCO are routed to TURKEY.
  • If TURKEY fails, SMTP then routes them to HERON.
  • Messages from ubird.edu are routed to owl.wise.mouser.edu.
  • If owl.wise.mouser.edu fails, SMTP then routes them to tragopan.asian.pheasant.edu.

  UCX> SHOW MX_RECORDS JUNO
   
                                Local MX database 
   
  Destination                  Preference      Gateway 
   
  JUNCO                            8           HERON 
                                   2           TURKEY 
  ubird.edu                        100         tragopan.asian.pheasant.edu 
                                   50          owl.wise.mouser.edu 
  

  12.4.5 SMTP Logging

  SMTP logs mail queue and mail symbiont events to the following files:

  • UCX_SMTP_LOGFILE.LOG
  • UCX_SMTP_RECV_STARTUP.LOG

  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.

  Logical names are available to modify the way SMTP logs information and the type of information it reports.

  12.5 Modifying Your SMTP Configuration

  You can modify your SMTP configuration by defining logical names that are translated at queue startup time. Characteristics you can affect include:

  • Event and error logging diagnostics
  • How mail headers are displayed
  • How mail is routed
  • How SMTP interacts with OpenVMS mail

  Some SMTP logical names are used to either enable or disable a configuration option and do not require a value. If you define the logical name, the option is considered to be enabled. If not defined, the option is disabled. To disable an option, simply remove the logical name.

  For example, to enable message logging for messages received from and transmitted to remote SMTP clients, define the UCX$SMTP_RECV_TRACE as follows:

  $ DEFINE/SYSTEM UCX$SMTP_RECV_TRACE 
   
  

  Other logical names require you supply a value. For example, to enable logging that provides information about symbiont activity during control file processing, define the logical name UCX$SMTP_LOG_LEVEL with value of 3. For example:

  $ DEFINE/SYSTEM UCX$SMTP_LOG_LEVEL 3 
   
  

  The descriptions below indicate where a value is required.

  ---

  Note

  Define the SMTP configuration logical names as /SYSTEM except where noted.

  ---

  • UCX$SMTP_LOG_LEVEL value
    Writes diagnostic information to the log file. Valid numeric values are as follows:

    Value 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.
    Value 3	Provides additional information to the above about symbiont initialization and activity during control file processing.
    Value 5	Enables full symbiont diagnostics. For use only under the advice of the DIGITAL customer support.

  • UCX$SMTP_NOSEY
    Used with UCX$SMTP_LOG_LEVEL to print the full subject RFC headers information. If not defined, header is logged only as SUBJECT:.
  • UCX$SMTP_LOG_LINE_NUMBERS
    Writes line numbers to SMTP logs. Includes the symbiont, receiver, and MAIL$PROTOCOL (DEBUG.TXT) logs.
  • UCX$SMTP_SYMB_TRACE
    Logs all messages received from and transmitted to remote SMTP servers. Used to to trace the SMTP application layer protocol. Any unprintable or control characters that are sent or received are printed as \n where n is the hexadecimal value of the character. For example, command lines and replies are terminated with a <CR><LF> that appear in the log as follows:

    send buf=MAIL FROM:<jones@acme.com>\d\a 
    recv buf=250 <jones@acme.com>... Sender OK\d\a 
    

    
    where \d\a is the <CR><LF>.
  • UCX$SMTP_RECV_TRACE
    Logs all messages received from and transmitted to remote SMTP clients. The same conventions for logging unprintable or control characters are used. Obsoletes the logical name UCX$SMTP_PROTO_TRACE.
  • UCX$SMTP_RECV_DEBUG
    Logs full diagnostics, similar to the UCX$SMTP_LOG_LEVEL 5 logical name. Obsoletes the logical name UCX$SMTP_PROTO_DEBUG.
  • UCX$SMTP_VMSMAIL_SEND
    Instructs MAIL$PROTOCOL to log diagnostics to a file named DEBUG.TXT in the default directory. (Used primarily by DIGITAL.)

  • UCX$SMTP_VMSMAIL_PARSE
    Causes the SMTP address parsing code to log diagnostics. The symbiont, receiver, and MAIL$PROTOCOL code are sensitive to this logical name, which is used primarily by DIGITAL.
  • UCX$SMTP_SYMB_SNAPSHOT_BLOCKS numeric value
    Enables snapshot logging for the symbiont. The value you assign is the desired size of the snapshot buffer in OpenVMS blocks (1 block being 512 bytes). Use with UCX$SMTP_LOG_LEVEL. Note that when you enable snapshot buffering for the symbiont, it takes some time for the symbiont process to stop when you issue a UCX STOP MAIL command or you stop the queue, depending on the size of the snapshot buffer and the speed of the system and its disks.
    For example, the following command line sets the log level to 5 and enables snapshot logging for the SMTP symbiont with a snapshot buffer of 200 blocks:

    $ DEFINE/SYSTEM UCX$SMTP_LOG_LEVEL 5 
    $ DEFINE/SYSTEM UCX$SMTP_SYMB_SNAPSHOT_BLOCKS 200 
    

  • UCX$SMTP_RECV_SNAPSHOT_BLOCKS numeric value
    Enables snapshot logging for the receiver. The value you assign is the desired size of the snapshot buffer in OpenVMS blocks (1 block being 512 bytes). Use with UCX$SMTP_LOG_LEVEL.
    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 UCX$SMTP_RECV_DEBUG 1 
    $ DEFINE/SYSTEM UCX$SMTP_RECV_TRACE 1 
    $ DEFINE/SYSTEM UCX$SMTP_RECV_SNAPSHOT_BLOCKS 200 
    

  • UCX$SMTP_NO_SUBS_DOMAIN_INBOUND
    Instructs SMTP not to consider mail that is sent to the substitute domain as local mail.
  • UCX$SMTP_COMMON string
    By default, SMTP looks for the .DIS and local alias files in the SYS$SPECIFIC:[UCX_SMTP]. Use this logical name to change the default cluster common directory. You must:
    • Define this logical name before SMTP startup.
    • Create the directory.
    • Move the .DIS files or the local alias file, or both, to the directory.
    
    You can also use this logical name as a search list. For example, you might want SMTP to look at the clusterwide directory and then the SYS$SPECIFIC:[UCX_SMTP] directory, as follows:

    $ DEFINE/SYSTEM UCX$SMTP_COMMON WORKDISK:[SMTP_DIS], - 
    _$ SYS$SPECIFIC:[UCX_SMTP] 
    

    
    Note that other files such as control files and log files reside in the SYS$SPECIFIC:[UCX_SMTP] directory.
  • UCX$SMTP_JACKET_LOCAL
    Instructs the symbiont to put the SMTP jacket on local-to-local mail to provide sufficient information to the POP server.
  • UCX$SMTP_INBOUND_NOXVMS
    Instructs the symbiont not to use the RFC X-VMS-To header as the text of the OpenVMS mail To: line and the X-VMS-CC header as the text of the CC: line. Instead, the RFC To: and CC: lines are used. If the UCX$SMTP_INBOUND_NOXVMS option is not defined, the SMTP symbiont uses the text of the X-VMS-To and X-VMS-CC lines for the mail header lines.
  • UCX$SMTP_VMSDEF_TO
    Instructs the symbiont not to pass any text for the To: line to OpenVMS callable mail when delivering local mail. This option causes OpenVMS callable mail to use the default text for the To: line (the user name). Overrides the UCX$SMTP_INBOUND_NOXVMS option for the To: field.
  • UCX$SMTP_MTS_ALLIN1
    Used in older UCX versions. When relaying mail from the SMTP environment to MTS (the message router), the symbiont puts UCX_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 Versions 3.3A.
  • UCX$SMTP_REWRITE_MTS_FROM
    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.
  • UCX$SMTP_ALTGATE_ALWAYS
    Instructs the symbiont to send all mail that is destined for another system (non-local mail) to the alternate gateway. Zone check is not performed.
  • UCX$SMTP_MX_IF_NOALTGATE
    Instructs the symbiont to use MX records to connect to a host if the alternate gateway cannot be reached.
  • UCX$SMTP_NO_MX
    Instructs the SMTP symbiont not to 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.

  ---

  Chapter 13
  Configuring and Managing the POP Server

  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.

  ---

  Previous | Next | Contents