Message Exchange Management Guide April, 1990 This manual describes the management and operation of Message Exchange, electronic mail software for VMS systems. Revision/Update Information: This manual supersedes Message Exchange Management Guide, V1.1. Operating System and Version: VMS V5.0 or later Software Version: Message Exchange V1.2 Engineering Computing Services Rensselaer Polytechnic Institute Troy, New York ________________________ 09 April 1990 Permission is granted to copy and redistribute this document for no commercial gain. The information in this document is subject to change without notice and should not be construed as a commitment by Rensselaer Polytechnic Institute. Rensselaer assumes no responsibility for any errors that may appear in this document. DISCLAIMER: The software described in this document is provided "as is". No guarantee is made by the author or the author's employer as to the suitability, reliability, security, usefulness, or performance of this software. The following are trademarks of Digital Equipment Corporation: DEC ULTRIX VAX VAXcluster VMS Jnet is a trademark of Joiner Associates, Inc. __________ Copyright ©1990 Rensselaer Polytechnic Institute All Rights Reserved. Printed in U.S.A. This document was prepared using VAX DOCUMENT, Version 1.2 _______________________________________________________ Contents _________________________________________________ PREFACE vii _______________________________________________________ CHAPTER 1 GENERAL OPERATION 1-1 _________________________________________________ 1.1 THE COMPONENTS 1-1 _________________________________________________ 1.2 CONFIGURING THE SOFTWARE 1-2 _________________________________________________ 1.3 AUTOMATIC OPERATION 1-2 _________________________________________________ 1.4 VAXCLUSTER ENVIRONMENTS 1-3 _________________________________________________ 1.5 PROBLEM REPORTS AND SUPPORT 1-3 _______________________________________________________ CHAPTER 2 THE ROUTER MODULE 2-1 _________________________________________________ 2.1 ENVELOPE ADDRESSES 2-1 _________________________________________________ 2.2 ADDRESS REWRITING 2-2 _________________________________________________ 2.3 DOMAIN/PATH MAPPING 2-3 iii Contents _________________________________________________ 2.4 ALIAS TRANSLATION 2-4 _________________________________________________ 2.5 OTHER ROUTER FUNCTIONS 2-5 _______________________________________________________ CHAPTER 3 LOCAL PROCESSING MODULES 3-1 _________________________________________________ 3.1 THE LOCAL DELIVERY AGENT 3-1 _________________________________________________ 3.2 MESSAGE FORWARDING 3-1 _________________________________________________ 3.3 MAILING LISTS 3-2 3.3.1 General-User Requests _________ 3-2 3.3.2 Control Messages ______________ 3-3 _________________________________________________ 3.4 FILE SERVICE 3-3 3.4.1 Packages ______________________ 3-4 3.4.2 Help File _____________________ 3-5 3.4.3 File Server Commands __________ 3-5 _________________________________________________ 3.5 VMS MAIL INTERFACE 3-6 3.5.1 Signature Files _______________ 3-6 _______________________________________________________ CHAPTER 4 SMTP SUPPORT 4-1 _________________________________________________ 4.1 DELIVERY AGENT 4-1 iv Contents 4.1.1 Mail Exchange Support _________ 4-1 4.1.2 Default SMTP Router ___________ 4-2 4.1.3 Retries _______________________ 4-3 _________________________________________________ 4.2 SERVER MODULE 4-3 _______________________________________________________ CHAPTER 5 JNET INTERFACE 5-1 _________________________________________________ 5.1 THE MAIL/FILE DISPATCHER 5-1 _________________________________________________ 5.2 MX/JNET INTERFACE MODULE 5-1 5.2.1 XMAILER.NAMES _________________ 5-2 _______________________________________________________ CHAPTER 6 UUCP SUPPORT 6-1 _________________________________________________ 6.1 RMAIL PROGRAM 6-1 _________________________________________________ 6.2 UUCP DELIVERY AGENT 6-2 _______________________________________________________ CHAPTER 7 FILE QUEUE MANAGEMENT 7-1 _________________________________________________ 7.1 MAILQUEUE 7-1 _________________________________________________ 7.2 FLQU 7-2 v Contents 7.2.1 Interpreting FLQU SHOW Output _ 7-4 _______________________________________________________ CHAPTER 8 TROUBLESHOOTING MX 8-1 _________________________________________________ 8.1 QUEUE FILES USED BY MX COMPONENTS 8-1 8.1.1 File Types ____________________ 8-1 _________________________________________________ 8.2 PROCESS NAMES 8-3 _________________________________________________ 8.3 DEBUG/TRACE OUTPUT 8-4 _______________________________________________________ MCP COMMAND DICTIONARY MCP MCP-3 @ (REDIRECT COMMAND INPUT) MCP-5 DEFINE ALIAS MCP-6 DEFINE FILE_SERVICE MCP-7 DEFINE LIST MCP-10 DEFINE PATH MCP-15 DEFINE REWRITE_RULE MCP-16 DEFINE SYSTEM_USERS MCP-18 EXIT MCP-19 HELP MCP-20 MODIFY MCP-21 QUIT MCP-22 REMOVE MCP-23 SAVE MCP-24 SHOW MCP-25 vi Contents _______________________________________________________ INDEX _______________________________________________________ TABLES 2-1 Router file queue-related logicals ______________________ 2-6 7-1 FLQU commands _________________ 7-3 8-1 Debug/Trace logical names _____ 8-4 MCP-1 Mailing list protection classes _______________________ MCP-12 MCP-2 Mailing list protection codes _ MCP-13 MCP-3 Typical protection codes ______ MCP-14 vii _______________________________________________________ Preface This guide describes the management and operation of Message Exchange (MX). __________________________________________________________________ Intended Audience This manual is intended for use by the system manager or any individual responsible for installing and maintaining MX. The reader should be generally familiar with VMS system concepts, electronic mail systems and networking terminology. __________________________________________________________________ Document Structure This guide consists of two parts. Part I contains eight chapters, which contain information on management and operation of the various components of MX. Part II is the command dictionary for the MX Control Program (MCP). Chapter 1 Contains general information about Message Exchange. Chapter 2 Describes the MX Router module. Chapter 3 Describes the MX Local delivery module and VMS MAIL interface. Chapter 4 Describes the MX SMTP support modules. Chapter 5 Describes the MX Jnet interface modules. Chapter 6 Describes the MX UUCP interface modules. vii Preface Chapter 7 Describes the file queue management tools. Chapter 8 Describes the tools available for troubleshooting MX. __________________________________________________________________ Related Documents You can find additional information in the following documents: o Message Exchange Installation Guide describes the installation of MX. o Message Exchange User's Guide describes MX features available to general users. o Message Exchange Release Notes contain information and updates not included in this manual. The release notes are part of the software distribution kit. o RFC 821: Simple Mail Transfer Protocol describes the SMTP protocol. o RFC 822: Standard for the Format of ARPA Internet Text Messages describes the format of headers and addresses used by Internet hosts. viii _______________________________________________________ 1 General Operation __________________________________________________________________ 1.1 The Components Message Exchange (MX) is software that provides the routing and delivery of electronic mail messages. It is divided into five major components. The Router processes messages entering from all sources and determines, based on envelope information, which of the other components should be used to delivery each message. The Router is implemented as a detached process. The Local delivery modules include the delivery agent and the VMS MAIL interface. The local delivery agent includes a mailing list processor and a file server, and is implemented as a detached process plus permanent subprocess. The VMS MAIL interface is implemented as a shareable image implementing a VMS MAIL "foreign mail" protocol. The SMTP support modules include a delivery agent and a server for receiving messages from other systems. Both CMU-Tektronix TCP/IP and DEC's VMS/ULTRIX Connection are supported as transports (though not simultaneously on one system). Both the delivery agent and the SMTP server agent are implemented as detached processes. The Jnet interface includes a Jnet mail/file dispatcher and a processing agent that handles all inbound and outbound messages. The mail/file dispatcher is implemented as a shareable image in accordance with Jnet specifications. The processing 1-1 General Operation agent is implemented as a detached process with a permanent subprocess. The UUCP interface includes a program to capture incoming UUCP mail and transfer it into MX, and a program to deliver mail to UUCP. Only DECUS UUCP V1.1 is supported. All of these components are supported by a file queueing system consisting of access routines (implemented as a shareable image), a queue directory (where queued files are kept) and an RMS indexed file (for tracking the queue entries). Utilities are provided for displaying queue entries and maintaining the queue. __________________________________________________________________ 1.2 Configuring the Software Configuring an E-mail system can be complicated. MX provides a command procedure, MXCONFIG.COM, that simplifies the configuration for most Internet and/or BITNET-connected systems. Based on a question-and- answer script, MXCONFIG creates a command file that will generate an MX configuration database. The system manager can tailor that configuration using the MX Control Program (MCP), or, if desired, can bypass MXCONFIG altogether and use MCP directly to create a configuration. MCP commands are described in detail at the back of this manual. __________________________________________________________________ 1.3 Automatic Operation The entire system, once properly configured, is designed to be as free from manual intervention as possible. All problem messages are returned to sender automatically. Mailing list problems that cannot be handled automatically can be directed to the person in charge of the mailing list, reducing the need for system manager intervention. 1-2 General Operation __________________________________________________________________ 1.4 VAXcluster Environments Both homogeneous and heterogeneous VAXclusters are supported. As long as the user authorization file and VMS MAIL profile is shared between nodes, those nodes can be considered "homogeneous" for the purposes of mail delivery. Some heterogeneous VAXclusters have homogeneous "sub-clusters" that share user bases. In a homogeneous cluster or sub-cluster, the agent processes can be run on different nodes to distribute the processing load. Only one MX installation per homogeneous cluster or sub-cluster is required. __________________________________________________________________ 1.5 Problem Reports and Support There is no formal support for MX. If you have E- mail capability, however, you can send your questions and comments to the MX user's mailing list at MX- List@vms.ecs.rpi.edu. If you wish to subscribe to the list, send a one-line message to MX-List- Request@vms.ecs.rpi.edu. The one line should contain the word SUBSCRIBE. If you do not have E-mail capability, you can contact the author directly: Matthew Madison Engineering Computing Services Rensselaer Polytechnic Institute Troy, New York 12180-3590 USA If you have an account on the DECUServe VAX Notes system, you can send mail to MADISON. 1-3 _______________________________________________________ 2 The Router Module All messages that pass through MX are processed by the Router module. The Router, which runs as a detached process, is responsible for directing incoming messages to the appropriate outgoing delivery agents. Routing is broken down into three phases: address rewriting, address/path mapping, and alias translation. __________________________________________________________________ 2.1 Envelope Addresses An electronic mail message is divided into three basic parts. The envelope, much like a real letter, consists of a return address and one or more destination addresses. MX uses RFC 821 (SMTP) addresses on all its envelopes, and converts them to and from other formats when necessary. The headers contain additional information about the message, such as when it was sent, the full list of recipients, etc. MX uses RFC 822 headers in all messages, and converts them when needed. The body of a message is the generally main item of interest to the user, since it contains the text of the message itself. The Router uses only envelope information when it processes messages. The return address is used when an error occurs in routing a message. The destination addresses are translated and analyzed to determine whether the message should be delivered locally or via SMTP or Jnet. 2-1 The Router Module __________________________________________________________________ 2.2 Address Rewriting Address rewriting is the first phase of message routing. Every message's destination addresses are matched against a list of rewrite rules, which consist of a pattern and a result. If an address matches the pattern, the rule is applied and the address rewritten per the rule's result. The purpose of this is to permit host or domain names that are not known to the delivery agents to be used and reformatted to known addresses automatically, hiding the use of gateways or other intermediary systems. For example, if you would like users to be able to address CSNET users as "user@host.CSNET", which is not a genuine Internet domain, you could define a rewrite rule to convert the fake CSNET domain into the appropriate gateway-routed address: MCP>DEFINE REWRITE_RULE "<{u}@{h}.CSNET>" - _MCP> "<@relay.cs.net:{u}@{h}.CSNET>" The "{u}" and "{h}" are called substitution strings. In the pattern part of a rewrite rule, a substitution string matches a string zero or more characters and assigns that string the name specified in the braces. That named string can then be used anywhere in the result part of the rule, and the characters matched will be substituted in the rewritten address. Thus, if the address "<"Mary Smith"@bogus.CSNET>" were to be rewritten using the above rule, substitution string u would match the string ""Mary Smith"" and substitution string h would match the string "bogus", and the address would be rewritten as "<@relay.cs.net:"Mary Smith"@bogus.CSNET>". This rewriting technique is fairly primitive, but should be effective enough for handling a small number of alias hosts or domains. Be careful, though, since the rule processor treats the addresses as ordinary text strings and does not understand the syntax of RFC 2-2 The Router Module 821 addresses. Because they were designed mainly for handling domain aliases, rewrite patterns are matched from right to left. The rewrite rule list is searched only once per address, until a matching pattern is found. Once a match is found, no additional rules are searched. If no rule matches an address, further processing continues on the original address. __________________________________________________________________ 2.3 Domain/Path Mapping After rewriting, the next Router phase is the identification of a delivery path. This phase is divided into two steps. The first step identifies the "next hop" the message should take. The next hop is determined by looking at the address and selecting either the first domain in the route path at the beginning of the address, or if there is no route path, the destination domain. The second step is to search the list of defined domain/path mappings to determine the delivery path. The MCP DEFINE PATH command is used to create a domain/path mapping. A mapping consists of a domain pattern (possibly containing VMS wildcard characters) and the name of the delivery path to be used if the next hop matches the domain pattern. Possible paths are SMTP, JNET, UUCP, and LOCAL. For example, a typical path list for an Internet host might be created with the commands: MCP>DEFINE PATH myhost.mycompany.ORG LOCAL MCP>DEFINE PATH myhost LOCAL ! abbreviation MCP>DEFINE PATH [1.2.3.4] LOCAL ! numeric address MCP>DEFINE PATH * SMTP 2-3 The Router Module The path list is searched sequentially until a match is made. The first three rules catch any locally-addressed messages, and the last rule, which would match any domain name not matching the first two rules, routes all other messages off-system via SMTP. Notice that abbreviations or nicknames for the local host must have LOCAL path definitions to be recognized by MX. By combining appropriate rewrite rules and domain/path mappings, a suitably configured system can route any Internet or BITNET-addressed message transparently, regardless of actual Internet or BITNET connectivity. The MXCONFIG command procedure automatically generates appropriate rules and path definitions to perform this transparent routing. __________________________________________________________________ 2.4 Alias Translation The third phase of Router address processing is the identification and translation of local aliases. The system manager or postmaster can define aliases on the local system that translate to any local or remote address with the MCP DEFINE ALIAS command. If an address, after passing through the first two Router phases, is identified as a local address, the Router searches the alias list. If the local part of the original address matches one of the aliases, the original address is discarded and the alias address is substituted in its place and is passed through the other address processing phases. Note that alias processing is totally transparent to the sender as well as the recipient of a message. No message headers are changed or added to indicate that the message is being forwarded via an alias address. In addition, aliases are kept in a simple list that is searched sequentially, rather than a more efficient structure. For these two reasons, it is recommended 2-4 The Router Module that aliases be used sparingly. Mail forwarding is better done with the VMS MAIL SET FORWARD command. Also performed during this phase is "percent-dehacking" of addresses. MX supports the "percent-sign hack" that allows users to route messages through the local system by specifying an address of the form "user%host1@host2". If the local part of the address is found to contain a percent sign, the percent sign is converted to an at sign, the original address is discarded, and the new address is substituted as for aliases. While this form of routed addressing is not recommended, it is sometimes required when the local host is acting as a gateway between two networks. __________________________________________________________________ 2.5 Other Router Functions In addition to its routing responsibilities, the Router also maintains the file queue used by all the MX agents. The queue itself is a directory containing RMS indexed file which contains the basic queueing information for each entry. For each entry, one or more files are stored in the queue directory, with names based on the queue entry number. Additional information on the use and structure of the file queue is presented in Chapter 7. The Router is responsible for deleting queue entries that have been processed or cancelled or have expired, cleaning out bad entries, and periodically reclaiming bucket space within the indexed file. All of these functions involve periodic queue processing passes. The amount of time between these passes can be controlled by defining logical names in the system logical name table. The logical names, default values, and functions are described in Table 2-1. The default values have been chosen to allow for reasonable queue access on a moderately busy system. 2-5 The Router Module Table_2-1__Router_file_queue-related_logicals__________ Default Logical_____________value____Description_______________ FLQ_CHECK_WAIT 10 min. Amount of time between checks for other queue-related events FLQ_PURGE_WAIT 15 min. Amount of time a queue entry should remain in queue after it has been processed FLQ_FULL_PURGE_WAIT 1 day Amount of time an in-progress entry may remain in progress and unmodified before it is deleted FLQ_RECLAIM_WAIT 1 day Amount of time between indexed file reclaim _____________________________passes____________________ 2-6 _______________________________________________________ 3 Local Processing Modules This chapter describes the MX Local delivery agent, including the mailing list processor and file server, and the MX/VMS MAIL interface module. __________________________________________________________________ 3.1 The Local Delivery Agent The Local delivery agent, a detached process, handles all messages determined to be local by the Router. The envelope created by the Router for a locally-delivered message is read by the agent. Each address is then identified as a straight local delivery, a DECnet delivery, a forwarded message, a mailing list posting or control message, or a file service request, based on the local address. Local deliveries and DECnet deliveries are handled by a subprocess which uses VMS MAIL to deliver the message. DECnet deliveries are periodically retried if they fail due to network link errors (up to 48 tries over a two day period). All other deliveries are handled directly by modules within the Local agent. __________________________________________________________________ 3.2 Message Forwarding The Local agent uses the callable MAIL interface to obtain forwarding information about local users. If a forwarding address is set for a local user, the Local agent creates a new message, adding "Resent" headers to the original headers, and queues it for processing by the Router. 3-1 Local Processing Modules Before queueing the message, however, the headers in the message are scanned, and if "Resent" headers are already present and the message is identified as having already been forwarded from the same address, it is considered a forwarding loop and the message is returned to sender. __________________________________________________________________ 3.3 Mailing Lists The MCP DEFINE LIST command is used to create a mailing list. The mailing list processor supports the automatic archiving of mailing list messages, automatic subscription processing, and limited remote control of mailing lists. In addition, mailing lists can be protected in a variety of ways to restrict the automatic subscription facility as well as postings to the list. For each mailing list created, three local addresses are used: one for the list itself, a request address (list-name-REQUEST), and a sender address (list-name-SENDER). The mailing list processor accepts subscription requests and other control messages on a list's request address. It uses the sender address as the return address on messages sent to the subscribers of the mailing list, so error messages and bounced mail can be returned to the list owner or error-handling person. ___________________________ 3.3.1 General-User Requests There are three general-user control request commands: SUBSCRIBE, SIGNOFF, and REVIEW. Users may send the commands to a mailing list's request address, or, for BITNET compatibility, to the username LISTSERV. If sent to LISTSERV, the request must also inclue the list name. Any message sent to a mailing list's request address that isn't recognized as one of these 3-2 Local Processing Modules commands (and isn't a control message from the list owner) is forwarded to the list owner. SUBSCRIBE requests are handled automatically only if the WORLD protection class is granted E (Enroll) access to the list. Otherwise, they are forwarded to the list owners for manual handling. SIGNOFF requests are handled automatically only if the GROUP protection class is granted D (Delete) access to the list. Otherwise, they are forwarded to the list owners for manual handling. REVIEW requests are handled automatically only if the requesting user is granted R (Read) access to the list. Read access may be granted only to GROUP (i.e., the subscribers of the list) or to GROUP and WORLD. If access is denied, the request is returned with an error message. ___________________________ 3.3.2 Control Messages The mailing list processor currently supports two control requests: ADD and REMOVE. They may be used by the owners of a mailing list to add and remove other users to and from the list of subscribers. Control messages are only accepted on a mailing lists request address, and are not handled by the LISTSERV compatibility code. __________________________________________________________________ 3.4 File Service The MX Local agent includes a file server which can be enabled with the MCP DEFINE FILE_SERVICE command. The file server can automatically service requests for single files or groups of files. Large files can be delayed to non-prime-time hours. 3-3 Local Processing Modules ___________________________ 3.4.1 Packages The file server is designed to handle groups of files, called packages. When you create a package, you create a directory with the name of that package, and all files in that directory must have file names the same as the package name. In addition, you must place a description file above the package directory which is sent when a user requests a listing of available packages. This structure works best when you use a program such as VMS_SHARE to put together your packages. VMS_SHARE is readily available around the Internet and BITNET. It is used to collect together text files, format them so as to improve the chances of their being transferable through most mail systems, and split them up into easily mailable chunks. When all the chunks are put together on the receiving end, they form a DCL command procedure that re-creates the original files. Example To demonstrate the structure used by the file server, let us suppose you have created a package called STUFF. You used VMS_SHARE to create the package, which split the package into three parts. First, you would create a directory for the package: $CREATE/DIRECTORY MX_FILESERV_ROOT:[STUFF] Next, you would copy the VMS_SHARE files into that directory. They must have file names the same as the package name: $COPY STUFF.* MX_FILESERV_ROOT:[STUFF] Finally, you would create a file containing a brief description of the package and place it above the STUFF directory: $EDIT MX_FILESERV_ROOT:[000000]STUFF.DESCRIPTION 3-4 Local Processing Modules The file server will now automatically handle distribution of the STUFF package. ___________________________ 3.4.2 Help File The file FILESERV_HELP.TXT, provided by the installation procedure in directory MX_ROOT:[FILESERV], contains a description of the file service commands. You should update this file to include the address you have chosen for your file server and any other site-specific information you may wish to include. ___________________________ 3.4.3 File Server Commands The three commands accepted by the file server are SENDME, LIST (or DIRECTORY), and HELP. Each may be abbreviated to the smallest unique string. One command is allowed per line of text in a request message, but several command lines may be sent in one request. SENDME takes either a package name (to have all parts of a package sent) or a file name (to have just one part sent). Large files are delayed until non-prime-time hours if enabled when file service is set up. LIST takes a pattern which is used to match against package names. The description file for each matching package is added to a message that is returned to the requesting user. If no pattern is specified, "*" is used. HELP causes the file FILESERV_HELP.TXT to be sent to the requesting user. 3-5 Local Processing Modules __________________________________________________________________ 3.5 VMS MAIL Interface Users on the local system send and receive mail through MX via the VMS MAIL foreign protocol interface. The transport name that should be used with MX is MX%, so when a user addresses a message to be sent via MX it should be specified as: To:MX%"user@domain" The quotation marks are absolutely necessary if the address contains an at-sign. If the "@domain" part is omitted, the logical name MX_VMSMAIL_NODE is translated and appended to the specified username. If multiple addresses are specified, each address requires a separate "MX%" (and quotation marks). Users can have their local mail forwarded through MX with the VMS SET FORWARD command: MAIL>SET FORWARD MX%"""user@domain""" Note that in this case, three pairs of quotation marks are required. ___________________________ 3.5.1 Signature Files The MX/VMS MAIL interface module contains code that permits the easy, semi-automatic addition of a signature file in a message. The user must define the logical name MX_SIGNATURE to point to the file containing the user's signature. The user can then include the line "/SIGNATURE" in the mail message, and MX will include the signature file in the message at that point. The slash mark must be in column one. The word SIGNATURE may be in any case and may be abbreviated to just SIG. 3-6 Local Processing Modules If a message is being sent to local users (without going through MX) as well as via MX, only the copy of the message that passes through MX will include the signature. 3-7 _______________________________________________________ 4 SMTP Support MX supports SMTP over TCP/IP when used with CMU-Tek TCP/IP or VMS/ULTRIX Connection. __________________________________________________________________ 4.1 Delivery Agent The SMTP delivery agent runs as a detached process. TCP/IP must be started before MX, or the process will not start properly. ___________________________ 4.1.1 Mail Exchange Support The CMU-Tektronix TCP/IP software includes a domain name resolver. In version 6.4 of the software, the resolver provides access only to host name-to-address mapping information; however, not all Internet domain names map directly to addresses. Domain names are also used to identify hosts on other networks to which electronic mail can be sent via some other Internet-connected gateway host, called a mail exchange. To interface properly with these hosts, The MX SMTP delivery agent maintains its own database of mail exchange mappings. The system-wide logical name MX_NAMESERVERS is used to determine which domain servers to ask for MX records. You may need to change the definition of this logical name in SYS$STARTUP:MX_STARTUP.COM. 4-1 SMTP Support The name resolver in version 6.5 of the CMU-Tektronix software provides full access to all domain service information, and the MX SMTP delivery agent obtains its mail exchange information from there instead of maintaining its own database. The current version of VMS/ULTRIX Connection does not provide a domain name resolver. MX does not support the use of mail exchanges when used with VMS/ULTRIX Connection. ___________________________ 4.1.2 Default SMTP Router For systems running the VMS/ULTRIX Connection software, or running the CMU-Tektronix software without name resolver support, Internet domain service information is not available. To be able to address messages to hosts that are not in the local system's host tables, you can establish a default router. The SMTP delivery agent will automatically forward to the default router all messages addressed to users on hosts unknown to the local system. A default router is established by defining the logical name MX_SMTP_DEFAULT_ROUTER before starting MX: $DEFINE/SYSTEM/EXEC MX_SMTP_DEFAULT_ROUTER "hostname" Before you use a default router, you should ensure that: o The host name for the system you are using as a default router is known to your system's TCP/IP (i.e., is in your system's host tables). o The default router you select "knows" about the Internet than your host, or in turn can forward to another host that has access to more domain name information. 4-2 SMTP Support o You have the consent of the people managing the system you intend to use as a default router. This is especially important if you expect the traffic between your system and the default router to be heavy. ___________________________ 4.1.3 Retries For most types of unsuccessful delivery attempts (all but unknown host name), the SMTP delivery agent will schedule a retry for 30 minutes after the unsuccessful attempt. After 48 retries (about two days' worth), MX will return the message to sender indicating that delivery was unsuccessful. __________________________________________________________________ 4.2 Server Module The SMTP server is a detached process that must be running for messages coming in via SMTP to be entered into MX. The server listens for incoming SMTP connections by opening a "listener" channel (for VMS/ULTRIX Connection) or keeping a passively-opened channel on the SMTP port (for CMU-Tek TCP). Whenever an SMTP connection comes in, the server immediately opens another channel. Up to four simultaneous SMTP connections can be maintained, by default. To expand or restrict the number of simultaneous connections, define the following logical name before starting MX on your system: $DEFINE/SYSTEM/EXEC MX_SMTP_SERVER_THREADS n The value of n should range from 1 to 16. The SMTP server may require larger process quotas/limits if more than four threads are allowed. 4-3 _______________________________________________________ 5 Jnet Interface MX supports functionality similar to the Columbia Mailer package for VM systems when used with Jnet to transfer messages on an RSCS network such as BITNET. __________________________________________________________________ 5.1 The Mail/File Dispatcher MX traps incoming mail and transfers it from Jnet to its own file queue by providing a Jnet mail/file dispatcher. The Message Exchange Installation Guide describes how to hook this dispatcher into Jnet. The dispatcher should recognize mail using the standard BITNET conventions (class M, file type NOTE or MAIL, etc.), and will pass them onto the MX/Jnet interface module for input processing. __________________________________________________________________ 5.2 MX/Jnet Interface Module The MX/Jnet interface module runs as a detached process with a permanent subprocess used for sending files out over Jnet. For incoming messages, it will convert CMS NOTEs and PROFS notes into mostly-RFC 822-compliant messages. Also supported is BSMTP for both incoming and outgoing mail to BITNET nodes with registered mailers. 5-1 Jnet Interface ___________________________ 5.2.1 XMAILER.NAMES In order to communicate with other mailers on BITNET, you must register the username you are using to run the MX software as your node's mailer. You should not run the MX software under the SYSTEM username if you plan on registering a mailer, since the SYSTEM username has special meaning to RSCS. You must also obtain an XMAILER.NAMES file for your RSCS network and place it in the directory MX_ROOT:[JNET]. For BITNET hosts, you should be able to obtain this file from the same place you get your monthly JANROUTES updates. MX will only recognize those nodes listed in the XMAILER.NAMES file. It will properly identify registered mailers on other nodes from this file and will send mail via BSMTP if possible. Otherwise, messages will be sent as plain mail directly to each destination user. If you cannot obtain an XMAILER.NAMES file for your RSCS network, you can create one for your own use. You need one line in the file for each node in your network. Each line in the file must be of the form: :nick.HOSTNAME :alias.ALIAS :net. :mailer. :netsoft. where "HOSTNAME" is the name of the host, "ALIAS" is either the host name repeated or an alias for the host name, ":net." is followed by the name of the network the node resides on (optional for use with MX), ":mailer." is followed either by a blank (indicating no mailer) or by a mailer username designation, and ":netsoft." is followed by the name of the RSCS software in use on the node (optional for MX use). You should only specify a mailer username for other nodes running MX or running some other mailer package that can handle BSMTP. Be sure that the other mailers on your network are also aware of your system's mailer username in order to take full advantage of BSMTP message transfers. Until your mailer username is 5-2 Jnet Interface registered, you should omit any reference to mailers in your XMAILER.NAMES file. 5-3 _______________________________________________________ 6 UUCP Support MX supports UUCP message transfers by interfacing with DECUS UUCP. Note: UUCP support has not been thoroughly tested. Use at your own risk. __________________________________________________________________ 6.1 RMAIL Program The MX RMAIL program is used in the UUCP UUXQT_DCL command procedure to intercept incoming UUCP messages and divert them to MX. The RMAIL program converts all UUCP "bang"-style addresses into RFC 822 route addresses and queues the message for processing by the Router. The address conversion routines leave domain names untouched and converts straight UUCP names into domain names by appending ".UUCP". A UUCP address with multiple node names is converted into a routing address for envelope purposes and a percent-hacked address in the message headers. For example, the address nodea!nodeb!nodec.domain.name!noded!user would be converted into <@nodea.UUCP,@nodeb.UUCP,@nodec.domain.name:user@noded.UUCP> when in the envelope, and user%noded.UUCP%nodec.domain.name%nodeb.UUCP@nodea.UUCP when in the message headers. 6-1 UUCP Support __________________________________________________________________ 6.2 UUCP Delivery Agent The UUCP delivery agent performs address conversion on the envelope and headers that is the inverse of RMAIL's. All addresses are converted into UUCP "bang" syntax. The message is then rewritten into a form suitable for use by the UUCP_MAILSHR mail interface supplied with DECUS UUCP and it is sent by spawning a subprocess that performs a MAIL/PROTOCOL=UUCP_MAILSHR to deliver the message. Note that none of the MX UUCP programs do any form of UUCP route interpretation. The DECUS UUCP mailer should continue to be used for that purpose, even after MX is installed. 6-2 _______________________________________________________ 7 File Queue Management This chapter describes the MAILQUEUE and FLQU utilities, which are used to examine and manage the file queue used by MX. The file queue itself is implemented as a combination of a directory containing the queued files, an ISAM file containing information about queue entries, and a shareable image containing queue access routines. All queue manipulations are performed by calling the queue access routines, and all access is coordinated by using standard RMS record locking. The queue access routines contain a notification mechanism that uses the VMS lock manager for notifying processing agents when queue entries are ready to be processed, to allow for distributed processing of queue entries with relatively short turn-around time. The file queueing software, besides being used for queueing mail files, can also be used as for general-purpose inter-user file transfer, or for any specific application requiring this sort of file queueing. However, until a future version of MX is released with improved queueing software, general access to the file queue will not be supported. __________________________________________________________________ 7.1 MAILQUEUE MAILQUEUE is a program that scans the file queue for delayed entries. Delayed entries are used by the local delivery agent (when delivering via DECnet) and the SMTP delivery agent when scheduling retires after unsuccessful delivery attempts. Delayed entries are also used by the file server to schedule delivery of large files during non-prime-time hours. 7-1 File Queue Management MAILQUEUE, when installed with SYSPRV privilege, can be used by non-privileged users to view only those delayed entries which were sent by them. When used from an account with SYSPRV privilege turned on, MAILQUEUE lists all delayed queue entries. MAILQUEUE resides in the MX_EXE: directory and is designed to be executed as a DCL foreign command: $MAILQ*UEUE :== $MX_EXE:MAILQUEUE $MAILQ Currently, only the SMTP and LOCAL delivery agents implement retries, which use the delay facility of the queueing software. In addition, the file server can be configured to delay large messages sent during prime time. If there are no delayed messages, MAILQUEUE returns the message %MAILQ-W-NOMATCH, No entries matched specification Otherwise, the MAILQUEUE display will resemble the following: Entry Agent From Next try 1678 SMTP username@myhost.mycompany.ORG 1-APR-1990 12:02 Delivering to: __________________________________________________________________ 7.2 FLQU FLQU (File Queue Utility) is a general-purpose utility for queue management to be used by privileged users. To use the SHOW command, a user must have at least SYSPRV privilege. To use the PURGE or READY command, SYSPRV and possibly SYSLCK and/or WORLD are required. 7-2 File Queue Management FLQU is also designed to be executed as a foreign command: $FLQU :== $MX_EXE:FLQU $FLQU SHOW FLQU is a subsystem, however, and takes commands. If you specify a command on the command line, that command is executed and control is returned to DCL. If you omit a command, FLQU prompts for commands until you exit back to DCL. A brief description of FLQU commands is given in Table 7-1. The entire file queueing system will be rewritten for a future version of MX, and will include a new queue management utility which will be fully documented. Table_7-1__FLQU_commands_______________________________ Command_______________Description______________________ SHOW Lists all the entries in the queue. SHOW/FULL entry-num Lists in more detail the specified entry. CANCEL Cancels the specified entry or entry-num[,...] entries. READY Readies the specified entry or entry-num[,...] entires, including clearing the DELAY flag. PURGE Deletes all completed and cancelled entries from the ______________________queue.___________________________ 7-3 File Queue Management ___________________________ 7.2.1 Interpreting FLQU SHOW Output When there are messages in the queue, FLQU SHOW displays the following information about each entry: Entry Clas Sts Size Origin Destination Dest Proc ----- ---- --- ------ -------------------- -------------------- --------------- 1661 MAIL FIN 1049 MYNODE::username@myn ECS:: MX_ROUTER 1662 MAIL FIN 1049 MYNODE::username@myn ECS:: MX_SMTP The fields of the display contain the following information: o The Entry field is the queue entry number, which can range from 1 to 32767. o The Class field indicates the type of entry, and should always say MAIL. o The Sts, or status, field can be one of INP, RDY, FIN, or CAN. o INP stands for "in progress" and is used when the entry is being processed by an agent. It is also used on entries already processed by the Router awaiting delivery by one of the other processing agents. o RDY stands for "ready" and is used when then entry is ready for processing by an agent. RDY status is also used when an entry is ready, but delayed for later processing. FLQU SHOW/FULL can be used to display the delay-until time. o FIN stands for "finished" and is used when processing of the entry has completed. Finished entries remain in the queue for a short time before being removed (see Table 2-1). o CAN stands for "cancelled" and is used when processing of the entry is terminated before completion, such as when CTRL/C is pressed during entry of a message in VMS MAIL. Cancelled 7-4 File Queue Management entries also remain in the queue for a short time before removal. o The Size field displays the size of the message. The size is calculated as the total number of bytes in the body of the message multiplied by the number of intended recipients of the message. Headers are not counted when computing the size of the message. o The Origin field, provided for informational purposes only, displays the envelope return address of the message, preceded by the local FLQ node name. For messages coming in from Jnet, this field displays the RSCS source user/host tag. o The Destination field is not used by MX, except for messages coming from Jnet, for which the field indicates the RSCS destination user and host. o The Dest Proc, or destination processor, field indicates the name of the processing agent that will process the entry. This can be MX_ROUTER, MX_JNET, MX_SMTP, MX_UUCP, or MX_LOCAL. 7-5 _______________________________________________________ 8 Troubleshooting MX This chapter contains information on MX useful for debugging MX components. __________________________________________________________________ 8.1 Queue Files Used by MX Components As has already been discussed, each MX component uses files in the file queue when processing messages. Each queue entry has at least one file associated with it, usually containing envelope information. The files created by MX are called FLQ_DIR:n.type, where n is the queue entry number and type is a file type indicating the type of information is in the file. All queued files used by MX, except for the one containing the message body, contain records written in tag-length-value (TLV) format. The tag and length fields are written in binary format, though the value is generally plain ASCII. While more efficient for MX, this storage format makes it more difficult to display the contents of these files, since the binary headers tend to confuse terminals. When examining these files, it is usually best to use DUMP or a text editor, rather than using TYPE. ___________________________ 8.1.1 File Types The following list describes the file types used for queue files, the agents that write them, and the agents that read them. 8-1 Troubleshooting MX SRC_INFO. This is the envelope information written on message entry. The first record in the file is the original source address, the second is the source address converted into RFC822 format, and subsequent records are recipient addresses. Written by: MX_MAILSHR, SMTP_SERVER, MX_JNET (incoming), MX_RMAIL. Read by: MX_ROUTER. HDR_INFO. This file contains the message headers, in TLV format. The headers are only used during address conversion when gatewaying mail into UUCP or Jnet, or for making return-address determinations on local delivery of mail. Written on message entry by: MX_MAILSHR, SMTP_SERVER, MX_JNET (incoming), MX_RMAIL. Read by: MX_LOCAL, MX_JNET (outgoing), MX_SMTP, MX_UUCP. MSG_TEXT. This file contains the text of the body of the message, in plain ASCII. Written on message entry by: MX_MAILSHR, SMTP_SERVER, MX_JNET (incoming), MX_RMAIL. Read on message delivery by: MX_LOCAL, MX_JNET (outgoing), MX_SMTP, MX_UUCP. JNET_INFO, LOCAL_INFO, SMTP_INFO, UUCP_INFO. These files contain envelope information used by the delivery agents. Written by: MX_ROUTER. Read by: MX_JNET, MX_LOCAL, MX_SMTP, MX_UUCP (respectively). JNET_INPUT. This file is used by the Jnet interface for holding the original message as it comes in from Jnet until it can be processed by MX_JNET. Written by: MX_MFSDISP. Read by: MX_JNET (incoming). Note that the SRC_INFO, HDR_INFO, and MSG_TEXT files remain attached to the original queue entry. When the queue entries for the delivery agents are created, a back link to the original queue entry is entered so the delivery agents can gain access to the headers and message text. In addition, forward links to the delivery agent entries are kept in the original queue entry, which are zeroed out as each delivery agent finishes its processing. When all forward links 8-2 Troubleshooting MX are zeroed, the original queue entry is changed to FINished status. __________________________________________________________________ 8.2 Process Names The MX_START.COM command procedure assigns a specific process name to each of the MX detached processes. To determine whether an agent is running or not, examine the SHOW SYSTEM output for the following process names: MX Router The Router MX SMTP SMTP delivery agent SMTP Server SMTP server MX Local Local delivery agent MX->VMS Mail Subprocess created by Local delivery agent MX Jnet Intfc Jnet interface (delivery agent and incoming message processor) MX->Jnet Subprocess created by Jnet interface MX uucp Intfc UUCP interface MX->uucp Subprocess created by UUCP interface Note that the subprocesses are not created until at least one message is processed by the corresponding delivery agent. 8-3 Troubleshooting MX __________________________________________________________________ 8.3 Debug/Trace Output Each of the delivery agents has debug/trace code that can be enabled to provide information on message processing. Tracing is enabled by defining a system-wide logical name, and disabled by deassigning that logical. Debugging can be enabled or disabled "on the fly": the process being debugged will automatically start logging trace information for each entry processed after the logical name is defined. The trace log file, by default, is created in the same directory used for the agent's main log file, with a filetype of .LOG. Trace output can be redirected by defining a system-wide logical name. The logical names used for debugging are outlined in Table 8-1. There is no debugging code available in MX_MAILSHR (the VMS MAIL interface), MX_MFSDISP (the Jnet file dispatcher), or MX_RMAIL (the UUCP RMAIL program). Table_8-1__Debug/Trace_logical_names___________________ Agent_______Enabling_logical______Trace_file___________ Default directory Router MX_ROUTER_DEBUG MX_ROUTER_LOG MX_ROUTER_DIR: Local MX_LOCAL_DEBUG MX_LOCAL_LOG MX_LOCAL_DIR: SMTP out MX_SMTP_DEBUG MX_SMTP_LOG MX_SMTP_DIR: SMTP SMTP_SERVER_DEBUG SMTP_SERVER_LOG MX_SMTP_DIR: server Jnet MX_JNET_DEBUG MX_JNET_LOG MX_JNET_DIR: intfc UUCP MX_UUCP_DEBUG MX_UUCP_LOG MX_UUCP_DIR: intfc__________________________________________________ 8-4 _______________________________________________________ MCP Command Dictionary MCP Commands MCP _______________________________________________________ MCP Executes the MX Control Program. _______________________________________________________ FORMAT MCP [command] _______________________________________________________ Command Qualifiers Defaults /FILE=file-spec _______________________________________________________ PARAMETERS [command] Any MCP command except the input redirection operator (@). The specified command is executed and control is returned to DCL immediately thereafter. _______________________________________________________ DESCRIPTION MCP was written to be used as a DCL "foreign" command. To use it as a foreign command, you must define a symbol as follows: $MCP :== $MX_EXE:MCP Defining the symbol in this way allows you to use the /FILE qualifier and specify "one-shot" commands on the command line. MCP-3 MCP Commands MCP _______________________________________________________ QUALIFIERS /FILE=file-spec Loads the specified MX configuration file for editing. If not specified, no configuration information is loaded. The default file type is MXCFG. MCP-4 MCP Commands @ (RedirectCommand Input) _______________________________________________________ @ (Redirect Command Input) Executes MCP commands read from a file. _______________________________________________________ FORMAT @ file-spec _______________________________________________________ PARAMETERS file-spec Name of the file containing MCP commands. If omitted, the default file type is MCP. _______________________________________________________ DESCRIPTION Use this command to have MCP take further command input from the specified file. There is no built-in limit on the number of levels of nesting of command files, so be careful when using input redirection from within a command file. This command can only be used at the MCP command prompt, not as a "one-shot" MCP command. To have a file be used for input for an entire MCP session, use the following sequence of DCL commands. $DEFINE/USER SYS$INPUT file-spec $MCP MCP-5 MCP Commands DEFINE ALIAS _______________________________________________________ DEFINE ALIAS Defines a local alias for transparent mail forwarding. _______________________________________________________ FORMAT DEFINE ALIAS local-name fwd-address _______________________________________________________ PARAMETERS local-name A string up to 32 characters in length. Any E-mail addressed to this name on the local host will be sent to the fowarding address. fwd-address A valid E-mail address, which will be substituted for the matching local alias address. _______________________________________________________ DESCRIPTION An alias can be used to cause mail messages to be forwarded automatically to another address. Unlike forwarding using the SET FORWARD command in VMS Mail, no "Resent" headers are added to the message. In addition, alias-based forwarding is performed by the MX routing agent rather than the local delivery agent, thus affording a small savings in message queue space and processing time. Due to the lack of notification, however, it is recommended that aliases be used sparingly. MCP-6 MCP Commands DEFINE FILE_SERVICE _______________________________________________________ DEFINE FILE_SERVICE Establishes an MX file server. _______________________________________________________ FORMAT DEFINE FILE_SERVICE _______________________________________________________ Command Qualifiers Defaults /BEGIN_SEND_PERIOD=hh:mm /[NO]DELAY_THRESHOLD=size /END_SEND_PERIOD=hh:mm /MANAGER=address /USER=name _______________________________________________________ DESCRIPTION This command is used to establish or remove an MX mail-based file server on the local system. The server can be set up to distribute groups of files called "packages" using E-mail as the distribution medium. The file server responds to commands placed, one per line, in the text of a mail message sent to the file server username. The commands the file server responds to are HELP, LIST, and SENDME. The logical name MX_FILESERV_ROOT is a rooted-directory name that the file server software uses to locate packages. Each package must have a directory at MX_FILESERV_ROOT:[package-name] where all its files are kept. In addition, the file name of each of the files in the package must also match the package name. Each package must also have a file called MX_FILESERV_ROOT:[000000]package-name.DESCRIPTION that MCP-7 MCP Commands DEFINE FILE_SERVICE contains a description of the package and the files in the package. The SENDME command takes one argument, the name of a package or an individual file. If a package name is specified, all files in the package directory are sent to the requesting user. Otherwise, just the specified file is sent. The LIST command can take a wildcard pattern as an argument (if omitted, it defaults to "*"). The contents of the description files of all packages whose names match the wildcard pattern are placed in a file and sent to the requesting user. The HELP command causes the file server to send the file MX_FILESERV_ROOT:[000000]FILESERV_HELP.TXT to the requesting user. A sample help file is provided with MX, which the system manager can modify to provide site-specific information. _______________________________________________________ QUALIFIERS /BEGIN_SEND_PERIOD=hh:mm Identifies the time of day when the file server can begin sending files that exceed the delay threshold size. /[NO]DELAY_THRESHOLD=size Use /DELAY_THRESHOLD to establish the maximum size, in bytes, a file can be to be sent at any time during the day. Files exceeding size are sent only during the sending period established by /BEGIN_SEND_PERIOD and /END_SEND_PERIOD. Use /NODELAY_THRESHOLD to remove size restrictions. /MANAGER=address When establishing a file server, you must provide a valid E-mail address to which all error messages and mail that bounces back to the file server can be forwarded. MCP-8 MCP Commands DEFINE FILE_SERVICE /USER=name The local name to be used for the file server. The name can be up to 32 characters in length. The recommended name is FILESERV. To disable file service, use a null username (/USER=""). MCP-9 MCP Commands DEFINE LIST _______________________________________________________ DEFINE LIST Creates a mailing list. _______________________________________________________ FORMAT DEFINE LIST list-name _______________________________________________________ Command Qualifiers Defaults /[NO]ARCHIVE=fspec /NOARCHIVE /ERRORS_TO=address See text /[NO]MODERATOR=(address/NOMODERATOR /OWNER=(address[,...]) /PROTECTION=prot-spec See text /REPLY_TO=(kwd[,...]) /REPLY_TO=SENDER _______________________________________________________ PARAMETERS list-name Local name to be used for the mailing list, up to 32 characters in length. _______________________________________________________ DESCRIPTION This command is used to establish a mailing list. A list is simply a collection of addresses. When a message is sent to the mailing list address, the mailing list processor forwards a copy of the message to all the addresses on the list. In addition, it can place a copy of the message in a file, called an archive. MCP-10 MCP Commands DEFINE LIST The mailing list processor can also automatically handle subscription requests for mailing lists. Requests addressed to list-name-REQUEST or LISTSERV containing valid subscription commands can be processed without intervention by the list owner, unless so desired. Only one command per request message is accepted, which must be the first line in the body of the message. Valid commands are SUBSCRIBE, SIGNOFF, and REVIEW. Each command can take a list name as an argument, which is only used if the request is addressed to LISTSERV. Each of the registered owners of a mailing list can also send special control messages to the mailing list processor to add addresses to or remove addresses from the mailing list. These messages must be addressed to list-name-REQUEST. The control commands are ADD and REMOVE, and each take one or more addresses, separated by commas, as arguments. The command must be on the first line of the body of the control message. _______________________________________________________ QUALIFIERS /[NO]ARCHIVE=fspec Specify /ARCHIVE to have the mailing list messages placed in an archive file automatically by the mailing list processor. For fspec you must provide at least a device/directory specification. If the file name is omitted, the mailing list name is used as the file name for the archive file. If the file type is omitted, yyyy-mm is used as the file type, where yyyy is the current year and mm is the number of the current month at the time a message is added to the archive. /ERRORS_TO=address This qualifier is used to direct error messages and mail returned to the mailing list processor to the specified address. If not specified, the address of MCP-11 MCP Commands DEFINE LIST the the first specified owner of the mailing list is used. /[NO]MODERATOR=(address[,...]) This qualifier is for future use. Moderated mailing lists are currently not supported. /OWNER=(address[,...]) This qualifier specifies the addresses of one or more owners of the mailing list. Each mailing list must have at least one owner, who is responsible for handling subscription requests not handled automatically by the mailing list processor and problems with or questions about the list. /PROTECTION=prot-spec This qualifier determines the protection of the mailing list. The protection specification, prot-spec, is identical to a VMS file protection specification, and defaults to (S:RWED,O:RWED,G:RWED,W:RWE). The four protection classes are described in Table MCP-1 and the four protection types are described in Table MCP-2. Table_MCP-1__Mailing_list_protection_classes___________ Class_______Description________________________________ SYSTEM any address matching one of the addresses on the system user list (see DEFINE SYSTEM_USERS) OWNER any address matching one of the owner addresses specified on the /OWNER qualifier GROUP any address matching one the addresses on the subscriber list for the mailing list MCP-12 MCP Commands DEFINE LIST Table_MCP-1_(Cont.)__Mailing_list_protection_classes___ Class_______Description________________________________ WORLD_______any_other_address__________________________ Just as with VMS file protections, the SYSTEM and OWNER classes are implicitly granted C (control) access, allowing them to use the ADD and REMOVE commands to add and remove addresses from the mailing list. Table_MCP-2__Mailing_list_protection_codes_____________ Code________Description________________________________ R (Read) allows the use of the REVIEW command W (Write) allows the user to post messages to the list E (Enroll) allows the automatic handling of the SUBSCRIBE command D (Delete) allows the automatic handling of the ____________SIGNOFF_command____________________________ Note that protection code E (enroll) is only meaningful when used with the WORLD class and that protection code D (delete) is only meaningful when used with the GROUP class. Some typical GROUP and WORLD protection specifications are shown in Table MCP-3. In most cases, you would also want to give SYSTEM and OWNER users RWED access. MCP-13 MCP Commands DEFINE LIST Table_MCP-3__Typical_protection_codes__________________ (G:RWED,W:RWE) Public list. Anyone can subscribe, sign off, and review the list, anyone can post to the list. (G:RWED,W:E) Semi-public list. Anyone can subscribe and sign off the list, but only subscribers can review or post to the list. (G:W,W) Private list. Only subscribers can post to the list, and all subscription requests are screened by the owners of the mailing list. (G,W) One-way list. Only the owners can post to the list, and they also _________________screen_all_the_subscription_requests._ Note: Since electronic mail can readily be forged, you should not depend on this protection scheme for absolute security of your mailing lists. The mailing list processor attempts no authentication of addresses when it receives messages. /REPLY_TO=(kwd[,...]) This qualifier is included for future use. In version V1.2 of MX, no modifications are made to message headers by the mailing list processor, so the Reply-To header provided by the sender is preserved. MCP-14 MCP Commands DEFINE PATH _______________________________________________________ DEFINE PATH Defines a mapping between a domain name and a distribution path. _______________________________________________________ FORMAT DEFINE PATH domain-name path-name _______________________________________________________ PARAMETERS domain-name A domain name or pattern containing VMS wildcards. path-name One of the supported MX path names: LOCAL, SMTP, JNET, or UUCP. _______________________________________________________ DESCRIPTION This command is used to associate a domain name and a distribution path. The Router uses this information to determine which distribution path should be used when routing mail messages. Each DEFINE PATH command adds a path definition to the end of the list. The Router searches this list in the order you specify until the domain name of the address it is trying to route to matches the domain name or wildcard pattern of the path definition. This means that you should place more specific path definitions before more general path definitions. MCP-15 MCP Commands DEFINE REWRITE_RULE _______________________________________________________ DEFINE REWRITE_RULE Defines an address-rewriting rule for use by the Router. _______________________________________________________ FORMAT DEFINE REWRITE_RULE pattern result _______________________________________________________ PARAMETERS pattern An RFC 821-compliant address string, possibly with the addition of one or more substitution strings. The address string must include the opening and closing angle brackets. Any address matching pattern will be rewritten by the Router based on the result string. result An RFC 821-compliant address string, possibly with the addition of one or more substitution strings. _______________________________________________________ DESCRIPTION This command is used to provide the Router with rules for transforming some addresses into other forms. The pattern string is an address string that must be matched to have the transormation apply. For example: MCP>DEFINE REWRITE_RULE "<{user}@{host}.CSNET>" - _MCP> "<@relay.cs.net:{user}@{host}.CSNET>" MCP-16 MCP Commands DEFINE REWRITE_RULE The strings "{user}" and "{host}" are called substitution strings. They are identified by the curly braces surrounding the substitution name, which you may specify arbitrarily. In the pattern string, a substitution string matches any number of any characters, like the asterisk in a VMS wildcard pattern. The matched string can be substituted into the rewritten address by specifying the same substitution string in the result string, or it may be omitted. Rewriting rules are useful for creating artificial domains that local users can take advantage of (such as .CSNET or .UUCP), allowing users to abbreviate host names, and automatically handling gateways (such as for BITNET or UUCP). They should be used sparingly, however, since every address must be matched against the rewrite rules list. The rewrite rules list is searched in the order you specify, so you should place more specific rules before more general rules. All pattern matching is done from right to left. MCP-17 MCP Commands DEFINE SYSTEM_USERS _______________________________________________________ DEFINE SYSTEM_USERS Defines the address to be given SYSTEM access to mailing lists. _______________________________________________________ FORMAT DEFINE SYSTEM_USERS address[,...] _______________________________________________________ PARAMETERS address[,...] One or more addresses, separated by commas. Each of the users identified by these addresses will be considered "system" users by the mailing list processor, and granted access via the SYSTEM protection class to all mailing lists. Case is important only in the username portion of the address. To retain the case of the address, surround it with quotation marks. _______________________________________________________ DESCRIPTION This command is used to provide the mailing list processor with a list of privileged users. These users are granted access to mailing lists via the SYSTEM protection class, and are given CONTROL access to all mailing lists as well. Typically only the system manager and/or postmaster for the system should be identified as system users. This will allow them to control a mailing list on the system when the owners of the list cannot be contacted. MCP-18 MCP Commands EXIT _______________________________________________________ EXIT Exits MCP. _______________________________________________________ FORMAT EXIT _______________________________________________________ DESCRIPTION Use this command to leave MCP. If you have modified the MX configuration, it is saved before exiting. If the configuration file has not been named, you are prompted for a file name before exiting. MCP-19 MCP Commands HELP _______________________________________________________ HELP Displays help information. _______________________________________________________ FORMAT HELP [topic...] _______________________________________________________ PARAMETERS topic The name of a topic in the help library. If omitted, a list of topics is displayed. MCP-20 MCP Commands MODIFY _______________________________________________________ MODIFY Modifies existing configuration information. _______________________________________________________ FORMAT { ALIAS alias new-fwdaddr } { FILE_SERVICE } MODIFY { LIST list-name } { PATH domain new-path } { } { REWRITE_RULE pattern new-result } _______________________________________________________ DESCRIPTION This command alters configuration information of the types listed in above. Each of the MODIFY commands takes the same arguments and qualifiers as its corresponding DEFINE command, so refer to the appropriate DEFINE command for further information. MCP-21 MCP Commands QUIT _______________________________________________________ QUIT Leaves MCP without saving any configuration changes. _______________________________________________________ FORMAT QUIT _______________________________________________________ DESCRIPTION Use this command leave MCP without saving any of the changes made to the MX configuration. If the configuration was changed, MCP will ask for confirmation before returning to DCL. MCP-22 MCP Commands REMOVE _______________________________________________________ REMOVE Removes a configuration record. _______________________________________________________ FORMAT { ALIAS alias } { LIST list-name } REMOVE { PATH domain } { } { REWRITE_RULE pattern } _______________________________________________________ DESCRIPTION This command removes one record of the specified type from the MX configuration. The specified alias, list name, domain, or rewrite rule pattern must match exactly the identical field in the record to be removed. MCP-23 MCP Commands SAVE _______________________________________________________ SAVE Saves the current configuration to a file. _______________________________________________________ FORMAT SAVE file-spec _______________________________________________________ PARAMETERS file-spec The name of the file to which the configuration is written. If omitted, the file type defaults to MXCFG. _______________________________________________________ DESCRIPTION Use this command to write the MX configuration you are creating or changing to a file. You should save the configuration to the file MX_DIR:MX_CONFIG.MXCFG if you want it to be used by the MX processing agents. MCP-24 MCP Commands SHOW _______________________________________________________ SHOW Displays all or part of the current MX configuration. _______________________________________________________ FORMAT { ALIASES [pattern] } { CONFIGURATION_FILE } { FILE_SERVICE } { LISTS [pattern] } SHOW { } { PATHS [pattern] } { REWRITE_RULES [pattern] } { SYSTEM_USERS } { } { ALL } _______________________________________________________ Command Qualifiers Defaults /[NO]COMMAND /NOCOMMAND /OUTPUT=file-spec /OUTPUT=SYS$OUTPUT: _______________________________________________________ DESCRIPTION The SHOW command displays the specified parts of the current MX configuration. For aliases, lists, paths, and rewrite rules, if you omit pattern, all records are displayed. _______________________________________________________ QUALIFIERS /[NO]COMMAND The /COMMAND qualifier indicates that the display should be formatted as the commands that would be entered to create the specified records. Use /COMMAND with the /OUTPUT qualifier to create an MCP command MCP-25 MCP Commands SHOW file that can be altered with your favorite editor, then read back into MCP to create a new configuration. /OUTPUT=file-spec The /OUTPUT qualifier is used to direct the SHOW result to a file or other device. By default, the result is displayed on the current output device, SYS$OUTPUT. MCP-26 _________________________________________________________________ Index _______________________________ A File queueing software (Cont.) _______________________________ FLQU, 7-2 Address rewriting, 2-2 logical names, 2-5 Alias, 2-4 MAILQUEUE, 7-1 File queue maintenance, 2-5 _______________________________ File server, 3-3, MCP-7 B commands, 3-5 _______________________________ example, 3-4 BSMTP, 5-2 FLQU, 7-2 _______________________________ _______________________________ C H _______________________________ _______________________________ Configuring MX, 1-2 HDR_INFO file, 8-2 _______________________________ _______________________________ D J _______________________________ _______________________________ Debugging, 8-4 Jnet DECnet mail delivery, 3-1 Mail/file dispatcher, 5-1 Default router, 4-2 Jnet interface, 1-1, 5-1 DEFINE PATH, 2-3 JNET_INFO file, 8-2 DEFINE REWRITE_RULE, 2-2 JNET_INPUT file, 8-2 Domain/path mapping, 2-3, _______________________________ MCP-15 L _______________________________ _______________________________ E Local delivery support, 1-1, _______________________________ 3-1 Envelope, 2-1 LOCAL_INFO file, 8-2 _______________________________ _______________________________ F M _______________________________ _______________________________ File queueing software, 7-1 Mail exchange, 4-1 Mail forwarding, 3-1, 3-6 Index-1 Index _______________________________ Mailing lists, 3-2, MCP-10 Q addresses, 3-2 _______________________________ control commands, 3-3 Queue files, 8-1 subscription handling, 3-2 Queue file types, 8-1 MAILQUEUE, 7-1 Queue status, 7-4 MCP commands @, MCP-5 _______________________________ DEFINE ALIAS, MCP-6 R DEFINE FILE_SERVICE, MCP-7 _______________________________ DEFINE LIST, MCP-10 Rewrite rules, 2-2, MCP-16 DEFINE PATH, 2-3, MCP-15 RMAIL, 6-1 DEFINE REWRITE_RULE, 2-2, Router, 1-1, 2-1 MCP-16 DEFINE SYSTEM_USERS, MCP-18 _______________________________ EXIT, MCP-19 S HELP, MCP-20 _______________________________ MODIFY, MCP-21 Signature files, 3-6 QUIT, MCP-22 SMTP server, 4-3 REMOVE, MCP-23 SMTP support, 1-1, 4-1 SAVE, MCP-24 SMTP_INFO file, 8-2 SHOW, MCP-25 SRC_INFO file, 8-2 Message body, 2-1 Message headers, 2-1 _______________________________ MSG_TEXT file, 8-2 T MX components _______________________________ Jnet interface, 1-1, 5-1 Threads, 4-3 Local, 1-1, 3-1 Trace logs, 8-4 Router, 1-1, 2-1 _______________________________ SMTP, 1-1, 4-1 UUCP interface, 1-2, 6-1 U MXCONFIG.COM, 1-2 _______________________________ MX Control Program, MCP-3 UUCP interface, 1-2, 6-1 UUCP_INFO file, 8-2 _______________________________ UUCP_MAILSHR, 6-2 P _______________________________ _______________________________ Packages, 3-4 V Percent-hack, 2-5 _______________________________ Process names, 8-3 VMS MAIL, 3-1, 3-6 Index-2 Index _______________________________ X _______________________________ XMAILER.NAMES, 5-2 Index-3