 


















          Message Exchange Management Guide



          December 1995



          This manual describes the management and operation
          of Message Exchange, electronic mail software for VMS
          systems.




          Revision/Update Information:  This is a revised manual.
                                        Revision bars indicate
                                        changes made since the
                                        last version of the
                                        software.

          Operating System and Version: VMS V5.0 or later

                                        OpenVMS AXP V1.0 or later

          Software Version:             Message Exchange V4.2

          Matt Madison and Hunter Goatley
          MadGoat Software

 








          ________________________
          11 December 1995

          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 MadGoat Software. The authors and
          MadGoat Software assume 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 authors
          or the authors' employers as to the suitability,
          reliability, security, usefulness, or performance
          of this software.

          MX was originally written by Matthew D. Madison,
          formerly of Rensselaer Polytechnic Institute and
          currently employed by TGV, Inc. The software is
          currently maintained by Hunter Goatley, formerly of
          Western Kentucky University and currently employed by
          The LOKI Group, Inc.

          The following are trademarks of Digital Equipment
          Corporation:

          DEC                DECnet              P.S.I.
          ULTRIX             VAX                 VAXcluster
          VMS                AXP                 VMScluster

          Jnet is a registered trademark of Wingra Technologies,
          Inc.

          MultiNet is a registered trademark of TGV, Inc.

          TCPware is a trademark of Process Software
          Corporation.

          WIN/TCP and Pathway are registered trademarks of The
          Wollongong Group, Inc.

          __________
          Copyright 1995 MadGoat Software. ALL RIGHTS RESERVED.

 









          _______________________________________________________

          Contents

                _________________________________________________
                PREFACE                                        ix

          _______________________________________________________
          CHAPTER 1  OVERVIEW OF MESSAGE EXCHANGE
                     OPERATION                                1-1

                _________________________________________________
                1.1   WHAT IS A MESSAGE?                      1-1

                _________________________________________________
                1.2   WHAT IS AN ADDRESS?                     1-2

                _________________________________________________
                1.3   MX COMPONENTS                           1-3

                1.3.1     The Message Queue  _____________    1-4

                1.3.2     Message Entry Agents  __________    1-5

                1.3.3     The Router  ____________________    1-6

                1.3.4     Delivery Agents  _______________    1-6

                1.3.5     MLF Agent  _____________________    1-7

          _______________________________________________________
          CHAPTER 2  CONFIGURING MX WITH MXCONFIG             2-1

                _________________________________________________
                2.1   WHY USE MXCONFIG?                       2-1

                _________________________________________________
                2.2   USING MXCONFIG                          2-1

                2.2.1     Selecting Delivery Paths  ______    2-2

                _________________________________________________
                2.3   LOCAL NODE NAME INFORMATION             2-2

                                                              iii

 


          Contents





                _________________________________________________
                2.4   ESTABLISHING A POSTMASTER ALIAS         2-3

                _________________________________________________
                2.5   FINISHING THE CONFIGURATION             2-3


          _______________________________________________________
          CHAPTER 3  MANAGING THE ROUTER                      3-1

                _________________________________________________
                3.1   REWRITE RULES                           3-1

                _________________________________________________
                3.2   DEFINING DELIVERY PATHS                 3-2

                3.2.1     DOMAIN.NAMES Paths  ____________    3-3

                _________________________________________________
                3.3   ALIAS TRANSLATION                       3-4

                _________________________________________________
                3.4   CONTROLLING THE ROUTER PROCESS          3-5

                _________________________________________________
                3.5   LOGGING ROUTER EVENTS                   3-5

          _______________________________________________________
          CHAPTER 4  MANAGING THE DELIVERY AGENTS             4-1

                _________________________________________________
                4.1   LOCAL DELIVERY OPTIONS                  4-1

                _________________________________________________
                4.2   SMTP, DECNET_SMTP, AND X25_SMTP
                      DELIVERY OPTIONS                        4-1

                4.2.1     Internet "Mail Exchanger"
                          Support  _______________________    4-2

          iv

 


                                                         Contents





                4.2.2     Default SMTP Router  ___________    4-2

                _________________________________________________
                4.3   THE JNET INTERFACE                      4-3

                4.3.1     Jnet Address Conversion  _______    4-3

                4.3.2     Gateway Policy  ________________    4-4

                4.3.3     Jnet Node Name  ________________    4-4

                4.3.4     Mailer Username  _______________    4-4

                4.3.5     XMAILER.NAMES, DOMAIN.NAMES,
                          and BITEARN.NODES Files  _______    4-5
                4.3.5.1     BITEARN.NODES and MXBITNET.MAILERS
                            Files, 4-6
                4.3.5.2     XMAILER.NAMES File, 4-8
                4.3.5.3     DOMAIN.NAMES File, 4-8

                _________________________________________________
                4.4   UUCP DELIVERY OPTIONS                   4-9

                _________________________________________________
                4.5   SITE DELIVERY OPTIONS                  4-10

                _________________________________________________
                4.6   THE LISTSERV INTERFACE                 4-10

                _________________________________________________
                4.7   SHUTDOWNS AND RESETS                   4-10

                _________________________________________________
                4.8   LOGGING DELIVERY AGENT EVENTS          4-11

          _______________________________________________________
          CHAPTER 5  MANAGING MESSAGE ENTRY AGENTS            5-1

                _________________________________________________
                5.1   LOCAL MESSAGE ENTRY                     5-1

                                                                v

 


          Contents





                5.1.1     VMS MAIL Protocol Prefix  ______    5-2

                5.1.2     From Header Format  ____________    5-2

                _________________________________________________
                5.2   SMTP_SERVER                             5-3

                _________________________________________________
                5.3   DECNET_SMTP NETWORK OBJECT              5-3

                _________________________________________________
                5.4   X25_SMTP NETWORK OBJECT                 5-5

                _________________________________________________
                5.5   MESSAGE ENTRY AGENT SHUTDOWNS           5-6

          _______________________________________________________
          CHAPTER 6  MANAGING THE MESSAGE QUEUE               6-1

                _________________________________________________
                6.1   ESTABLISHING THE QUEUE SIZE             6-1

                _________________________________________________
                6.2   RUNNING THE MX FLQ MANAGER              6-2

                _________________________________________________
                6.3   QUEUE CLEANUP LOGICALS                  6-2

                _________________________________________________
                6.4   AUTOMATIC PURGING OF FINISHED QUEUE
                      ENTRIES                                 6-4

                _________________________________________________
                6.5   THE MCP QUEUE COMMANDS                  6-4

                6.5.1     Interpreting MCP QUEUE SHOW
                          Output  ________________________    6-4

                6.5.2     Interpreting MCP QUEUE
                          STATISTICS Output  _____________    6-6

          vi

 


                                                         Contents





          _______________________________________________________
          CHAPTER 7  OTHER MISCELLANEOUS UTILITIES            7-1

                _________________________________________________
                7.1   THE MLFAKE UTILITY                      7-1

                _________________________________________________
                7.2   THE MAILQUEUE UTILITY                   7-2

                _________________________________________________
                7.3   THE MX_DECODE UTILITY                   7-3


          _______________________________________________________
          CHAPTER 8  TROUBLESHOOTING MX                       8-1

                _________________________________________________
                8.1   QUEUE FILES USED BY MX COMPONENTS       8-1

                8.1.1     File Types  ____________________    8-2

                _________________________________________________
                8.2   PROCESS NAMES                           8-3

                _________________________________________________
                8.3   DEBUG/TRACE OUTPUT                      8-4

          _______________________________________________________
          CHAPTER 9  THE MX STARTUP PROCESS                   9-1

                _________________________________________________
                9.1   STARTUP COMMAND PROCEDURES              9-1

                _________________________________________________
                9.2   STARTUP DATA FILES                      9-2

                9.2.1     MX_LOGICALS.DAT  _______________    9-3

                9.2.2     MX_STARTUP_INFO.DAT  ___________    9-3

                                                              vii

 


          Contents





                _________________________________________________
                9.3   TYPICAL MX_STARTUP_INFO
                      MODIFICATIONS                           9-5


          _______________________________________________________

          MCP COMMAND DICTIONARY
                MCP                                  MCP-3
                @ (REDIRECT COMMAND INPUT)           MCP-5
                DEFINE ALIAS                         MCP-6
                DEFINE FILE_SERVER                   MCP-7
                DEFINE LIST                         MCP-11
                DEFINE PATH                         MCP-19
                DEFINE REWRITE_RULE                 MCP-21
                DEFINE SYSTEM_USERS                 MCP-23
                EXIT                                MCP-25
                HELP                                MCP-26
                MODIFY                              MCP-27
                QUEUE CANCEL                        MCP-28
                QUEUE COMPRESS                      MCP-29
                QUEUE CREATE                        MCP-31
                QUEUE EXTEND                        MCP-32
                QUEUE PURGE                         MCP-33
                QUEUE READY                         MCP-34
                QUEUE SHOW                          MCP-35
                QUEUE STATISTICS                    MCP-39
                QUEUE SYNCHRONIZE                   MCP-40
                QUIT                                MCP-41
                REMOVE                              MCP-42
                RESET                               MCP-43
                REVIEW                              MCP-45
                SAVE                                MCP-46
                SET DECNET_SMTP                     MCP-47
                SET JNET                            MCP-49
                SET LOCAL                           MCP-52
                SET ROUTER                          MCP-56
                SET SITE                            MCP-58
                SET SMTP                            MCP-59

          viii

 


                                                         Contents





                SET X25_SMTP                        MCP-61
                SHOW                                MCP-63
                SHUTDOWN                            MCP-65
                STATUS                              MCP-67


          _______________________________________________________
          INDEX


          _______________________________________________________
          FIGURES

                1-1       Message parts  _________________    1-2

                1-2       Message path  __________________    1-4

          _______________________________________________________
          TABLES

                6-1       FLQ Manager/Router
                          queue-related logicals  ________    6-3

                8-1       Debug/Trace logical names  _____    8-5

                9-1       Component names for use with
                          MX_STARTUP.COM  ________________    9-1

                MCP-1     Mailing list protection
                          classes  _______________________ MCP-15

                MCP-2     Mailing list protection codes  _ MCP-15

                MCP-3     Typical protection codes  ______ MCP-16

                MCP-4     Header name keywords  __________ MCP-53

                MCP-5     MCP STATUS Descriptions  _______ MCP-68


                                                               ix

 







          _______________________________________________________

          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 nine
          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    Contains information about how Message
          1          Exchange operates.

          Chapter    Describes how to use the MXCONFIG procedure.
          2

          Chapter    Describes how to manage the Router
          3          functions.

          Chapter    Describes how to manage the message delivery
          4          agents.

          Chapter    Describes how to manage the message entry
          5          agents.

          Chapter    Describes how to manage the message queue.
          6

          Chapter    Describes some miscellaneous MX utilities.
          7

                                                               ix

 


          Preface






          Chapter    Describes the tools available for
          8          troubleshooting MX.

          Chapter    Describes the MX startup process.
          9

          __________________________________________________________________

          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 Programmer's Guide describes the
             programmable customization features

          o  Message Exchange Mailing List/File Server Guide
             describes the MX Mailing List/File Server.

          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.

          o  RFC 1123: Requirements for Internet Hosts -
             Application and Support provides additional
             information on SMTP support for Internet hosts.

          x

 








          _______________________________________________________

   1      Overview of Message Exchange Operation



          This chapter briefly describes how MX operates.

          __________________________________________________________________

   1.1    What is a Message?

          Electronic mail messages are usually divided up into
          three parts:

          o  The envelope. Much like an envelope used for mail in
             the real world, an electronic mail envelope includes
             a return address and destination information. Unlike
             real mail, however, one message can have multiple
             destinations. In addition, addresses on the envelope
             can be changed as they pass through a system.

          o  The headers. Message headers include information
             about the message that the recipient will see
             when he or she reads the message. This information
             includes the date the message was sent, the subject
             of the message, who sent it and who will receive it,
             and which systems the message passed through on its
             way to the recipient.

          o  The body. This is the message text itself, as
             entered by the person (or other entity) that sent
             the message.

          There are several standards for the format of each
          part of a message. MX uses the Internet RFC 822 format
          for message headers and body, and Internet RFC 821
          format for envelope information. When sending messages
          to non-Internet sites, MX will convert the message
          format as needed to comply with the standards required
          by the destination system. Figure 1-1 is an example of
          a message broken down into its parts.

                                                              1-1

 


          Overview of Message Exchange Operation




          Figure 1-1  Message parts
          _______________________________________________________

          Envelope:

              <user1@host1.org>       Return address
              <user2@host2.org>       Recipient #1
              <user3@host3.org>       Recipient #2

          Headers:

              Received: from host1.org by host2.org with SMTP; 01 Oct 1990 12:32:01 EDT
              Date: Mon, 01 Oct 1990 11:19:47 EDT
              From: user1@host1.org
              To: user2@host2.org
              Cc: user3@host3.org
              Subject: Hello there

          Body:

              Just a quick note to let you know I'm alive.
              Have a nice day.

          _______________________________________________________

          __________________________________________________________________

   1.2    What is an Address?

          Much like the address on a real envelope, an
          electronic mail address indicates where a message
          should be delivered, or where it came from. MX uses
          the Internet RFC 822 format for addresses. RFC 822
          specifies a very rich syntax for addresses, but most
          are of the form:

                                                      local-part@domain

          Where domain usually identifies a system and local-
          part identifies the user on that system.

          1-2

 


                           Overview of Message Exchange Operation





          Envelope Addresses

          Envelope addresses are kept by MX in a special format,
          the route-address, which adheres to Internet RFC
          821. Users cannot generally use route-addresses when
          addressing mail; they are used internally by MX and
          other mail systems for tracking the route a message
          has taken to get from source to destination, or for
          forcing a particular route to be taken for a message.

          A route-address has the form

                                                     <local-part@domain>
                                                             or
                                          <@domain[,@domain...]:local-part@domain>

          This form of addressing is discouraged on the
          Internet, but is used when messages are gatewayed
          between multiple mail networks.

          __________________________________________________________________

   1.3    MX Components

          Message Exchange consists of several parts:

          o  A message queue, where all messages are stored
             during processing by MX.

          o  Message entry agents. These programs or processes
             take messages in from users or from other networked
             hosts and enter them in the message queue for
             processing.

          o  The Router. This is the "hub" of MX processing. All
             incoming messages have their envelope information
             processed by the Router to determine how they should
             be delivered.

          o  Message delivery agents. These programs or processes
             take messages that have been processed by the router
             and deliver them either to local users or to other
             networked hosts.

                                                              1-3

 


          Overview of Message Exchange Operation





          o  The Mailing List/File Server (MLF) agent. This
             special process handles all mailing list and file
             server requests.

          Figure 1-2 depicts how the MX components interact.

          Figure 1-2  Message path
          _______________________________________________________

                                    WIDE


          _______________________________________________________

          ___________________________

   1.3.1  The Message Queue

          All MX messages are stored in a directory called the
          message queue (sometimes called the file queue). This
          is the directory pointed to by the logical name MX_
          FLQ_DIR. Besides the files comprising the messages
          themselves, the queue directory also contains a file
          called MX_SYSTEM_QUEUE.FLQ_CTL. This file, called the
          queue control file, is a sequential file that contains
          information about the state of each message, who is
          processing it, etc. All MX processes access their
          queue entries through this control file.

          The size of the queue control file determines the
          maximum number of entries that can be in the queue at
          any given time. The larger the file, the more entries
          that can be in the queue.

          Because the message queue is shareable cluster-wide,
          a user on any node in a VMScluster can send messages
          over a network, even if there is no direct network



          1-4

 


                           Overview of Message Exchange Operation





          connection (via TCP/IP, X.25, UUCP, etc.) on the
          particular node to the target network.[1]

          ___________________________

   1.3.2  Message Entry Agents

          Messages are entered into MX by users from VMS Mail
          through the MX% protocol prefix. This invokes routines
          in image MX_EXE:MX_MAILSHR.EXE, which create the
          necessary files in the message queue for processing
          by the Router.

          Messages coming in from other hosts are handled by

          o  an SMTP server, for messages coming in over TCP/IP;

          o  a DECnet-SMTP server, for messages coming in via
             SMTP-over-DECnet;

          o  an X.25-SMTP server, for messages coming in via
             SMTP-over-X.25;

          o  the Jnet Mail/File dispatcher and interface process,
             for messages coming in over Jnet;

          o  the RMAIL program, for messages coming in via UUCP;
             or

          o  the MX_SITE_IN program, for messages coming in from
             a locally-created network interface.

          Messages are also entered into the queue by the
          Mailing List/File Server (MLF) agent, in response to a
          mailing list or file server request.

          ________________
        [1]  When following the MX clustering guidelines

            described in Message Exchange Installation Guide.

                                                              1-5

 


          Overview of Message Exchange Operation




          ___________________________

   1.3.3  The Router

          The Router is responsible for taking the envelope
          information from a message and determining where the
          message should be sent based on the addresses listed
          in the envelope.

          Each recipient address in the envelope is processed in
          two or three phases:

          1  In the rewrite phase, the address is checked against
             a list of rewriting rules. If it matches one of the
             rules, the rule is applied and the original address
             is replaced.

          2  In the path identification phase, the next hop
             domain of the address is identified and that domain
             is checked against the domain-path mapping list.
             This identifies the delivery agent that will be
             called on to deliver the message to the recipient.

          3  If the recipient is on the local system, a third
             phase is entered, which checks to see if the local-
             part of the address is an alias for another address,
             a mailing list name, or file server name.

          The Router is also responsible for maintaining the
          message queue. It cleans out completed or cancelled
          entries.

          ___________________________

   1.3.4  Delivery Agents

          The Local delivery agent delivers mail to local users
          or to other hosts over DECnet using VMS Mail. It also
          identifies local users who have used SET FORWARD to
          direct their mail elsewhere and resends messages to
          their forwarding addresses.

          1-6

 


                           Overview of Message Exchange Operation





          Other delivery agents send messages to other hosts or
          other mail-processing software.

          o  The SMTP delivery agent sends messages using the
             Simple Mail Transfer Protocol over TCP/IP.

          o  The DECNET_SMTP delivery agent sends messages using
             the Simple Mail Transfer Protocol over DECnet.

          o  The X25_SMTP delivery agent sends messages using the
             Simple Mail Transfer Protocol over X.25 (using VAX
             P.S.I.).

          o  The Jnet delivery agent sends messages either using
             the Batch SMTP protocol or as regular BITNET note
             files.

          o  The UUCP delivery agent passes messages to the UUCP
             package for processing.

          o  The SITE delivery agent passes messages to a
             locally-created network interface package.

          o  The LISTSERV delivery agent passes messages to
             L-Soft International's LISTSERV mailing list
             processor.

          Each delivery agent is responsible for converting
          MX-format messages into the format required for the
          particular network or network interface package.

          ___________________________

   1.3.5  MLF Agent

          The Mailing List/File Server (MLF) agent is a special
          form of delivery agent that handles mailing list and
          file server requests. It doesn't actually deliver
          messages to a network directly. What it does is create
          new messages based on the list or server requests
          and sends the new messages back to the Router for
          processing and eventual delivery.

                                                              1-7

 








          _______________________________________________________

   2      Configuring MX with MXCONFIG



          This chapter describes the MXCONFIG procedure, MX_
          DIR:MXCONFIG.COM.

          __________________________________________________________________

   2.1    Why Use MXCONFIG?

          Configuring MX by hand is a complicated and error-
          prone process, due to the number of options available.
          Based on a question-and-answer script, MXCONFIG
          creates a command file that will generate an MX
          configuration database. Configurations created with
          MXCONFIG should be adequate for most Internet and
          BITNET/EARN sites; it can also be used as a base that
          can be tailored using the MX Control Program (MCP), if
          needed.

          __________________________________________________________________

   2.2    Using MXCONFIG

          When you execute MXCONFIG, it displays some
          introductory information and then asks you what you
          want to call the MCP command file it generates:

              * What do you want to call the command file? [MX_DIR:CONFIG.MCP]:

          Just press RETURN to accept the default answer, or
          enter a new filename for the MCP commands MXCONFIG
          will generate.




                                                              2-1

 


          Configuring MX with MXCONFIG




          ___________________________

   2.2.1  Selecting Delivery Paths

          It then displays a menu of delivery paths for you
          to select from. MXCONFIG will scan your MX startup
          information file (MX_DIR:MX_STARTUP_INFO.DAT) and
          will pre-select the delivery paths it finds there. For
          example:

                   1. [*] SMTP over TCP/IP
                   2. [*] BITNET/EARN (Jnet)
                   3. [ ] UUCP
                   4. [ ] SMTP over DECnet
                   5. [ ] SMTP over X.25

                   6.     Exit

              *      Your choice [6]:

          To de-select a delivery path, select it a second
          time. When you are finished, select the Exit option
          to continue with the script.

          __________________________________________________________________

   2.3    Local Node Name Information

          Depending on the delivery paths you selected, you
          will be prompted to enter network node names for
          each network that identify the local node. Follow
          the instructions provided by MXCONFIG and enter the
          information carefully.

          As you proceed through the script, MXCONFIG will
          notify you of any gateways it has assigned for your
          system. If the gateways it selects are incorrect
          for your system, you should edit the command file
          generated by MXCONFIG before using MCP to build your
          MX configuration database.

          2-2

 


                                     Configuring MX with MXCONFIG




          __________________________________________________________________

   2.4    Establishing A Postmaster Alias

          After path definition and node name entry, you are
          asked to establish an alias in MX for the user
          Postmaster. All Internet and BITNET sites must be
          able to accept mail to Postmaster, either by having a
          POSTMASTER username or through an alias. BITNET sites
          must also accept mail to POSTMAST, the eight-character
          truncation of Postmaster.

          If you already have a POSTMASTER username on your
          system that can accept incoming mail, you do not need
          to establish a Postmaster alias. Otherwise, you should
          provide a valid E-mail address (preferably local) when
          asked:

              * Enter an alias for Postmaster (user@host):

          MXCONFIG will automatically create both the Postmaster
          and POSTMAST aliases for you.

          __________________________________________________________________

   2.5    Finishing the Configuration

          Once all of the configuration questions have been
          asked, MXCONFIG asks:

              * Would you like to run MCP now to build the configuration? [Y]:

          If you answer YES, MXCONFIG will run MCP for you,
          building an MX configuration file from the commands
          it generated during the script. Otherwise, it will
          provide instructions on how to use the command file
          it generated to create your own MX configuration file
          using MCP.



                                                              2-3

 








          _______________________________________________________

   3      Managing the Router



          This chapter describes the MCP commands used to
          configure and control the Router.

          __________________________________________________________________

   3.1    Rewrite Rules

          Address-rewriting rules, or rewrite rules for short,
          are checked by the Router for every recipient address
          on every envelope of every message that passes through
          MX. A rewrite rule consists 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 provide a general
          means of altering envelope addresses, primarily for
          handling multi-gateway cases where DEFINE PATH/ROUTE
          is insufficient.

          Be careful, since the rule processor treats the
          addresses as ordinary text strings and does not
          understand the syntax of RFC 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.

          An example of an application for rewrite rules is
          the mapping of an artificial domain name, such as
          host.dnet, into an address for delivery through VMS
          MAIL over DECnet:

              MCP> DEFINE REWRITE_RULE "<{user}@{host}.dnet>" -
              _MCP>                    "<""{host}::{user}""@local.host.name>"

                                                              3-1

 


          Managing the Router





          The pattern matching routine treats the variable
          references in the first string as wildcards;
          everything between the left angle bracket and the
          at sign is copied into the {user} variable, and
          everything between the at sign and the string .dnet>
          is copied into the {host} variable. The variable names
          have no special significance to the pattern matching
          routine.

          __________________________________________________________________

   3.2    Defining Delivery Paths

          The first step the Router takes in determining a
          delivery path is to identify 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,
          and possibly a routing host for that domain.

          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 DECNET_SMTP, JNET, LOCAL, SITE, SMTP, UUCP, and
          X25_SMTP.

          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 *.BITNET               SMTP/ROUTE=cunyvm.cuny.edu
              MCP> DEFINE PATH *.UUCP                 SMTP/ROUTE=uunet.uu.net
              MCP> DEFINE PATH *                      SMTP

          3-2

 


                                              Managing the Router





          When setting up a path for X25_SMTP traffic, the DTE
          logicals defined in the PSI$DTE_TABLE logical name
          table should be specified as the /ROUTE values. For
          example, assume two nodes wish to exchange mail using
          X25_SMTP. Node A's domain name is node_a.foobar_
          org.whatever, and Node B's name is node_b.whocares_
          org.whatever. The MCP command to define the path on
          node A would be:

              MCP> DEFINE PATH "*.whocares_org.whatever" X25_SMTP -
              _MCP> /ROUTE="WHOCARES_DTE_LOGICAL"

          On Node B, the MCP command would be:

              MCP> DEFINE PATH "*.foobar_org.whatever" X25_SMTP -
              _MCP> /ROUTE="FOOBAR_DTE_LOGICAL"

          where the *_DTE_LOGICALs are the logicals defined in
          PSI$DTE_TABLE.

          The path list is searched sequentially until a match
          is made. The first three rules catch any locally-
          addressed messages. The next two rules provide
          transparent routing of addresses in the BITNET and
          UUCP "fake domains" through their respective Internet
          gateways. The last rule, which would match any other
          domain name, 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.

          ___________________________

   3.2.1  DOMAIN.NAMES Paths

          If no paths from the configuration file match a domain
          name, the Router will automatically examine paths
          built from a BITNET/EARN DOMAIN.NAMES file, which
          describes the appropriate BITNET/EARN routes for
          Internet domain-style addresses. See Section 4.3.5
          for further information about obtaining a DOMAIN.NAMES
          file.

                                                              3-3

 


          Managing the Router




          __________________________________________________________________

   3.3    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
          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. You
          can disable the percent-dehacking function with the
          MCP command SET ROUTER/NOPERCENT_HACK.

          3-4

 


                                              Managing the Router




          __________________________________________________________________

   3.4    Controlling the Router Process

          The Router process will respond to shutdown and reset
          signals sent by the MCP SHUTDOWN and RESET commands,
          respectively. Using these commands is the only way
          that the Router can be shut down or reset without
          possibly losing messages.

          __________________________________________________________________

   3.5    Logging Router Events

          Major events in the Router process, such as startup,
          shutdown, and configuration resets, are automatically
          logged to the Router's log file, MX_ROUTER_DIR:MX_
          ROUTER_nodename.LOG. These events may also be logged
          to an operator console by defining the logical name
          MX_EVENT_OPER_CLASS:

              $ DEFINE/SYSTEM/EXEC MX_EVENT_OPER_CLASS class-name

          where class-name can be any recognized OPCOM operator
          class, such as NETWORK.

          This logical name must be defined before MX is started
          in order to have any effect. Its definition affects
          all MX processing agents.












                                                              3-5

 








          _______________________________________________________

   4      Managing the Delivery Agents



          This chapter describes some of the MCP commands used
          to configure and control the various MX delivery
          agents.

          __________________________________________________________________

   4.1    Local Delivery Options

          The local delivery agent can be configured to place
          message header lines at either the beginning of the
          message text, the end of the message text, or both,
          when delivering locally through VMS Mail.

          In addition, you can control whether accounting
          information is generated, the delivery retry interval,
          and the maximum retry count. By default, unsuccessful
          deliveries into VMS Mail are retried every half hour
          up to 96 times total (giving a two-day period) before
          being returned to sender.

          The MCP SET LOCAL command can be used to alter any of
          these settings; refer to the command description for
          further information.

          __________________________________________________________________

   4.2    SMTP, DECNET_SMTP, and X25_SMTP Delivery Options

          As with the local delivery agent, you can alter
          the accounting setting, the retry interval, and
          the maximum retry count for SMTP, DECNET_SMTP,
          and X25_SMTP deliveries. However, the SMTP agent
          differentiates between failed deliveries due to
          domain name lookup failures and other kinds of failed
          deliveries, and you can set a different maximum retry
          count for DNS lookup failures. The MCP SET SMTP, SET
          DECNET_SMTP, and SET X25_SMTP commands are used to
          alter the settings for the three delivery agents.

                                                              4-1

 


          Managing the Delivery Agents





          The defaults are 30 minutes for retry interval, 12
          DNS failures maximum (for SMTP only), and 96 general
          failures maximum.

          Refer to the command descriptions for further
          information.

          ___________________________

   4.2.1  Internet "Mail Exchanger" Support

          Some of the supported TCP/IP packages include domain
          name resolvers that provide 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
          exchanger.

          For those TCP/IP packages that do not track mail
          exchanger data, the MX SMTP delivery agent maintains
          its own database of mail exchanger mappings. The
          initial list of domain servers to be asked for MX
          information is controlled by the NETLIB software.
          Refer to the NETLIB release notes for further
          information.

          ___________________________

   4.2.2  Default SMTP Router

          When the local system uses host tables instead of
          Domain Name Service, you may want to establish a
          default router for SMTP messages. 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 in MCP with the SET
          SMTP/DEFAULT_ROUTER command.

          4-2

 


                                     Managing the Delivery Agents





          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" more about
             the Internet than your host, or in turn can forward
             to another host that has access to more domain name
             information.

          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.3    The Jnet Interface

          The MX/Jnet interface module runs as a detached
          process. 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.

          ___________________________

   4.3.1  Jnet Address Conversion

          The Jnet interface will automatically convert
          addresses on outgoing mail such that local addresses
          use the RSCS node name and all non-BITNET, non-local
          addresses are "percent-hacked" to provide a route back
          through the local system for hosts that are connected
          only to BITNET.

          BITNET-style addresses are automatically percent-
          hacked on incoming messages and de-hacked when
          outgoing, to guarantee a return path for mail being
          forwarded to other networks. If Jnet is the only

                                                              4-3

 


          Managing the Delivery Agents





          network transport you are using for mail, you can
          disable this feature with the MCP SET JNET/NOPERCENT_
          HACK command. This is done automatically for you if
          you use the MXCONFIG.COM procedure to configure MX.

          You can also use the SET JNET command to control
          whether accounting information is generated and
          whether BSMTP replies are generated. See the SET JNET
          command description for further information.

          ___________________________

   4.3.2  Gateway Policy

          Recently announced BITNET/EARN rules prohibit
          Internet/BITNET gateways from gatewaying mail to or
          from BITNET hosts that do not have a BSMTP-compliant
          mailer (such as MX). MX enforces these rules unless
          you use the MCP SET JNET/LENIENT command.

          ___________________________

   4.3.3  Jnet Node Name

          MX will use the Jnet cluster node name on all outgoing
          mail, if you have enabled Jnet clustering. Otherwise,
          MX will use the local Jnet node name. You can override
          this selection by defining the logical name MX_JNET_
          NODE:

              $ DEFINE/SYSTEM MX_JNET_NODE nodename

          No validity checking is performed on the specified
          node name.

          ___________________________

   4.3.4  Mailer Username

          BITNET mail protocols require the use of a reserved
          "mailer" username, through which most incoming and
          outgoing mail messages will be sent. This username is
          registered in the BITNET/EARN node tables and is used
          by other mailers on the network to determine which
          mail protocols can be used to communicate with your

          4-4

 


                                     Managing the Delivery Agents





          system. The recommended mailer username is MAILER. You
          should not use SYSTEM as your mailer username.

          You can implement a mailer username either with the
          /USERNAME qualifier on the SET JNET command or by
          running the MX/Jnet interface under a mailer account
          you create specifically for use with MX, as described
          in Message Exchange Installation Guide.

          ___________________________

   4.3.5  XMAILER.NAMES, DOMAIN.NAMES, and BITEARN.NODES Files

          In order to communicate with other mailers on BITNET,
          you must register your node's mailer username in the
          BITNET/EARN node table. Information on how to update
          your BITNET node entry can be obtained from your local
          LISTSERV@BITNIC:

              $ SEND LISTSERV@BITNIC GET UPDATE PROCEDUR

          The person performing the update must be the BITNET
          contact person for the node being updated, or some
          other authorized entity.

          The following example shows a typical command used to
          update your BITNET node entry for MX:

              MODIFY NODE node
              :servers1.mailer@node(MAIL,ND PU,M,BSMTP,P_user)

          This command can be sent to UPDATE@BITNIC to establish
          your mailer account (substituting the appropriate
          username and node, of course). Jnet can received mail
          files in either NETDATA or PUNCH format; the ``ND PU''
          in the command above will inform other BITNET mailers
          that your node can accept both (and prefers NETDATA).
          NETDATA is the preferred format, because there is no
          line length limitation as there is for PUNCH files.

          In order for MX to determine the capabilities of
          mailers on other systems on BITNET, you must provide
          either BITEARN.NODES file or XMAILER.NAMES. If
          you're not directly connected to the Internet, you

                                                              4-5

 


          Managing the Delivery Agents





          should also provide DOMAIN.NAMES. All three files are
          described below.

          If BITEARN.NODES is available, then MX can send either
          files via Jnet as either NETDATA or PUNCH, depending
          on the preference established for the target nodes.
          If XMAILER.NAMES is used instead, only PUNCH files can
          be sent, because preferred mail format information for
          nodes is not supplied in XMAILER.NAMES.
                 _____________________
                 4.3.5.1  BITEARN.NODES and MXBITNET.MAILERS
                          Files
          The file BITEARN.NODES contains descriptions of all
          the systems on the BITNET/EARN networks. Every BITNET
          node is fully described in BITEARN.NODES; the file
          XMAILER.NAMES is created from this file. In order to
          provide support for sending NETDATA files, MX uses
          BITEARN.NODES to create its own mailer file, called
          MXBITNET.MAILERS.

          BITEARN.NODES

          Because all BITNET nodes are listed in BITEARN.NODES,
          the file can be pretty big (several thousand blocks).
          You can arrange to have monthly updates sent to you
          from a NETSERV site near you. By applying the monthly
          updates, your mailer information stays current.

          You can obtain a copy of BITEARN.NODES from your local
          NETSERV, or from NETSERV@BITNIC:

              $ SEND NETSERV@BITNIC GET BITEARN NODES

          The file may also be available from a neighboring
          site; because of the file's size, you might try to
          acquire a copy from a neighbor before requesting it
          from NETSERV.

          If you have a NETSERV access password, you can have
          the monthly updates distributed to you automatically
          with the NETSERV AFD command. Send the command HELP to
          your local NETSERV for further information. Software
          for applying the updates can be obtained by sending

          4-6

 


                                     Managing the Delivery Agents





          the following commands in the body of a mail message
          to FILESERV@WKUVX1.WKU.EDU:

              SEND UPDNODES
              SEND FILESERV_TOOLS

          MXBITNET.MAILERS

          If the file BITEARN.NODES is found in MX_JNET_
          DIR:, the MX Jnet interface will scan the file for
          mailer information for all the nodes, producing
          the MX-private file MX_JNET_DIR:MXBITNET.MAILERS.
          This file contains the mailer names for all BITNET
          sites, as well as the sites' preferred mail formats.
          This file is then read during the MX Jnet interface
          initialization; when mail is sent to a BITNET site, MX
          consults the data from this file to determine whether
          the message should be sent as a PUNCH file or as a
          NETDATA file. Lines are wrapped at 80 characters for
          PUNCH files, but not for NETDATA files.

          You can avoid the need for maintaining BITEARN.NODES
          if you get it from the VMS Store, a repository
          of VMS utilities maintained by Eric Thomas
          (ERIC@SEARN.BITNET). You can get the current version
          of MXBITNET.MAILERS by sending the following command
          to LISTSERV@SEARN.BITNET.

              $ SEND LISTSERV@SEARN GET <BITNET>MXBITNET.MAILERS

          You can also have MXBITNET.MAILERS automatically
          distributed to you each month using the following
          command.

              $ SEND LISTSERV@SEARN AFD ADD <BITNET>MXBITNET.MAILERS





                                                              4-7

 


          Managing the Delivery Agents




                 _____________________
                 4.3.5.2  XMAILER.NAMES File
          If you elect not to use BITEARN.NODES and/or
          MXBITNET.MAILERS, then you should 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 your local
          NETSERV, or from NETSERV@BITNIC:

              $ SEND NETSERV@BITNIC GET XMAILER NAMES

          If you cannot contact a NETSERV server, the contact
          person for a host that is upstream from you should
          have a copy of this file.

          If you do not have a copy of this file in MX_
          ROOT:[JNET], MX will not be able to contact mailers
          at other sites on the networks, nor will it be able
          to use the BSMTP protocol, which is required when
          communicating with the INTERBIT gateways.
                 _____________________
                 4.3.5.3  DOMAIN.NAMES File
          If you do not have a direct Internet connection, you
          should also obtain a copy of DOMAIN.NAMES and place
          it in MX_ROOT:[JNET]. The Router will use this file
          to route non-BITNET messages to appropriate gateways.
          DOMAIN.NAMES is also available from NETSERV:

              $ SEND NETSERV@BITNIC GET DOMAIN NAMES

          If you cannot contact a NETSERV server, the contact
          person for a host that is upstream from you should
          have a copy of this file.

          These files are updated monthly. If you have a NETSERV
          access password, you can have the monthly updates
          distributed to you automatically with the NETSERV AFD
          command. Send the command HELP to your local NETSERV
          for further information.


          4-8

 


                                     Managing the Delivery Agents





          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
          registered, you should omit any reference to mailers
          in your XMAILER.NAMES file.

          __________________________________________________________________

   4.4    UUCP Delivery Options

          The MX_RMAIL program (part of the UUCP interface)
          can be configured to use DECUS UUCP's MAIL_REWRITE
          rules to translate addresses on messages coming in
          from UUCP. To use this feature, execute the following
          logical name definition prior to starting MX (or add
          it to the file MX_DIR:MX_LOGICALS.DAT):

              $ DEFINE/SYSTEM MX_UUCP_REWRITE TRUE

          The MX_RMAIL program will automatically use the
          rewrite rules in the file UUCP_CFG:MAIL_REWRITE.RULES.
          If you would rather define your own INBOUND_TO and
          INBOUND_FROM rules for use by MX_RMAIL, place them in
          the file MX_UUCP_DIR:UUCP_MAIL_REWRITE.RULES. If that

                                                              4-9

 


          Managing the Delivery Agents





          file is present, MX_RMAIL will use it instead of the
          file in UUCP_CFG.

          __________________________________________________________________

   4.5    SITE Delivery Options

          The SITE delivery agent includes support for retry
          on error. The MCP SET SITE command can be used to
          alter the retry interval and maximum retry count.
          Refer to the SET SITE command description for further
          information.

          __________________________________________________________________

   4.6    The LISTSERV Interface

          The MX/LISTSERV interface module runs as a detached
          process. If L-Soft International's LISTSERV product
          is installed on the system, MX Router automatically
          detects messages destined for LISTSERV and mailing
          lists and passes them on to the LISTSERV software for
          processing.

          There are no MCP commands to control MX LSV.

          __________________________________________________________________

   4.7    Shutdowns and Resets

          Each of the delivery agents will respond to shutdown
          and reset signals as sent by the MCP SHUTDOWN and
          RESET commands, respectively. Using these commands
          is the only guaranteed way of cleanly shutting down
          and resetting the delivery agents, without loss of
          messages in progress.

          There may be times when it is necessary to prevent
          local users from using VMS Mail to send mail via MX.
          To do so, define the executive-mode system logical
          name MX_SHUTDOWN:

              $ DEFINE/SYSTEM/EXEC MX_SHUTDOWN TRUE

          4-10

 


                                     Managing the Delivery Agents





          If a user tries to send mail to an MX% address and
          MX_SHUTDOWN is defined, VMS Mail (MX_MAILSHR) will
          display an error message stating that MX has been
          temporarily disabled by the system manager.

          __________________________________________________________________

   4.8    Logging Delivery Agent Events

          Major events in the delivery agents, such as startup,
          shutdown, and configuration resets, are automatically
          logged to each agent's log file. These events may
          also be logged to an operator console by defining the
          logical name MX_EVENT_OPER_CLASS:

              $ DEFINE/SYSTEM/EXEC MX_EVENT_OPER_CLASS class-name

          where class-name can be any recognized OPCOM operator
          class, such as NETWORK.

          This logical name must be defined before MX is started
          in order to have any effect. Its definition affects
          all MX processing agents.

















                                                             4-11

 








          _______________________________________________________

   5      Managing Message Entry Agents



          This chapter describes the options available with the
          MX message entry agents.

          __________________________________________________________________

   5.1    Local Message Entry

          The VMS MAIL interface (MX_MAILSHR) is used for local
          message entry. It is controlled through the definition
          of system-wide logical names.

          Usage of MX through VMS Mail can be restricted by
          defining the executive-mode logical MX_RESTRICT_USAGE
          in the system logical name table:

              $ DEFINE/SYSTEM/EXEC MX_RESTRICT_USAGE TRUE

          If the logical is defined, the user must hold the MX_
          MAIL_ACCESS process rights identifier in order to send
          mail using MX. The VMS utility AUTHORIZE is used to
          create and grant identifiers:

              $ set default sys$system:
              $ run authorize
              UAF> ADD/IDENTIFIER MX_MAIL_ACCESS
              Identifier MX_MAIL_ACCESS value: %X8001000D added to rights data base
              UAF> GRANT/IDENTIFIER MX_MAIL_ACCESS GOATHUNTER
              Identifier MX_MAIL_ACCESS granted to GOATHUNTER
              UAF>

          Users not holding the identifier and trying to send
          mail through MX will see an error message stating that
          they are not authorized to send mail using MX.

                                                              5-1

 


          Managing Message Entry Agents




          ___________________________

   5.1.1  VMS MAIL Protocol Prefix

          MX by default uses the foreign protocol prefix MX%
          when interfacing with VMS Mail. You can define
          alternate foreign protocol prefixes for use with
          MX, to provide a migration path for users from other
          mail systems to MX. MX will correctly handle the
          following prefixes: SMTP%, WINS%, IN%, JNET%, IHMF%,
          VN%, ST%, INET%, and UUCP%.[1] To set up one of these
          alternate prefixes in VMS Mail, define the logical
          name MAIL$PROTOCOL_prefix:

              $ DEFINE/SYSTEM/EXEC MAIL$PROTOCOL_prefix MX_MAILSHR

          where prefix is one of the above-mentioned prefixes,
          without the trailing percent sign.

          Note that incoming mail from MX will always bear the
          MX% prefix. If you wish to use another prefix for
          incoming mail, you can define the logical name MX_
          PROTOCOL_PREFIX:

              $ DEFINE/SYSTEM/EXEC MX_PROTOCOL_PREFIX prefix%

          where prefix is one of the above-mentioned prefixes,
          with the trailing percent sign. The default prefix MX%
          is the recommended prefix.

          ___________________________

   5.1.2  From Header Format

          You can control the format of the RFC822 From: header
          that is created by MX_MAILSHR with the logical name
          MX_VMSMAIL_FROM_FORMAT:

              $ DEFINE/SYSTEM/EXEC MX_VMSMAIL_FROM_FORMAT "format-string"

          ________________
        [1] You should not re-direct the UUCP% prefix to MX if
            you are using MX with UUCP. Doing so will prevent
            messages from being delivered to UUCP from MX, since
            MX uses the UUCP_MAILSHR interface (the same as UUCP%

            does).

          5-2

 


                                    Managing Message Entry Agents





          the format-string is passed to the $FAO system service
          as the control string when formatting the From:
          header. The string must start and end with angle
          brackets (<>), and must result in a syntactically
          valid RFC822 address. The FAO directive !AS may be
          used twice in the format string-the first causes
          the local-part (username) of the address to be
          substituted; the second causes the domain-part (host
          name) to be substituted (the second instance is
          optional). The default format string is "<!AS@!AS>".

          __________________________________________________________________

   5.2    SMTP_SERVER

          The SMTP server is a detached, multi-threaded process.
          You can specify how many threads the server should
          handle simultaneously by defining a logical name:

              $ DEFINE/SYSTEM/EXEC MX_SMTP_SERVER_THREADS n

          The value of n should range from 1 to 16. The default
          is 4. The SMTP server may require larger process
          quotas/limits if more than four threads are allowed.

          __________________________________________________________________

   5.3    DECNET_SMTP Network Object

          You must create a DECnet object called DECSMTP for
          establishing SMTP-over-DECnet connections. To do this,
          either use your mailer account or create a dedicated
          server account for use with the DECnet object (a
          dedicated server account is recommended). Using the
          AUTHORIZE utility, set a password for the this account
          and set the account /NOPWDLIFETIME. Also be sure the
          account has network access enabled.

              UAF> MODIFY account/PASSWORD=some-password/NOPWDLIFETIME/network

          A DECnet object needs to be created to handle the
          incoming SMTP-over-DECnet connections and to map the
          DECSMTP object name to a DECnet object number. Choose
          an unused DECnet object number. To see what object
          numbers are currently in use, use the command:

                                                              5-3

 


          Managing Message Entry Agents





              $ MCR NCP SHOW KNOWN OBJECT

          Assign the object name DECSMTP to an unused object
          number; the number used must be identical on all
          nodes on your network that use SMTP-over-DECnet (this
          example uses 254). In NCP, use these commands:

              NCP> PURGE OBJECT DECSMTP ALL
              NCP> DEFINE OBJECT DECSMTP NUMBER 254 PROXY NONE FILE -
              _NCP>    MX_EXE:DNSMTP_SERVER.EXE USER server-acct PASSWORD some-password
              NCP> SET OBJECT DECSMTP ALL

          You do not need to specify the FILE, USER, or PASSWORD
          parameters if you do not intend to accept incoming
          SMTP connections over DECnet. Be sure to use both the
          DEFINE and SET commands of NCP, and be sure that the
          password in the DECnet database matches the password
          you set for the server account in AUTHORIZE.

          Using Proxies

          Instead of storing the username and password for the
          server account in the DECnet database, you could
          grant access using DECnet proxies. Proxies give you
          more control over who on the network has access to
          the object, and eliminate the need for storing the
          password to the server account in the DECnet object
          database.

          To enable proxy access to the DECSMTP object, use the
          following commands in NCP:

              NCP> PURGE OBJECT DECSMTP ALL
              NCP> DEFINE OBJECT DECSMTP NUMBER 254 PROXY INCOMING FILE -
              _NCP>    MX_EXE:DNSMTP_SERVER.EXE
              NCP> SET OBJECT DECSMTP ALL

          Then in AUTHORIZE, create proxy entries for the mailer
          accounts on the other systems on the network that will
          be sending you mail via SMTP-over-DECnet:

              UAF> ADD/PROXY remote::mailer server-acct/DEFAULT

          5-4

 


                                    Managing Message Entry Agents





          For remote::mailer substitute the DECnet node of the
          remote system and the username of the mailer account
          on that system. For server-acct substitute the name
          of the server account you set up for use with the
          DECnet-SMTP object.

          __________________________________________________________________

   5.4    X25_SMTP Network Object

          You must create a DECnet object called X25_SMTP for
          establishing SMTP-over-X.25 connections, both incoming
          and outgoing.

          If you intend to accept incoming SMTP-over-X.25
          connections, you should establish an account (either
          your mailer account or a dedicated server account) for
          use with each DECnet object. See Message Exchange
          Installation Guide for more information on the
          requirements for the DECnet object account.

          A DECnet object needs to be created to handle the
          incoming SMTP-over-X.25 connections and to map the
          X25_SMTP object name to a DECnet object number. Choose
          an unused DECnet object number. To see what object
          numbers are currently in use, use the command:

              $ MCR NCP SHOW KNOWN OBJECT

          Assign the object name X25_SMTP to an unused object
          number; the number used must be identical on all
          nodes on your network that use SMTP-over-DECnet (this
          example uses 253). In NCP, use these commands:

              NCP> PURGE OBJECT X25_SMTP ALL
              NCP> DEFINE OBJECT X25_SMTP NUMBER 253 PROXY NONE FILE -
              _NCP>    MX_EXE:XSMTP_SERVER.EXE USER server-acct PASSWORD some-password
              NCP> SET OBJECT X25_SMTP ALL

          You do not need to specify the FILE, USER, or PASSWORD
          parameters if you do not intend to accept incoming
          SMTP connections over X.25. Be sure that the password
          in the DECnet database matches the password you set
          for the server account in AUTHORIZE.

                                                              5-5

 


          Managing Message Entry Agents





          You must also add an X.25 "destination" to the P.S.I.
          database that maps to the DECnet object:

              NCP> DEFINE MODULE X25-SERVER DESTINATION X25_SMTP -
              _NCP>   OBJECT X25_SMTP PRIORITY 0 -
              _NCP>   CALL MASK  FFFFFFFFFFFFFFFFFFFFFFFF -
              _NCP>   CALL VALUE FF0000005832355F534D5450

              NCP> SET MODULE X25-SERVER DESTINATION X25_SMTP ALL

          Section 3.2, Defining Delivery Paths, contains
          information about defining X25_SMTP paths using MCP.

          __________________________________________________________________

   5.5    Message Entry Agent Shutdowns

          The two message entry mechanisms that do not get
          shut down with the rest of MCP are the VMS Mail
          interface and the DECNET_SMTP server (if you are
          using SMTP-over-DECnet). The VMS Mail interface can
          be deactivated by de-installing the MX_MAILSHR image:

              $ INSTALL REMOVE MX_MAILSHR

          The SMTP-over-DECnet server gets shut down
          automatically when you shut down DECnet, or can be
          manually removed by eliminating the DECSMTP object
          from the DECnet database:

              $ MCR NCP CLEAR OBJECT DECSMTP ALL

          The SMTP-over-X.25 server gets shut down automatically
          when you shut down P.S.I., or can be manually removed
          by eliminating the X25_SMTP object from the DECnet
          database:

              $ MCR NCP CLEAR OBJECT X25_SMTP ALL


          5-6

 








          _______________________________________________________

   6      Managing the Message Queue



          This chapter describes the various commands needed to
          control how the message queue operates.

          __________________________________________________________________

   6.1    Establishing the Queue Size

          The maximum number of queue entries that can be
          present in the MX message queue at any one time is
          determined by the size, in blocks, of the MX message
          queue file. Each entry in the queue requires one
          block, with 10 additional blocks used to store a
          bitmap of entries in use. This means, for example,
          that a queue file that is 510 blocks in size will
          allow 500 entries to be present in the queue. The
          upper ceiling on the maximum entries is 32,767.

          MCP contains commands to let you manipulate the size
          of the message queue file. Using a static, sequential
          file results in performance that is more than 50%
          better than older versions of MX that used an RMS
          indexed file.

          Most sites that process several thousand mail messages
          a day can probably work well with a queue file of
          about 5,000 blocks. If you are not short on disk
          space, creating a 131,072-block file will eliminate
          the need to ever modify the queue file size.






                                                              6-1

 


          Managing the Message Queue




          __________________________________________________________________

   6.2    Running the MX FLQ Manager

          As entries in the message queue are processed, they
          are marked as being finished. By default, one of the
          MX Router processes will be responsible for purging
          out finished entries.

          As of MX V4.0, you have the option of running a
          separate MX FLQ Manager process, whose sole job is
          to purge the queue of finished entries and cancel or
          ready any in-progress entries leftover from system
          crashes, disconnected processes, etc. Running a
          separate FLQ manager frees the MX Router to route
          messages, instead of splitting its time between
          routing and maintaining the queue. This means that
          the MX Router has more time for routing messages and
          queue maintenance isn't delayed while the MX Router is
          routing.

          While the MX FLQ Manager can be run on multiple
          nodes in a cluster, only one manager is ever actively
          maintaining the queue. Running the manager on multiple
          nodes can provide failover backup in case of a node
          crash, etc. If the MX FLQ Manager is shutdown and
          there are no managers running on another node, one
          of the MX Router processes will automatically start
          maintaining the queue.

          Sites that do not process many messages per day will
          probably not benefit from running the MX FLQ Manager
          process.

          __________________________________________________________________

   6.3    Queue Cleanup Logicals

          The Router process (or the MX FLQ Manager process)
          automatically handles cleanup of the message queue.
          The time between cleanup events can be controlled with
          logical names, as described in Table 6-1.

          6-2

 


                                       Managing the Message Queue





          Table_6-1__FLQ_Manager/Router_queue-related_logicals___

                            Default
          Logical___________value___Description__________________

          MX_FLQ_MGR_       2 min.  Amount of time FLQ Manager
          WAKEUP_INTERVAL           sleeps before checking for
                                    entries to purge

          MX_ROUTER_        10      Amount of time MX Router
          WAKEUP_INTERVAL   min.    sleeps before checking for
                                    entries to purge

          MX_FLQ_CHECK_     10      Amount of time between checks
          WAIT              min.    for other queue-related
                                    events

          MX_FLQ_PURGE_     15      Amount of time a queue entry
          WAIT              min.    should remain in queue after
          __________________________it_has_been_processed________

          To alter one of these values, use the DEFINE command
          to set the logical to a new time (using VMS delta-time
          format) and send a reset signal to the Router and/or
          FLQ Manager processes:

              $ DEFINE/SYSTEM MX_FLQ_PURGE_WAIT "0 00:10:00"
              $ MCP RESET ROUTER,FLQ

          (If the Router runs on a different node in the
          cluster, you will have to define the logical name
          there.)

          If you want this change to be permanent and survive
          a system reboot, you can edit the file MX_DIR:MX_
          LOGICALS.DAT and modify the proper line.




                                                              6-3

 


          Managing the Message Queue




          __________________________________________________________________

   6.4    Automatic Purging of Finished Queue Entries

          Finished queue entries are left in the queue for 15
          minutes, by default, before they are purged. It is
          not necessary to leave the entries in the queue once
          they have been marked ``FINished.'' If you prefer
          to not leave them around, you can enable automatic
          purging of FIN entries and their related files using
          the following command:

              $ DEFINE/SYSTEM/EXEC MX_FLQ_AUTOPURGE_FIN TRUE

          Even when autopurging is enabled, it is still
          necessary for the MX FLQ Manager or MX Router process
          to occasionally scan the queue for CANCELed entries.
          However, a dedicated MX FLQ Manager process is not as
          beneficial as it is when autopurging is not enabled.

          __________________________________________________________________

   6.5    The MCP QUEUE Commands

          MCP includes a suite of commands for queue management
          to be used by privileged users. These commands are
          documented in the MCP command dictionary.

          ___________________________

   6.5.1  Interpreting MCP QUEUE SHOW Output

          When there are messages in the queue, MCP QUEUE SHOW
          displays the following information about each entry:

              Entry Status  Size  Source  Agent  Entry Status  Size
              ----- ------ ------ ------ ------- ----- ------ ------
               2980 INPROG    229 LOCAL  <usr01@myhost.mycompany.com>
                                         SMTP     2981 READY     229
                                                 (waiting until 15-NOV-1991 15:07:21.75)
               9872 INPROG     34 JNET   <JUSER@SOMENODE.BITNET>
                                         LOCAL    9874 INPROG     34
              10859 READY   65120 LOCAL  <FileServ-Mgr@myhost.mycompany.com>
                    (Waiting until 15-NOV-1991 18:00:00.00)

          6-4

 


                                       Managing the Message Queue





          The fields of the display contain the following
          information:

          o  The first Entry field is the queue entry number for
             the base message, which can range from 1 to 131,071.

          o  The first Status field describes the status of
             the base message and can be one of INPROG, READY,
             FINISH, or CANCLD.

            o  INPROG stands for "in progress" and is used when
               the base entry is being processed by the Router,
               or when one of its related entries is ready or in
               progress.

            o  READY is used when the base entry is ready for
               processing by the Router.

            o  FINISH indicates that processing of the base
               entry has completed. Finished entries remain
               in the queue for a short time before being
               removed (see Table 6-1). They are not normally
               displayed; the /ALL qualifier on the MCP QUEUE
               SHOW command can be used to force the display of
               these entries.

            o  CANCLD indicates that processing of the entry is
               terminated before completion, such as when CTRL/C
               is pressed during entry of a message in VMS MAIL.
               Cancelled entries also remain in the queue for a
               short time before removal, and are only displayed
               when MCP QUEUE SHOW/ALL is used.

          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 Source field describes the origin of the base
             message. It can have the value LOCAL, JNET, SMTP,
             DNSMTP (for SMTP-over-DECnet), UUCP, SITE, or MAIL.
             To the right of the source display is the address of
             the user who originated the message.

                                                              6-5

 


          Managing the Message Queue





          If a message is being processed by one of the MX
          delivery agents, the base queue entry will be
          immediately followed by indented entries that begin
          with the Agent field. The Agent field identifies the
          delivery agent that is working on the entry. Possible
          values are LOCAL, LSV, SMTP, JNET, UUCP, SITE, and
          DNSMTP (for SMTP-over-DECnet).

          The second Entry, Status, and Size fields provide
          information about the queue entry used by the delivery
          agent. This agent-specific entry refers back to the
          base entry for the message headers and text, and
          the base entry has pointers to the agent-specific
          entries related to it. When an agent-specific entry
          is finished, the reference to it in the base entry is
          removed; when no agent-specific entries are left, the
          base entry is marked FINISHED.

          ___________________________

   6.5.2  Interpreting MCP QUEUE STATISTICS Output

          The MCP command QUEUE STATISTICS displays the
          following entry statistics:

              MCP> QUEUE STATISTICS
              Total entries: 16/502  (3%)   Highest entry used: 24  (4%)
              MCP>

          The first number after ``Total entries:'' is the
          current number of entries in the queue. The second
          number is the maximum number of entries allowed by
          the queue file size. The percentage of entries used is
          also shown.

          The ``Highest entry used:'' is the largest entry
          number ever used during the life of the queue file.
          The percentage of the queue in use at that time
          is also shown. This value can be used to determine
          whether or not the selected queue file size is
          sufficiently large. The MCP command QUEUE EXTEND can
          be used to increase the size of the queue file.

          6-6

 








          _______________________________________________________

   7      Other Miscellaneous Utilities



          This chapter describes other utilities available with
          MX.

          __________________________________________________________________

   7.1    The MLFAKE Utility

          For those times when you need to act on behalf of one
          of your users to sign off or subscribe to a mailing
          list, the MLFAKE utility may come in handy:

                            $ MLFAKE  :== $MX_EXE:MLFAKE
                            $ MLFAKE  listname  hostname  [command] [arguments]
                                /LISTSERV[=lsvname]
                                /REQUEST=reqaddress
                                /FROM=fromuser

          Specify the name of the mailing list and its host
          (with no @ in between). If you omit command, it
          defaults to SIGNOFF. If the command requires
          additional arguments, you should specify them after
          command (in which case you must specify the command).
          If the mailing list is managed by a BITNET LISTSERV,
          use the /LISTSERV qualifier; otherwise the request
          will go to the -Request address for the list (the
          Internet convention). You can override this altogether
          by specifying the request address with the /REQUEST
          qualifier. Finally, you must specify who the request
          is supposed to be from with the /FROM qualifier.

          For example:

              $ MLFAKE/FROM=someuser MX-List WKUVX1.WKU.EDU
              $ MLFAKE/FROM=someuser ESL-L UBVM.BITNET/LISTSERV
              $ MLFAKE/FROM=someuser/REQUEST="FileServ" -
              _$         "" WKUVX1.WKU.EDU SEND MX032.BLURB

                                                              7-1

 


          Other Miscellaneous Utilities





          The first example is for an Internet-type mailing
          list. The message will be constructed with "someuser"
          as the originator and MX-List-Request@vms.ecs.rpi.edu
          as the destination, with the message reading SIGNOFF.
          In the second example, for a BITNET mailing list, the
          destination will be LISTSERV@UBVM.BITNET, with the
          message reading SIGNOFF ESL-L. The third example shows
          how MLFAKE can be used with file servers by specifying
          the destination user with the /REQUEST qualifier and
          omitting the listname argument (which is ignored when
          /REQUEST is specified).

          MLFAKE requires SYSPRV privilege. SYSLCK privilege
          is not required, but will speed processing of the
          message. DO NOT install the MLFAKE image with these
          privileges! Only trusted users should have access
          to this utility, since it can be used to fake a mail
          message from any other user.

          __________________________________________________________________

   7.2    The MAILQUEUE Utility

          MAILQUEUE is a program that scans the message queue
          for entries still in progress. It can be used by non-
          privileged users to view only those entries which
          were sent by them. When used from an account with
          SYSPRV privilege turned on, it lists all pending 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

          If there are no delayed messages, MAILQUEUE returns
          the message

              %MAILQ-I-MQNONE, no MX mail messages queued on local system

          7-2

 


                                    Other Miscellaneous Utilities





          Otherwise, the MAILQUEUE display will resemble the
          following:

              Entry: 9872, Origin: [Jnet] <SOMEUSER@YOYODYNE.BITNET>
                Status: IN-PROGRESS
                Local entry #9874, status: READY
                    Waiting for retry until: 15-NOV-1991 16:46:44.12
                    Recipient #1: SOMEUSER, Route=myhost.mycompany.com
                    Error count=93
                    Last error: %MAIL-E-OPENOUT, error opening !AS as output

              Entry: 10859, Origin: [Local] <FileServ@myhost.mycompany.com>
                Status: READY, waiting until 15-NOV-1991 18:00:00.00
                  Recipient #1: <SOMEUSER%SOMEHOST.BITNET@myhost.mycompany.com>

          __________________________________________________________________

   7.3    The MX_DECODE Utility

          The MX_DECODE utility will decode MIME-compliant mail
          messages with contents specified as ``APPLICATION/VMS-
          RMS'' and encoded using BASE64 encoding. This
          is the format used by MX when the VMS Mail
          command SEND/FOREIGN is given. The MX Local agent
          automatically decodes such messages when they are
          received. MX_DECODE is provided for use with the MX
          Site agent, so that messages destined for MX Site may
          sent using SEND/FOREIGN.

          MX_DECODE should be executed using a foreign command:

              $ MX_DECODE :== $MX_EXE:MX_DECODE.EXE
              $ MX_DECODE MAIL_MESSAGE.BASE64 XYZ.xxx

          It accepts two required parameters: the input file and
          the output file. In order to decode the file properly,
          the input file must include the MIME RFC822 headers
          before the encoded body. The headers are used only
          to find the stored VMS file attributes. The resulting
          decoded output file will retain all of the VMS file
          attributes of the original file.

                                                              7-3

 








          _______________________________________________________

   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 message 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 stored in a directory tree under
          the MX_FLQ_DIR: directory. The files are named n.type,
          where n is the queue entry number and type is a file
          type indicating the type of information is in the
          file.

          There are ten subdirectories under the MX queue
          directory. The subdirectories are used to keep the
          size of the MX queue .DIR files below 128 blocks so
          that they can be cached by RMS. The subdirectory in
          which a file is located is determined by using the
          last digit in the file name as the subdirectory name
          ([.0], [.1], ..., [.9]).

          Most of the queued files used by MX (the INFO files)
          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

 


          Troubleshooting MX




          ___________________________

   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.

          SRC_INFO. This is the envelope information written
          on message entry. This file contains TLV records
          indicating the source of the message, the originating
          address, and the recipient addresses. Written by: MX_
          MAILSHR, DNSMTP_SERVER, XSMTP_SERVER, SMTP_SERVER, MX_
          JNET (incoming), MX_RMAIL, MX_SITE_IN. 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, DNSMTP_SERVER, XSMTP_SERVER, SMTP_SERVER, MX_
          JNET (incoming), MX_RMAIL, MX_SITE_IN. Read by: MX_
          LOCAL, MX_JNET (outgoing), MX_SMTP, MX_UUCP, MX_SITE,
          MX_MLF, MX_LSV, MX_DNSMTP, MX_XSMTP.

          MSG_TEXT. This file contains the text of the body of
          the message, in plain ASCII. Written on message entry
          by: MX_MAILSHR, DNSMTP_SERVER, XSMTP_SERVER, SMTP_
          SERVER, MX_JNET (incoming), MX_RMAIL, MX_SITE_IN. Read
          on message delivery by: MX_LOCAL, MX_JNET (outgoing),
          MX_SMTP, MX_UUCP, MX_SITE, MX_MLF, MX_LSV, MX_DNSMTP,
          MX_XSMTP.

          DNSMTP_INFO, JNET_INFO, LOCAL_INFO, SMTP_INFO, UUCP_
          INFO, SITE_INFO, MLF_INFO, XSMTP_INFO . These files
          contain envelope information used by the delivery
          agents. Written by: MX_ROUTER. Read by: MX_DNSMTP,
          MX_JNET, MX_LOCAL, MX_SMTP, MX_UUCP, MX_SITE, MX_MLF,
          MX_XSMTP (respectively).

          8-2

 


                                               Troubleshooting MX





          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 (base) 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
          are zeroed, the original queue entry is changed to
          FINISH 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, use the
          MCP command STATUS or examine the SHOW SYSTEM output
          for the following process names:

          MX Router      The Router

          MX FLQ         The MX queue manager
          Manager

          MX SMTP        SMTP delivery agent

          MX DNSMTP      SMTP-over-DECnet delivery agent

          MX XSMTP       SMTP-over-X.25 delivery agent

          SMTP Server    SMTP server

          MX Local       Local delivery agent

          MX Jnet        Jnet interface (delivery agent and
          Intfc          incoming message processor)

          MX LSV         Gateway to L-Soft's LISTSERV processor

                                                              8-3

 


          Troubleshooting MX






          MX MLF         Mailing list/file server

          MX Site        Site-specific interface agent
          Agent

          MX->SITE       Subprocess created by site interface

          MX uucp        UUCP interface
          Intfc

          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    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 the MX_
          MAILSHR/MX_MAILSHRP (the VMS MAIL interface), MX_
          MFSDISP (the Jnet mail/file dispatcher), or in MX_
          SITE_IN.

          8-4

 


                                               Troubleshooting MX





          Table_8-1__Debug/Trace_logical_names___________________

                                                               Default
                                                               di-
                                                               rec-
          Agent__________Enabling_logical___Trace_file_________tory

          Jnet intfc     MX_JNET_DEBUG      MX_JNET_LOG        MX_
                                                               JNET_
                                                               DIR:

          Local          MX_LOCAL_DEBUG     MX_LOCAL_LOG       MX_
                                                               LOCAL_
                                                               DIR:

          Local          MX_LSV_DEBUG       MX_LSV_LOG         MX_
                                                               LSV_
                                                               DIR:

          ML/FS          MX_MLF_DEBUG       MX_MLF_LOG         MX_
                                                               MLF_
                                                               DIR:

          RMAIL (UUCP    MX_UUCP_RMAIL_     MX_RMAIL_LOG       MX_
          in)            DEBUG                                 UUCP_
                                                               DIR:

          Router         MX_ROUTER_DEBUG    MX_ROUTER_LOG      MX_
                                                               ROUTER_
                                                               DIR:

          Router/file    MX_FLQ_DEBUG       MX_FLQ_LOG         MX_
          queue                                                ROUTER_
                                                               DIR:

          SMTP out       MX_SMTP_DEBUG      MX_SMTP_LOG        MX_
                                                               SMTP_
                                                               DIR:

          SMTP server    MX_SMTP_SERVER_    SMTP_SERVER_LOG    MX_
                         DEBUG                                 SMTP_
                                                               DIR:

                                                              8-5

 


          Troubleshooting MX





          Table_8-1_(Cont.)__Debug/Trace_logical_names___________

                                                               Default
                                                               di-
                                                               rec-
          Agent__________Enabling_logical___Trace_file_________tory

          SMTP-over-     MX_DNSMTP_DEBUG    MX_DNSMTP_LOG      MX_
          DECnet out                                           DNSMTP_
                                                               DIR:

          SMTP-over-     MX_DNSMTP_SERVER_  DNSMTP_SERVER_LOG  MX_
          DECnet         DEBUG                                 DNSMTP_
          server                                               DIR:

          SMTP-over-     MX_XSMTP_DEBUG     MX_XSMTP_LOG       MX_
          X.25 out                                             XSMTP_
                                                               DIR:

          SMTP-over-     MX_XSMTP_SERVER_   XSMTP_SERVER_LOG   MX_
          X.25 server    DEBUG                                 XSMTP_
                                                               DIR:

          Site Agent     MX_SITE_DEBUG      MX_SITE_LOG        MX_
                                                               SITE_
                                                               DIR:

          UUCP intfc     MX_UUCP_DEBUG      MX_UUCP_LOG        MX_
                                                               UUCP_
          _____________________________________________________DIR:










          8-6

 








          _______________________________________________________

   9      The MX Startup Process



          This chapter describes the command procedures and
          files used by MX when it is started.

          __________________________________________________________________

   9.1    Startup Command Procedures

          Typically, MX is started up by executing the command
          procedure SYS$STARTUP:MX_STARTUP.COM. This file is
          created at installation time simply to make MX easy to
          start; all it does is execute MX___STARTUP.COM,  which
          is located in the directory that eventually becomes
          the equivalence name for the logical name MX_EXE.
          MX___STARTUP.COM  contains the commands for setting
          up the MX logical names and invoking MX_START.COM,
          also located in the MX_EXE directory, to start the MX
          processing agents.

          Individual MX components can be started by passing
          their names (one or more, separated with commas
          and with no intervening blanks) as arguments to
          SYS$STARTUP:MX_STARTUP.COM. Table 9-1 lists the
          components that the startup command procedures
          recognize.

          Table_9-1__Component_names_for_use_with_MX_STARTUP.COM_

          Name___________Description_____________________________

          LOGICALS       Defines MX logical names and installs
                         the MX shareable libraries.



                                                              9-1

 


          The MX Startup Process





          Table 9-1 (Cont.)  Component names for use with MX_
          ___________________STARTUP.COM_________________________

          Name___________Description_____________________________

          NETLIB         Executes NETLIB's startup command
                         procedure. (Prerequisite for ROUTER,
                         SMTP, and SMTP_SERVER if using TCP/IP
                         with MX.)

          ROUTER         Starts the Router process.

          LOCAL          Starts the local delivery agent.

          SMTP           Starts the SMTP-over-TCP/IP delivery
                         agent.

          SMTP_SERVER    Starts the SMTP server (for TCP/IP).

          DNSMTP         Starts the SMTP-over-DECnet delivery
                         agent.

          XSMTP          Starts the SMTP-over-X.25 delivery
                         agent.

          JNET           Starts the Jnet Interface.

          UUCP           Starts the UUCP delivery agent.

          SITE           Starts the SITE interface.

          MLF            Starts the mailing list/file server.

          LSV            Starts the gateway to L-Soft's
          _______________LISTSERV._______________________________

          __________________________________________________________________

   9.2    Startup Data Files

          MX___STARTUP.COM  uses two data files, both located
          in the MX root directory (MX_DIR:). MX_LOGICALS.DAT
          contains logical name definitions, some of which can
          be customized or altered after MX is installed. MX_
          STARTUP_INFO.DAT contains information on which of the
          MX components are installed, and on which nodes they
          should be run.

          9-2

 


                                           The MX Startup Process




          ___________________________

   9.2.1  MX_LOGICALS.DAT

          The file MX_LOGICALS.DAT is a plain text file that
          contains information used by MX___STARTUP.COM  to
          create logical name definitions. The format of a
          record in MX_LOGICALS.DAT is:

                           logical-name\qualifiers\equiv-name

          For example:

              MX_FLQ_NODE_NAME\/SYSTEM/EXEC\MYNODE

          This file is created when MX is installed and can be
          updated by the installation procedure if an optional
          component is added after the initial installation of
          MX. Extreme caution should be exercised when making
          any manual changes to this file.

          ___________________________

   9.2.2  MX_STARTUP_INFO.DAT

          The file MX_STARTUP_INFO.DAT is a plain text file
          that contains information used by MX___STARTUP.COM  to
          determine, based on the SCSNODE name of the system,
          which MX components should be started. The file is
          also used by MXCONFIG.COM and the MX installation
          procedure to determine which MX optional components
          have been installed.

          Each record in this file is of the form:

                           nnncomponent:node[=count][,...]

          For example, a typical MX_STARTUP_INFO.DAT would look
          like:

              001NETLIB:*
              002ROUTER:NODE01,NODE02
              003LOCAL:NODE02
              004SMTP:NODE01=4,NODE02=2
              004SMTP_SERVER:NODE01

                                                              9-3

 


          The MX Startup Process





          Each line begins with a three-digit number, noted
          as nnn above. The order of the lines in this file is
          signficant, because some MX components are dependent
          on others, and hence must be started in a particular
          order. The MX installation procedure uses the SORT
          command to sort MX_STARTUP_INFO.DAT after it installs
          a component; the leading three-digit number on each
          line then determines its place in the file.

          The component portion of the record is the name of one
          of the MX components, listed in Table 9-1. Following
          the component name is a colon. To the right of the
          colon is either an asterisk ("*") or, for a VMScluster
          environment, a list of one or more SCSNODE names on
          which the component should be started.

          Multiple Instances of Components

          Each nodename may optionally be followed by an equals
          sign ("=") and a number, greater than 1, indicating
          how many instances of the component should be started.
          The components that support multiple instances per
          node are ROUTER, LOCAL, SMTP, DNSMTP, JNET, UUCP,
          and SITE. This feature can be particularly useful for
          busy systems, especially those using SMTP (since SMTP
          transactions can take a long time). For example, the
          line

              004SMTP:NODE01=4,NODE02=2

          Indicates that four instances of the SMTP delivery
          agent should be started on the system named NODE01,
          and two instances should be started on NODE02.

          As with MX_LOGICALS.DAT, extreme caution should
          be exercised when attempting to modify MX_STARTUP_
          INFO.DAT by hand. Make sure that there are no blanks
          on any line in the file, and test your changes
          thoroughly to ensure that you have not broken the
          startup process.

          9-4

 


                                           The MX Startup Process




          __________________________________________________________________

   9.3    Typical MX_STARTUP_INFO Modifications

          While there is generally no reason to modify the MX_
          LOGICALS.DAT file, there are a few reasons why you
          might wish to modify MX_STARTUP_INFO.DAT:

          1  If you change the SCS node name of one of the nodes
             in your VMScluster, or you add or remove a node,
             you might want to edit the file to reflect those
             changes.

          2  When NETLIB is installed, it is setup with an
             asterisk for the node specification, so it gets
             started on all nodes in your cluster. This is not
             harmful, even on nodes that are not running any
             TCP/IP package, and merely results in the use of a
             few extra global pages and global sections. However,
             if you want to restrict the NETLIB startup to only
             a few nodes, you can replace the asterisk on the
             startup line for NETLIB with the names of those
             nodes (separated by commas).

          3  To have multiple instances of an MX component get
             started automatically when MX is started, you can
             alter the node specifications to add the number of
             desired instances for each node.

          Remember to use caution when modifying MX_STARTUP_
          INFO.DAT, and keep a copy of the original version to
          use in case your modifications do not work.









                                                              9-5

 







          _______________________________________________________

          MCP Command Dictionary

 


                                                     MCP Commands
                                                              MCP




          _______________________________________________________

          MCP

          Executes the MX Control Program.

          _______________________________________________________

          FORMAT

          MCP  [command]

          _______________________________________________________
          Command Qualifiers     Defaults

          /[NO]FILE=file-spec    /FILE=MX_DIR:MX_CONFIG.MXCFG

          _______________________________________________________

          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.

          By default, MCP loads in the current configuration
          file, MX_DIR:MX_CONFIG.MXCFG, when started.

                                                            MCP-3

 


          MCP Commands
          MCP



          _______________________________________________________

          QUALIFIERS
          /[NO]FILE=file-spec
          Loads the specified MX configuration file for
          editing. If not specified, MX_DIR:MX_CONFIG.MXCFG is
          loaded. The default file type is MXCFG. If /NOFILE
          is specified, MCP is started without loading any
          configuration information.
































          MCP-4

 


                                                     MCP Commands
                                        @ (Redirect Command 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 forwarding 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_SERVER




          _______________________________________________________

          DEFINE FILE_SERVER

          Creates a file server.

          _______________________________________________________

          FORMAT

          DEFINE FILE_SERVER  name

          _______________________________________________________
          Command Qualifiers     Defaults

          /BEGIN_SEND_PERIOD=hh:mm
          /[NO]DELAY_THRESHOLD=size
          /[NO]DESCRIPTION=text  /NODESCRIPTION
          /END_SEND_PERIOD=hh:mm
          /[NO]HOST_LIMIT=hostlim
          /[NO]MAILING_LIST=listname
          /MANAGER=address
          /ROOT=rootspec
          /[NO]SERVER_LIMIT=servlim
          /[NO]USER_LIMIT=userlim

          _______________________________________________________

          PARAMETERS
          name
          Local name to be used for the file server, up to 32
          characters in length.

          _______________________________________________________

          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

                                                            MCP-7

 


          MCP Commands
          DEFINE FILE_SERVER




          server username. The commands the file server responds
          to are HELP, LIST, SENDME, QUIT, and ADDRESS.

          The root you specify with /ROOT qualifier is used
          by the file server software to locate packages. Each
          package must have a directory [package-name] under
          that root 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 package-name.DESCRIPTION in the
          top-level root directory that contains a description
          of the package and the files in the package.

          The .DESCRIPTION files may be placed in the package
          subdirectories, if desired, but they cannot exist in
          both the root and the subdirectories.

          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 FILESERV_HELP.TXT from the top-level root
          directory to the requesting user. A sample help file
          is provided with MX, which the system manager can
          modify to provide site-specific information.

          The QUIT command causes the file server to ignore
          any remaining lines in the message. It can be used to
          prevent the unintentional parsing of mail signatures.

          The ADDRESS command takes a valid RFC822-compliant
          address. It causes all file server replies to be
          redirected to the given address instead of the Reply-
          To or From addresses.

          MCP-8

 


                                                     MCP Commands
                                               DEFINE FILE_SERVER



          _______________________________________________________

          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. Defaults to 17:00.

          /[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.

          /[NO]DESCRIPTION=text
          This qualifier defines a brief description for the
          file server. This description is added to the file
          server address in the X-FileServer header on outgoing
          server messages.

          /END_SEND_PERIOD=hh:mm
          Identifies the time of day when the file server should
          stop sending files that exceed the delay threshold
          size. Defaults to 09:00.

          /[NO]HOST_LIMIT=hostlim
          Specifies that a maximum of hostlim bytes may be sent
          per day to any single host.

          /[NO]MAILING_LIST=list-name
          Specifies a mailing list to be linked to the file
          server. Only those users who are subscribed to the
          specified list may have access to the file server. The
          specified list must exist on the local system in order
          for this qualifier to have any effect.

          /MANAGER=address
          When establishing a file server, you can provide an E-
          mail address to which all error messages and mail that
          bounces back to the file server can be forwarded. The

                                                            MCP-9

 


          MCP Commands
          DEFINE FILE_SERVER




          local alias name-Mgr will be created to direct those
          error messages to the /MANAGER address. If you omit
          the /MANAGER qualifier, bounced mail will be directed
          to the Postmaster.

          /ROOT=rootspec
          You must specify a location (either a rooted logical
          or a device plus root directory specification) to
          be used as the root for the file server files and
          directories. Examples of valid roots are FILESERV_
          ROOT: (if it is defined as a rooted logical) and
          DISK:[FILE_SERVER.] (note the final dot before the
          bracket, indicating it is a root specification).

          /[NO]SERVER_LIMIT=servlim
          Specifies that a maximum of servlim bytes may be sent
          per day from the server.

          /[NO]USER_LIMIT=userlim
          Specifies that a maximum of userlim bytes may be sent
          per day to any one user.



















          MCP-10

 


                                                     MCP Commands
                                                      DEFINE LIST




          _______________________________________________________

          DEFINE LIST

          Creates a mailing list.

          _______________________________________________________

          FORMAT

          DEFINE LIST  list-name

          _______________________________________________________
          Command Qualifiers          Defaults

          /[NO]ADD_MESSAGE=fspec      /NOADD_MESSAGE
          /[NO]ARCHIVE=fspec          /NOARCHIVE
          /[NO]CASE_SENSITIVE         /CASE_SENSITIVE
          /[NO]DESCRIPTION=text       /NODESCRIPTION
          /|NO]DIGEST                 /NODIGEST
          /ERRORS_TO=address          See text
          /[NO]FORWARD_MESSAGE=fspec  /NOFORWARD_MESSAGE
          /[NO]MODERATOR=(address[,.../NOMODERATOR
          /OWNER=(address[,...])
          /PRIVATE                    /NOPRIVATE
          /PROTECTION=prot-spec       See text
          /[NO]REMOVE_MESSAGE=fspec   /NOREMOVE_MESSAGE
          /REPLY_TO=(kwd[,...])       /REPLY_TO=SENDER
          /[NO]RETURN_ADDRESS=addressSee  text
          /STRIP_HEADERS=keyword      See text

          _______________________________________________________

          PARAMETERS
          list-name
          Local name to be used for the mailing list, up to 32
          characters in length.



                                                           MCP-11

 


          MCP Commands
          DEFINE LIST



          _______________________________________________________

          DESCRIPTION
          This command is used to establish a mailing list. 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.

          Mailing lists are fully described in Message Exchange
          Mailing List/File Server Guide.

          _______________________________________________________

          QUALIFIERS
          /[NO]ADD_MESSAGE=fspec
          Specifies the name of a file to be sent to a
          user subscribing to the list. If omitted, the
          device and directory default to MX_MLIST_DIR: (MX_
          ROOT:[MLF.MAILING_LISTS]), and the file type defaults
          to TXT.

          The default for this qualifier is /NOADD_MESSAGE,
          which causes the global add message, MX_MLIST_
          DIR:MLIST_ADD_MESSAGE.TXT, to be sent when a user
          subscribes to the list. See Message Exchange Mailing
          List/File Server Guide for more information about
          notification messages.

          /[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.

          MCP-12

 


                                                     MCP Commands
                                                      DEFINE LIST




          /[NO]CASE_SENSITIVE
          This qualifier enables or disables case-sensitivity
          with regard to mailing list subscribers. By default,
          MX treats the left-hand side of subscriber addresses
          in a case-sensitive manner with regard to SIGNOFF and
          SET commands. If a list is defined /NOCASE_SENSITIVE,
          then the case of subscriber addresses will be ignored.

          /[NO]DESCRIPTION=text
          This qualifier defines a brief description for
          the mailing list. This description is added to the
          mailing list address in the X-ListName header on list
          m|ssages.
           |
          /|NO]DIGEST
          T|is qualifier enable or disables digest support for
          t|e list. A list marked /DIGEST can support the DIGEST
          f|ag for subscribers. Mail sent to the "-digest" form
          o| the list address will be forwarded only to those
          s|bscribers marked as digest subscribers.

          /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
          the the first specified owner of the mailing list is
          used.

          /[NO]FORWARD_MESSAGE=fspec
          Specifies the name of a file to be sent to a user
          subscribing to the list when the list does not have
          W:E access set. The message should notify the user
          that the subscription request was forwarded to the
          list owner. If omitted, the device and directory
          default to MX_MLIST_DIR: (MX_ROOT:[MLF.MAILING_
          LISTS]), and the file type defaults to TXT.




                                                           MCP-13

 


          MCP Commands
          DEFINE LIST




          The default for this qualifier is /NOFORWARD_MESSAGE,
          which causes the global forward-to-owner message, MX_
          MLIST_DIR:MLIST_FORWARD_MESSAGE.TXT, to be sent when a
          user tries to subscribe. See Message Exchange Mailing
          List/File Server Guide for more information about
          notification messages.

          /[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.

          /[NO]PRIVATE
          This qualifier specifies that the list is private
          and should not be displayed in response to DIRECTORY
          commands sent to the MXserver or -Request addresses.
          The list protection is not affected by this qualifier.

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







          MCP-14

 


                                                     MCP Commands
                                                      DEFINE LIST




          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

          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          allows the user to post messages to the list
          (Write)

          E          allows the automatic handling of the
          (Enroll)   SUBSCRIBE command

          D          allows the automatic handling of the SIGNOFF
          (Delete)___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.

                                                           MCP-15

 


          MCP Commands
          DEFINE LIST




          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.

          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.

          /[NO]REMOVE_MESSAGE=fspec
          Specifies the name of a file to be sent to a user
          signing off the list. If omitted, the device
          and directory default to MX_MLIST_DIR: (MX_
          ROOT:[MLF.MAILING_LISTS]), and the file type defaults
          to TXT.

          The default for this qualifier is /NOREMOVE_MESSAGE,
          which causes the global remove message, MX_MLIST_
          DIR:MLIST_ADD_MESSAGE.TXT, to be sent when a user
          signs off the list. See Message Exchange Mailing

          MCP-16

 


                                                     MCP Commands
                                                      DEFINE LIST




          List/File Server Guide for more information about
          notification messages.

          /REPLY_TO=(kwd[,...])
          Specifies how the mailing list processor should handle
          Reply-To headers. Available reply-to types are SENDER
          and LIST, which may be combined. The default is
          SENDER, which prevents the mailing list processor
          from modifying the headers. If LIST is specified,
          a Reply-To header is added to list messages to re-
          direct replies to the mailing list, eliminating any
          existing Reply-To header in the original message. If
          LIST and SENDER are both specified, a Reply-To header
          containing both the mailing list address and the
          original Reply-To address is added to list messages
          (using the From address if no Reply-To header existed
          in the original message).

          The /RETURN_ADDRESS=address qualifier can be used to
          supply an alternate list return address when /REPLY_
          TO=LIST is specified.

          /[NO]RETURN_ADDRESS=address
          This qualifier is used to specify an alternate address
          to be used as the ``Reply-To:'' address when /REPLY_
          TO=LIST is specified. This qualifier is most useful
          when multiple lists should have a common return
          address. For example, it can be used to redirect
          replies to a ``-Digest'' list back to the non-digest
          address.

          /STRIP_HEADERS=keyword
          This qualifier is used to strip certain RFC822 headers
          from messages posted to a mailing list.

          The following keywords are supported:

          o  RECEIVED and NORECEIVED


                                                           MCP-17

 


          MCP Commands
          DEFINE LIST




          o  OTHER and NOOTHER

          When /STRIP_HEADERS=RECEIVED is set, the ``Received:''
          headers are stripped from the incoming message before
          it is mailed out to the list subscribers, thereby
          reducing the total number of ``Received:'' headers in
          the final message. This is especially beneficial to
          BITNET hosts because there can be a substantial number
          of ``Received:'' headers added to a message that must
          pass through one or more Internet/BITNET gateways.

          When /STRIP_HEADERS=OTHER is set, all ``other''
          headers are stripped from posts. The ``other''
          headers are any headers not recognized by MX, which
          includes such headers as X- headers, return-receipt
          headers, X.400 headers, etc. Setting a list to /STRIP_
          HEADERS=OTHER handily gets around potential problems
          with subscribers using the DOS package Pegasus Mail,
          which will send message receipt messages back to
          a list. Note that this may not be a viable setting
          for a mailing list that is gatewayed to a newsgroup,
          depending on the gateway software, since headers used
          by the gateway may be omitted.

















          MCP-18

 


                                                     MCP Commands
                                                      DEFINE PATH




          _______________________________________________________

          DEFINE PATH

          Defines a mapping between a domain name and a
          distribution path.

          _______________________________________________________

          FORMAT

          DEFINE PATH  domain-name path-name

          _______________________________________________________
          Command Qualifiers     Defaults

          /ROUTE=host-name

          _______________________________________________________

          PARAMETERS
          domain-name
          A domain name or pattern containing VMS wildcards.

          path-name
          One of the supported MX path names: LOCAL, SMTP, JNET,
          SITE, DECNET_SMTP, X25_SMTP, 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 list. The list is
          automatically sorted based on the length of the path
          and the presence of wildcards. The Router searches
          this list until the domain name of the address it is
          trying to route to matches the domain name or wildcard
          pattern of the path definition.

                                                           MCP-19

 


          MCP Commands
          DEFINE PATH



          _______________________________________________________

          QUALIFIERS
          /ROUTE=host-name
          Specifies the name of a host that will route messages
          for the specified domain.



































          MCP-20

 


                                                     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 transformation apply. For example:

              MCP> DEFINE REWRITE_RULE "<{user}@{host}.DECnet.mycompany.com>" -
              _MCP>                     "<""{host}::{user}""@myhost.mycompany.org>"

          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

                                                           MCP-21

 


          MCP Commands
          DEFINE REWRITE_RULE




          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 can be used when the DEFINE PATH/ROUTE
          command is inadequate, such as when a message must
          pass through two or more gateways to get to its
          destination, or when the rewrite affects both the
          local-part and the domain-part of an address. 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-22

 


                                                     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 also given CONTROL access to
          all mailing lists. They receive all messages sent to
          MXserver that cannot be handled automatically by the
          mailing list processor.

          The first address on the SYSTEM_USER list is used as
          the return address for generic MXserver replies (those
          replies that are not about a specific mailing list).
          For this reason, you may want to specify an alias as
          the first system user.

                                                           MCP-23

 


          MCP Commands
          DEFINE SYSTEM_USERS




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


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


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


                                                     MCP Commands
                                                           MODIFY




          _______________________________________________________

          MODIFY

          Modifies existing configuration information.

          _______________________________________________________

          FORMAT
                  { ALIAS alias new-fwdaddr         }
                  { FILE_SERVER fsrv-name           }
          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-27

 


          MCP Commands
          QUEUE CANCEL




          _______________________________________________________

          QUEUE CANCEL

          Cancels a queue entry.

          _______________________________________________________

          FORMAT

          QUEUE CANCEL  entry-number[,...]

          _______________________________________________________
          Command Qualifiers     Defaults

          /[NO]LOG               /NOLOG

          _______________________________________________________

          PARAMETERS
          entry-number
          Queue entry number to be cancelled. If the number of a
          base queue entry, all related agent-specific entries
          will also be cancelled.

          _______________________________________________________

          DESCRIPTION
          This command sets the status of the specified
          queue entries to CANCELLED, which prevents further
          processing of the entries. This should only be done on
          entries which are not currently being processed by the
          Router or one of the delivery agents.

          _______________________________________________________

          QUALIFIERS
          /[NO]LOG
          Causes a message to be displayed for each cancelled
          entry. The default is /NOLOG.

          MCP-28

 


                                                     MCP Commands
                                                   QUEUE COMPRESS




          _______________________________________________________

          QUEUE COMPRESS

          Compress the message queue file.

          _______________________________________________________

          FORMAT

          QUEUE COMPRESS

          _______________________________________________________
          Command Qualifiers     Defaults

          /MAXIMUM_ENTRIES=valueNone.
          /[NO]LOG               /NOLOG

          _______________________________________________________

          DESCRIPTION
          Shrinks the message queue file by creating a new file
          and renumbering all the existing entries in the file.
          This command may be used to create a smaller message
          queue, which affects the maximum number of entries
          allowed in the queue.

          The /MAXIMUM_ENTRIES qualifier is required.

          This command requires exclusive access to the MX
          message queue file. Before compressing the file, all
          MX agents must either be shut down or inactive.

          _______________________________________________________

          QUALIFIERS
          /MAXIMUM_ENTRIES=number-of-entries
          Specifies the maximum number of queue entries to be
          allowed. MX will not allow more entries to be added to
          the queue than the specified value. MCP QUEUE EXTEND
          can be used to increase the number of allowed entries.

          The size of the queue file in blocks is equal to
          the maximum number of entries, plus 10 blocks, plus
          whatever is added for the disk cluster.

                                                           MCP-29

 


          MCP Commands
          QUEUE COMPRESS




          /[NO]LOG
          Causes a status message to be displayed after
          successful operation. Default is /NOLOG.





































          MCP-30

 


                                                     MCP Commands
                                                     QUEUE CREATE




          _______________________________________________________

          QUEUE CREATE

          Create a message queue file.

          _______________________________________________________

          FORMAT

          QUEUE CREATE

          _______________________________________________________
          Command Qualifiers     Defaults

          /MAXIMUM_ENTRIES=valueNone.

          _______________________________________________________

          DESCRIPTION
          Creates a new, empty MX message queue file. The
          /MAXIMUM_ENTRIES qualifier is required.

          Note: This command simply creates a new queue file; the
          existing queue file is not automatically deleted. Any
          files for any existing queue entries are also left in
          place.

          This command requires exclusive access to the MX
          message queue file. Before compressing the file, all
          MX agents must either be shut down or inactive.

          _______________________________________________________

          QUALIFIERS
          /MAXIMUM_ENTRIES=number-of-entries
          Specifies the maximum number of queue entries to be
          allowed. MX will not allow more entries to be added to
          the queue than the specified value. MCP QUEUE EXTEND
          can be used to increase the number of allowed entries.

          The size of the queue file in blocks is equal to
          the maximum number of entries, plus 10 blocks, plus
          whatever is added for the disk cluster.

                                                           MCP-31

 


          MCP Commands
          QUEUE EXTEND




          _______________________________________________________

          QUEUE EXTEND

          Extends the message queue file.

          _______________________________________________________

          FORMAT

          QUEUE EXTEND

          _______________________________________________________
          Command Qualifiers     Defaults

          /MAXIMUM_ENTRIES=valueNone.

          _______________________________________________________

          DESCRIPTION
          Extends the existing message queue file to allow more
          entries to be in the queue at any given time.

          The /MAXIMUM_ENTRIES qualifier is required.

          This command requires exclusive access to the MX
          message queue file. Before compressing the file, all
          MX agents must either be shut down or inactive.

          _______________________________________________________

          QUALIFIERS
          /MAXIMUM_ENTRIES=number-of-entries
          Specifies the maximum number of queue entries to be
          allowed. MX will not allow more entries to be added to
          the queue than the specified value. MCP QUEUE EXTEND
          can be used to increase the number of allowed entries.

          The size of the queue file in blocks is equal to
          the maximum number of entries, plus 10 blocks, plus
          whatever is added for the disk cluster.

          MCP-32

 


                                                     MCP Commands
                                                      QUEUE PURGE




          _______________________________________________________

          QUEUE PURGE

          Purges the message queue of finished and cancelled
          entries.

          _______________________________________________________

          FORMAT

          QUEUE PURGE

          _______________________________________________________
          Command Qualifiers     Defaults

          /[NO]LOG               /NOLOG

          _______________________________________________________

          DESCRIPTION
          This command searches the message queue for all
          entries of FINISH or CANCELLED status and deletes them
          from the queue.

          _______________________________________________________

          QUALIFIERS
          /[NO]LOG
          Causes a message to be displayed for each deleted
          entry. The default is /NOLOG.









                                                           MCP-33

 


          MCP Commands
          QUEUE READY




          _______________________________________________________

          QUEUE READY

          Readies a queue entry.

          _______________________________________________________

          FORMAT

          QUEUE READY  entry-number[,...]

          _______________________________________________________
          Command Qualifiers     Defaults

          /[NO]LOG               /NOLOG

          _______________________________________________________

          PARAMETERS
          entry-number
          Queue entry number to be readied. If the number of a
          base queue entry, the base entry will be readied and
          all existing agent-specific entries will be cancelled.

          _______________________________________________________

          DESCRIPTION
          This command sets the status of the specified queue
          entries to READY and clears the delay flag. This
          should only be done on entries which are not currently
          being processed by the Router or one of the delivery
          agents.

          _______________________________________________________

          QUALIFIERS
          /[NO]LOG
          Causes a message to be displayed for each readied
          entry. The default is /NOLOG.

          MCP-34

 


                                                     MCP Commands
                                                       QUEUE SHOW




          _______________________________________________________

          QUEUE SHOW

          Displays queue entries.

          _______________________________________________________

          FORMAT

          QUEUE SHOW  [entry-number,...]

          _______________________________________________________
          Command Qualifiers     Defaults

          /ALL
          /BEFORE=time
          /BRIEF
          /CREATED
          /DATE
          /DELAY
          /DESTINATION_AGENT=agent
          /EXPIRE
          /FULL
          /IN_PROGRESS
          /MODIFIED
          /ORIGIN_AGENT=agent
          /OUTPUT=file-spec
          /SINCE=time
          /WAITING

          _______________________________________________________

          PARAMETERS
          entry-number
          Queue entry number to be displayed. If omitted, all
          READY and IN-PROGRESS entries are displayed.



                                                           MCP-35

 


          MCP Commands
          QUEUE SHOW



          _______________________________________________________

          DESCRIPTION
          This command displays entries in the message queue.

          _______________________________________________________

          QUALIFIERS
          /ALL
          Causes all queue entries to be displayed, regardless
          of status. If omitted, just the READY and IN-PROGRESS
          entries are displayed.

          /BEFORE[=time]
          Selects only those entries dated before the specified
          time. You can specify time as an absolute time, a
          combination of absolute and delta times, or as one of
          the following keywords: TODAY (default), TOMORROW, or
          YESTERDAY. Specify one of the following qualifiers
          with the /BEFORE qualifier to indicate the time
          attribute to be used as the basis for selection:
          /CREATED (default), /DELAY, /EXPIRE, or /MODIFIED.

          /BRIEF
          Causes a brief listing of all the queue entries to
          be displayed, including those that have finished or
          been cancelled. The information displayed is taken
          only from the MX queue file and includes the target MX
          process for each entry.

          /CREATED
          Modifies the time value specified with the /BEFORE or
          the /SINCE qualifier. The /CREATED qualifier selects
          entries based on their dates of creation.

          /DATE
          Causes the creation and modification dates to be
          displayed for each queue entry.



          MCP-36

 


                                                     MCP Commands
                                                       QUEUE SHOW




          /DELAY
          Modifies the time value specified with the /BEFORE
          or the /SINCE qualifier. The /DELAY qualifier selects
          entries based on their delay dates.

          /DESTINATION_AGENT=agent
          Selects only those entries that are to be or have been
          processed by the specified MX agent. Valid keywords
          are: ROUTER, MLF, LOCAL, SMTP, SITE, LSV, JNET, UUCP,
          DNSMTP, and XSMTP. This qualifier is most useful when
          used with /BRIEF.

          /EXPIRE
          Modifies the time value specified with the /BEFORE or
          the /SINCE qualifier. The /EXPIRE qualifier selects
          entries based on their dates of expiration.

          /FULL
          Provides more details about the displayed entries,
          including intended recipients, error counts, and last
          error status messages. If omitted, a brief, one-line
          display is produced for each entry.

          /IN_PROGRESS
          Displays only entries marked as being in-progress
          (INPROG).

          /MODIFIED
          Modifies the time value specified with the /BEFORE or
          the /SINCE qualifier. The /MODIFIED qualifier selects
          entries based on their dates of modification.

          /ORIGIN_AGENT=agent
          Selects only those entries that were entered into the
          queue by the specified MX agent. Valid keywords are:
          LOCAL, SMTP, JNET, UUCP, SITE, MAIL, DNSMTP, XSMTP,
          and BSMTP.

          /OUTPUT=file-spec
          Directs the results to the specified file. If omitted,
          the results are displayed on SYS$OUTPUT.

                                                           MCP-37

 


          MCP Commands
          QUEUE SHOW




          /SINCE[=time]
          Selects only those entries dated after the specified
          time. You can specify time as an absolute time,
          a combination of absolute and delta times, or as
          one of the following keywords: TODAY (default),
          TOMORROW, or YESTERDAY. Specify one of the following
          qualifiers with the /SINCE qualifier to indicate the
          time attribute to be used as the basis for selection:
          /CREATED (default), /DELAY, /EXPIRE, or /MODIFIED.

          /WAITING
          Limits the display to only those entries with READY
          status.



























          MCP-38

 


                                                     MCP Commands
                                                 QUEUE STATISTICS




          _______________________________________________________

          QUEUE STATISTICS

          Displays statistical information concerning the
          entries in the MX message queue.

          _______________________________________________________

          FORMAT

          QUEUE STATISTICS

          _______________________________________________________

          DESCRIPTION
          This command displays the total number of entries in
          the queue, the maximum number of entries possible for
          the queue file, the percentage of entries in use, and
          the largest entry number ever used during the life of
          the file.



















                                                           MCP-39

 


          MCP Commands
          QUEUE SYNCHRONIZE




          _______________________________________________________

          QUEUE SYNCHRONIZE

          Synchronizes the message queue bitmap with the actual
          entries in the queue.

          _______________________________________________________

          FORMAT

          QUEUE SYNCHRONIZE

          _______________________________________________________
          Command Qualifiers     Defaults

          /LOG
          /RESET

          _______________________________________________________

          DESCRIPTION
          This command updates the bitmap for the MX system
          message queue to synchronize it with the actual
          entries in the queue. The only time this command may
          be necessary is in the event of a system crash or disk
          failure.

          The command may be issued at any time; it does not
          require exclusive access to the MX message queue file.

          _______________________________________________________

          QUALIFIERS
          /LOG
          Causes a status message to be displayed after
          successful operation. Default is /NOLOG.

          /RESET
          Resets the ``Highest entry used'' counter displayed
          by QUEUE STATISTICS. By default, the counter is not
          reset.

          MCP-40

 


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


          MCP Commands
          REMOVE




          _______________________________________________________

          REMOVE

          Removes a configuration record.

          _______________________________________________________

          FORMAT
                  { ALIAS alias               }
                  { FILE_SERVER fileserv-name }
          REMOVE  { LIST list-name            }
                  { 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-42

 


                                                     MCP Commands
                                                            RESET




          _______________________________________________________

          RESET

          Sends a reset signal to one or more delivery agents.

          _______________________________________________________

          FORMAT

          RESET  [agent-name...]

          _______________________________________________________
          Command Qualifiers     Defaults

          /ACCOUNTING
          /CLUSTER
          /|ODE=(node[,...])

          _______________________________________________________

          PARAMETERS
          agent-name...
          One or more MX delivery agent names, separated by
          commas. Valid names are DECNET_SMTP, JNET, LOCAL,
          LSV, MLF, ROUTER, SITE, SMTP, UUCP, and X25_SMTP. If
          omitted, all agents running on the same node as the
          user executing this command are reset.

          _______________________________________________________

          DESCRIPTION
          The RESET command can be used to signal one or more
          MX delivery agents to reload their configuration
          information. This command requires the SYSLCK
          privilege.

          _______________________________________________________

          QUALIFIERS
          /ACCOUNTING
          Causes the specified agents to open new versions of
          their accounting files. Only useful for those agents

                                                           MCP-43

 


          MCP Commands
          RESET




          that support accounting, and with MLF (which causes a
          new version of FILESERV_LOG.LOG to be opened).

          If /ACCOUNTING is specified, no reload of
          configuration data is performed; only the accounting
          files are reset.

          /CLUSTER
          Specifies that the RESET command should affect all
          of the specified agents cluster-wide, rather than
          just the ones on the node from which the command is
          e|ecuted.
           |
          /|ODE=(node[,...])
          S|ecifies that the RESET command should affect only
          t|e specified agents running on the given nodes.
























          MCP-44

 


                                                     MCP Commands
                                                           REVIEW




          _______________________________________________________

          REVIEW

          Displays the subscribers of a local mailing list.

          _______________________________________________________

          FORMAT

          REVIEW  mailing-list

          _______________________________________________________
          Command Qualifiers     Defaults

          /OUTPUT=file-spec

          _______________________________________________________

          PARAMETERS
          mailing-list
          Name of the mailing list whose subscriber list is
          to be displayed. The mailing list must reside on the
          local system.

          _______________________________________________________

          DESCRIPTION
          This command performs the functional equivalent of
          the mailing list processor's REVIEW command for any
          mailing list on the local system. All subscribers'
          addresses and personal names (if any) listed, along
          with their MAIL/NOMAIL status.

          _______________________________________________________

          QUALIFIERS
          /OUTPUT=file-spec
          Directs the results to the specified file. If omitted,
          the results are displayed on SYS$OUTPUT.

                                                           MCP-45

 


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


                                                     MCP Commands
                                                  SET DECNET_SMTP




          _______________________________________________________

          SET DECNET_SMTP

          Alters settings specific to the SMTP-over-DECnet
          delivery agent.

          _______________________________________________________

          FORMAT

          SET DECNET_SMTP

          _______________________________________________________
          Command Qualifiers     Defaults

          /[NO]ACCOUNTING
          /MAXIMUM_RETRIES=count
          /RETRY_INTERVAL=delta-time

          _______________________________________________________

          DESCRIPTION
          This command is used to change the SMTP-over-DECnet
          agent settings.

          _______________________________________________________

          QUALIFIERS
          /[NO]ACCOUNTING
          Enables or disables the recording of accounting
          information. Accounting is disabled by default. When
          enabled, accounting information is written to the file
          MX_DNSMTP_DIR:MX_DNSMTP_ACC.DAT. You can redirect the
          accounting information to another file by defining the
          logical name MX_DNSMTP_ACC.

          The format of the accounting record is:

          dd-mmm-yyyy hh:mm XMIT: PROTO=DECNET_SMTP, SOURCE="src-addr", HOST="host", BYTES_SENT=n

                                                           MCP-47

 


          MCP Commands
          SET DECNET_SMTP




          where dd-mmm-yyyy hh:mm is the date/time stamp of the
          accounting record; src-addr is the source address for
          the message; host is the host to which the message was
          sent; and n is the number of bytes in the delivered
          message.

          /MAXIMUM_RETRIES=count
          Sets the maximum number of retries for message
          delivery. The default count is 96, which for a half-
          hour retry interval comes to roughly two days of
          retries.

          /RETRY_INTERVAL=delta-time
          Sets the amount of time that should elapse between
          delivery attempts. The default is 30 minutes. Specify
          as a VMS delta time value.
























          MCP-48

 


                                                     MCP Commands
                                                         SET JNET




          _______________________________________________________

          SET JNET

          Alters settings specific to the Jnet interface.

          _______________________________________________________

          FORMAT

          SET JNET

          _______________________________________________________
          Command Qualifiers     Defaults

          /[NO]ACCOUNTING
          /[NO]BSMTP_REPLY
          /[NO]LENIENT
          /[NO]PERCENT_HACK
          /[NO]USERNAME=(username[,...])

          _______________________________________________________

          DESCRIPTION
          This command is used to enable or disable the various
          settings specific to the Jnet interface.

          _______________________________________________________

          QUALIFIERS
          /[NO]ACCOUNTING
          Enables or disables the recording of accounting
          information. Accounting is disabled by default. When
          enabled, accounting information is written to the
          file MX_JNET_DIR:MX_JNET_ACC.DAT. You can redirect the
          accounting information to another file by defining the
          logical name MX_JNET_ACC.

          The format of the accounting record is:

          dd-mmm-yyyy hh:mm XMIT: PROTO=proto, SOURCE="src-addr", HOST="dest", BYTES_SENT=n

                                                           MCP-49

 


          MCP Commands
          SET JNET




          where proto is one of the BITNET mailer protocol types
          (BSMTP, JNET, or BITNET), src-addr is the source
          address for the message, dest is the BITNET host to
          which the message was sent, and n is the number of
          bytes transmitted. Note that with the BSMTP and BITNET
          protocol types, one transmission can have multiple
          destinations on a single host.

          /[NO]BSMTP_REPLY
          Controls whether replies are sent for incoming BSMTP
          transactions. Most hosts supporting BSMTP discard
          any replies, so this is disabled by default to reduce
          network traffic.

          /[NO]LENIENT
          Controls whether BITNET gateway rules are strictly
          or leniently enforced. The gateway rules specify that
          no messages may be gatewayed to or from a BITNET/EARN
          host that does not run a BSMTP-compliant mailer. Until
          more BITNET and EARN hosts start running mailers, you
          may wish to use the lenient setting to avoid excessive
          rejection of gatewayed mail.

          /[NO]PERCENT_HACK
          Enables or disables automatic percent-hack
          translation. The default is to enable translation.

          Percent hacking should be disabled when Jnet is the
          only network transport being used for mail.

          /[NO]USERNAME=(username[,...])
          Specifies the username(s) in the NJE tags on incoming
          mail files that should be considered as being destined
          for the mailer. The first username in the list,
          called the primary mailer username, will also be
          used as the NJE origin user on outgoing messages,
          which should match the value of the :mailer tag in the
          XMAILER.NAMES file entry for the local host.


          MCP-50

 


                                                     MCP Commands
                                                         SET JNET




          If omitted or disabled by SET JNET/NOUSERNAME, MX
          uses the username of the process running the MX/Jnet
          interface as the mailer username.

          Generally, only one mailer username will be needed
          per system, which by BITNET recommendations should
          be MAILER. The need for recognition of multiple
          mailer usernames should occur only if you decide to
          change the mailer username for your system, during the
          transition period from old to new.






























                                                           MCP-51

 


          MCP Commands
          SET LOCAL




          _______________________________________________________

          SET LOCAL

          Alters Local-delivery-specific settings.

          _______________________________________________________

          FORMAT

          SET LOCAL

          _______________________________________________________
          Command Qualifiers     Defaults

          /[NO]ACCOUNTING
          /[NO]CC_POSTMASTER
          /[NO]HEADERS=(loc:(hdrname[,...])[,...])
          /MAXIMUM_RETRIES=count
          /[NO]MM_DELIVER
          /[NO]MULTIPLE_FROM
          /RETRY_INTERVAL=delta-time

          _______________________________________________________

          DESCRIPTION
          This command is used to change the local delivery
          agent settings.

          _______________________________________________________

          QUALIFIERS
          /[NO]ACCOUNTING
          Enables or disables the recording of accounting
          information. Accounting is disabled by default. When
          enabled, accounting information is written to the file
          MX_LOCAL_DIR:MX_LOCAL_ACC.DAT. You can redirect the
          accounting information to another file by defining the
          logical name MX_LOCAL_ACC.

          The format of the accounting record is:

              dd-mmm-yyyy hh:mm DELIVER: SOURCE="src-addr", USER="user", SIZE=n

          MCP-52

 


                                                     MCP Commands
                                                        SET LOCAL




          where dd-mmm-yyyy hh:mm is the date/time stamp of the
          accounting record; src-addr is the source address for
          the message; user is the address on the local host to
          which the message was delivered; and n is the number
          of bytes in the delivered message.

          /[NO]CC_POSTMASTER
          Specifies whether or not error messages resulting
          from LOCAL delivery errors are mailed to the local
          POSTMASTER, in addition to the original message
          sender.

          /HEADERS=(loc:(hdrname[,...])[,...])
          Controls the inclusion and placement of RFC 822
          headers in messages delivered to VMS Mail. Valid
          values for loc are TOP and BOTTOM. Valid values for
          hdrname are listed in Table MCP-4.

          Table_MCP-4__Header_name_keywords______________________

          Keyword____________Meaning_____________________________

          ALL                All headers.

          BCC                The Bcc (blind carbon copy) header.

          CC                 The CC (carbon copy) header.

          DATE               The Date header.

          FROM               The From header.

          IN_REPLY_TO        The In-Reply-To header.

          KEYWORDS           The Keywords header (not strictly
                             RFC 822).

          MESSAGE_ID         The Message-Id header.

          OTHER              Any header not recognized by MX.

          RECEIVED           The Received header(s).

          REFERENCES         The References header (not strictly
                             RFC 822).

          REPLY_TO           The Reply-To header.

                                                           MCP-53

 


          MCP Commands
          SET LOCAL




          Table_MCP-4_(Cont.)__Header_name_keywords______________

          Keyword____________Meaning_____________________________

          RESENT_BCC         The Resent-Bcc header.

          RESENT_CC          The Resent-CC header.

          RESENT_DATE        The Resent-Date header.

          RESENT_FROM        The Resent-From header.

          RESENT_MESSAGE_ID  The Resent-Message-Id header.

          RESENT_REPLY_TO    The Resent-Reply-To header.

          RESENT_SENDER      The Resent-Sender header.

          RESENT_TO          The Resent-To header.

          RETURN_PATH        The Return-Path header.

          SENDER             The Sender header.

          SUBJECT            The Subject header.

          TO_________________The_To_header.______________________

          The header names can be negated by prefixing them with
          NO. You may include any combination of headers for
          inclusion at the top and/or the end of the message.
          For example, you might want to move the Received and
          Return-Path headers to the bottom of messages, since
          the information they convey are of interest only when
          there are network problems:

              MCP> SET LOCAL/HEADERS=(TOP:(ALL,NORECEIVED,NORETURN_PATH),-
              _MCP>                    BOTTOM:(NOALL,RECEIVED,RETURN_PATH))

          /MAXIMUM_RETRIES=count
          Sets the maximum number of retries for DECnet message
          delivery. The default count is 96, which for a half-
          hour retry interval comes to roughly two days of
          retries.

          /[NO]MM_DELIVER
          Controls whether or not incoming mail can be delivered
          via the MultiNet user agent MM. By default, incoming
          mail is delivered only via VMS Mail. If some users

          MCP-54

 


                                                     MCP Commands
                                                        SET LOCAL




          would prefer to have all mail delivered to MM,
          specifying /MM_DELIVER will allow MX to comply with
          those requests.

          /[NO]MULTIPLE_FROM
          Controls whether or not the VMS Mail ``From:'' line
          on incoming messages can contain multiple return
          addresses. By default, if an RFC822 From: or Reply-
          To: line contains more than one address, as many of
          those addresses as will fit are included on the VMS
          Mail ``From:'' line (up to 255 characters). Specifying
          /NOMULTIPLE_FROM limits the ``From:'' line to a single
          address.

          /RETRY_INTERVAL=delta-time
          Sets the amount of time that should elapse between
          delivery attempts. The default is 30 minutes. Specify
          as a VMS delta time value.






















                                                           MCP-55

 


          MCP Commands
          SET ROUTER




          _______________________________________________________

          SET ROUTER

          Alters Router-specific settings.

          _______________________________________________________

          FORMAT

          SET ROUTER

          _______________________________________________________
          Command Qualifiers     Defaults

          /[NO]OMIT_VMSMAIL_SENDER
          /[NO]PERCENT_HACK

          _______________________________________________________

          DESCRIPTION
          This command is used to enable or disable the
          automatic de-hacking of percent signs in a local
          address. Percent-hacking is explained in Section 3.3.

          _______________________________________________________

          QUALIFIERS
          /[NO]OMIT_VMSMAIL_SENDER
          Enables or disables the omission of the Sender: header
          for messages sent from VMS Mail. Normally, a Sender:
          line is included if the Sender: and From: addresses
          are different. However, some sites using the MX_SITE_
          NAME_CONVERSION feature with the FULL_CONVERT routine
          have had problems sending mail to some mailers when
          the Sender: and From: are different, despite the fact
          that it is allowed by RFC822 (in fact, according to
          RFC822, the Sender: should be omitted if it is the
          same address as the From: address). To allow those
          sites to work around the problems with those mailers,
          /OMIT_VMSMAIL_SENDER can be used to omit the Sender:
          line in all cases.

          MCP-56

 


                                                     MCP Commands
                                                       SET ROUTER




          MX_SITE_NAME_CONVERSION is documented in the Message
          Exchange Programmer's Guide.

          Note: If /OMIT_VMSMAIL_SENDER is specified, then the
          Sender: line is also omitted from any SMTP messages
          forwarded by users with the MX_FAKE_RFC822 process
          rights identifier.

          /[NO]PERCENT_HACK
          Enables or disables automatic percent-hack
          translation. The default is to enable translation.





























                                                           MCP-57

 


          MCP Commands
          SET SITE




          _______________________________________________________

          SET SITE

          Alters settings specific to the SITE delivery agent.

          _______________________________________________________

          FORMAT

          SET SITE

          _______________________________________________________
          Command Qualifiers     Defaults

          /MAXIMUM_RETRIES=count
          /RETRY_INTERVAL=delta-time

          _______________________________________________________

          DESCRIPTION
          This command is used to change the SITE agent
          settings.

          _______________________________________________________

          QUALIFIERS
          /MAXIMUM_RETRIES=count
          Sets the maximum number of retries for message
          delivery. The default count is 96, which for a half-
          hour retry interval comes to roughly two days of
          retries.

          /RETRY_INTERVAL=delta-time
          Sets the amount of time that should elapse between
          delivery attempts. The default is 30 minutes. Specify
          as a VMS delta time value.



          MCP-58

 


                                                     MCP Commands
                                                         SET SMTP




          _______________________________________________________

          SET SMTP

          Alters SMTP-delivery-specific settings.

          _______________________________________________________

          FORMAT

          SET SMTP

          _______________________________________________________
          Command Qualifiers     Defaults

          /[NO]ACCOUNTING
          /DEFAULT_ROUTER=hostname
          /DNS_RETRIES=dnscount
          /MAXIMUM_RETRIES=count
          /RETRY_INTERVAL=delta-time

          _______________________________________________________

          DESCRIPTION
          This command is used to change the SMTP interface
          settings.

          _______________________________________________________

          QUALIFIERS
          /[NO]ACCOUNTING
          Enables or disables the recording of accounting
          information. Accounting is disabled by default. When
          enabled, accounting information is written to the
          file MX_SMTP_DIR:MX_SMTP_ACC.DAT. You can redirect the
          accounting information to another file by defining the
          logical name MX_SMTP_ACC.

          The format of the accounting record is:

          dd-mmm-yyyy hh:mm XMIT: PROTO=SMTP, SOURCE="src-addr", HOST="dest", BYTES_SENT=n

                                                           MCP-59

 


          MCP Commands
          SET SMTP




          where src-addr is the source address for the message;
          dest is the name of the Internet host to which the
          message was sent; and n is the number of bytes
          transmitted. Note that with SMTP messages, one
          transmission can have multiple destinations on a
          single host.

          /DEFAULT_ROUTER=hostname
          Specifies the name of a host to which SMTP messages
          can be forwarded if MX cannot resolve a host name.
          This qualifier should only be used if you are not
          using the Internet domain name service. The hostname
          should be the name of a host which appears in your
          local host table.

          /DNS_RETRIES=dnscount
          Sets the maximum number of retries for SMTP delivery
          when the cause of the failure is the inability to
          determine the address corresponding to a host name.
          Certain types of domain server failures can cause MX
          to believe a host name is invalid. When a host name
          is genuinely invalid, however, the sender should be
          told relatively quickly. Therefore, the default count
          is 12 (giving about 6 hours' worth of attempts for a
          half-hour retry interval).

          /MAXIMUM_RETRIES=count
          Sets the maximum number of retries for SMTP message
          delivery. The default count is 96, which for a half-
          hour retry interval comes to roughly two days of
          retries.

          /RETRY_INTERVAL=delta-time
          Sets the amount of time that should elapse between
          delivery attempts. The default is 30 minutes. Specify
          as a VMS delta time value.




          MCP-60

 


                                                     MCP Commands
                                                     SET X25_SMTP




          _______________________________________________________

          SET X25_SMTP

          Alters settings specific to the SMTP-over-X.25
          delivery agent.

          _______________________________________________________

          FORMAT

          SET X25_SMTP

          _______________________________________________________
          Command Qualifiers     Defaults

          /[NO]ACCOUNTING
          /MAXIMUM_RETRIES=count
          /RETRY_INTERVAL=delta-time

          _______________________________________________________

          DESCRIPTION
          This command is used to change the SMTP-over-X.25
          interface settings.

          _______________________________________________________

          QUALIFIERS
          /[NO]ACCOUNTING
          Enables or disables the recording of accounting
          information. Accounting is disabled by default. When
          enabled, accounting information is written to the file
          MX_XSMTP_DIR:MX_XSMTP_ACC.DAT. You can redirect the
          accounting information to another file by defining the
          logical name MX_XSMTP_ACC.

          The format of the accounting record is:

          dd-mmm-yyyy hh:mm XMIT: PROTO=X25_SMTP, SOURCE="src-addr", HOST="dest", BYTES_SENT=n

                                                           MCP-61

 


          MCP Commands
          SET X25_SMTP




          where src-addr is the source address for the message;
          dest is the name of the host to which the message was
          sent; and n is the number of bytes transmitted. Note
          that with X25_SMTP messages, one transmission can have
          multiple destinations on a single host.

          /MAXIMUM_RETRIES=count
          Sets the maximum number of retries for X25_SMTP
          message delivery. The default count is 96, which for a
          half-hour retry interval comes to roughly two days of
          retries.

          /RETRY_INTERVAL=delta-time
          Sets the amount of time that should elapse between
          delivery attempts. The default is 30 minutes. Specify
          as a VMS delta time value.
























          MCP-62

 


                                                     MCP Commands
                                                             SHOW




          _______________________________________________________

          SHOW

          Displays all or part of the current MX configuration.

          _______________________________________________________

          FORMAT
                { ALIASES [pattern]       }
                { CONFIGURATION_FILE      }
                { DECNET_SMTP             }
                {                         }
                { FILE_SERVER [pattern]   }
                { JNET                    }
                { LISTS [pattern]         }
                {                         }
                { LOCAL                   }
                { PATHS [pattern]         }
          SHOW  { REWRITE_RULES [pattern] }
                {                         }
                { ROUTER                  }
                { SITE                    }
                { SMTP                    }
                {                         }
                { SYSTEM_USERS            }
                { VERSION                 }
                { X25_SMTP                }
                {                         }
                { 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, file
          servers, lists, paths, and rewrite rules, only those
          records matching pattern (which may contain wildcard
          characters) are displayed; if you omit pattern, all
          records are displayed.

                                                           MCP-63

 


          MCP Commands
          SHOW




          SHOW CONFIGURATION_FILE displays the name of the
          configuration file loaded when MCP was started.
          SHOW VERSION displays the version identifier for the
          current version of MX.

          _______________________________________________________

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


                                                     MCP Commands
                                                         SHUTDOWN




          _______________________________________________________

          SHUTDOWN

          Sends a shutdown signal to one or more delivery
          agents.

          _______________________________________________________

          FORMAT

          SHUTDOWN  [agent-name...]

          _______________________________________________________
          Command Qualifiers     Defaults

          /CLUSTER
          /|ODE=(node[,...])

          _______________________________________________________

          PARAMETERS
          agent-name...
          One or more MX delivery agent names, separated by
          commas. Valid names are DECNET_SMTP, JNET, LOCAL, LSV,
          MLF, ROUTER, SITE, SMTP, SMTP_SERVER, UUCP, and X25_
          SMTP. If omitted, all agents running on the same node
          as the user executing this command are shut down.

          Note that the SMTP delivery agent may be shut down
          separately from the SMTP_SERVER message entry agent.

          _______________________________________________________

          DESCRIPTION
          The SHUTDOWN command can be used to signal one or more
          MX delivery agents to finish processing and exit. This
          command requires the SYSLCK privilege.


                                                           MCP-65

 


          MCP Commands
          SHUTDOWN



          _______________________________________________________

          QUALIFIERS
          /CLUSTER
          Specifies that the SHUTDOWN command should affect the
          specified agents on all nodes in the cluster, not just
          t|e current node.
           |
          /|ODE=(node[,...])
          S|ecifies that the SHUTDOWN command should affect the
          s|ecified agents only on the given nodes.






























          MCP-66

 


                                                     MCP Commands
                                                           STATUS




          _______________________________________________________

          STATUS

          Displays a list of the MX agent processes currently
          running and the current state of each agent process.

          _______________________________________________________

          FORMAT

          STATUS  [agent-name...]

          _______________________________________________________
          Command Qualifiers     Defaults
           |
          /|ODE=(node[,...])

          _______________________________________________________

          PARAMETERS
          agent-name...
          One or more MX agent names, separated by commas.
          Valid names are DECNET_SMTP, JNET, LOCAL, LSV, MLF,
          ROUTER, SITE, SMTP, SMTP_SERVER, UUCP, and X25_SMTP.
          If omitted, information about all agents is displayed.

          _______________________________________________________

          DESCRIPTION
          For each process running one of the MX agent programs,
          the process ID, process name, MX status, and MX agent
          type is displayed. In a VMScluster environment,
          the VMScluster node name for the process is also
          displayed. This command requires the SYSLCK privilege.

          The status field indicates the action currently being
          performed by the agent. Valid status descriptions are
          shown in Table MCP-5.

                                                           MCP-67

 


          MCP Commands
          STATUS




          Table_MCP-5__MCP_STATUS_Descriptions___________________

          Unknown        Current status is not known.

          Reading        Reading the MX configuration file.
          Config.

          Idle           Process is idle, waiting for an entry
                         to process.

          Enabling       Requesting single agent enable lock.

          Selecting      Searching in-memory queue for an entry
                         to process.

          Searching      Searching in-memory queue for an entry
                         to process.

          Locating       Initializing the in-memory queue by
                         searching the MX queue file for entries
                         to be processed by that agent.

          Searching2     Searching in-memory queue for located
                         entries.

          Processing     Processing the specified entry.

          Retrying       Retrying delivery of the specified
                         entry.

          Inserting      Inserting a new queue entry.

          Search. for    Searching for delayed entries.
          wait

          Waiting for    Idle, waiting to process the specified
                         entry.

          Req update     Requesting other agents to update an
                         entry.

          FLQ Cleanup    Performing MX queue file maintenance.

          FLQread wait   Waiting for a read from the MX queue
                         file.

          Wlock wait     Waiting for entry work lock.

          Connected      SMTP Server has the specified number of
          _______________incoming_connections_active.____________

          MCP-68

 


                                                     MCP Commands
                                                           STATUS



          _|_____________________________________________________
           |
          Q|ALIFIERS
          /|ODE=(node[,...])
          S|ecifies that the STATUS command should show only the
          s|ecified agents running on the given nodes.



































                                                           MCP-69

 









          _________________________________________________________________

          Index

          _______________________________
          A                                  HDR_INFO file,8-2

          _______________________________    _______________________________
          address-rewriting rules,3-1        J
          Alias,3-4                          _______________________________

          _______________________________    JNET_INFO file,8-2
          B                                  JNET_INPUT file,8-3

          _______________________________    _______________________________
          BITEARN.NODES file,4-5,  4-6       L
          BSMTP,4-9                          _______________________________

          _______________________________    LOCAL_INFO file,8-2
          C                                  Logical names
          _______________________________     MAIL$PROTOCOL_prefix,5-2
          component names,9-1                 MX_DNSMTP_DEBUG,8-5
                                              MX_DNSMTP_SERVER_DEBUG,8-6
          _______________________________     MX_EVENT_OPER_CLASS,3-5,
          D                                      4-11
          _______________________________     MX_FLQ_AUTOPURGE_FIN,6-4
          Debugging,8-4                       MX_FLQ_CHECK_WAIT,6-3
          DEFINE PATH,3-2                     MX_FLQ_DEBUG,8-5
          delivery path,3-2                   MX_FLQ_DIR,1-4
          DNSMTP_INFO file,8-2                MX_FLQ_MGR_WAKEUP_INTERVAL,
          DOMAIN.NAMES file,3-3,  4-5,           6-3
             4-8                              MX_FLQ_PURGE_WAIT,6-3
          Domain/path mapping,MCP-19          MX_JNET_DEBUG,8-5
                                              MX_JNET_NODE,4-4
          _______________________________     MX_LOCAL_DEBUG,8-5

          F                                   MX_LSV_DEBUG,8-5
          _______________________________     MX_MLF_DEBUG,8-5
          File server,MCP-7                   MX_PROTOCOL_PREFIX,5-2
                                              MX_RESTRICT_USAGE,5-1
          _______________________________     MX_ROUTER_DEBUG,8-5

          H                                   MX_ROUTER_WAKEUP_INTERVAL,
          _______________________________        6-3

                                                                    Index-1

 


          Index





          Logical names (cont'd)             MCP commands (cont'd)

            MX_SHUTDOWN,4-10                  QUEUE SYNCHRONIZE,MCP-40
            MX_SITE_DEBUG,8-6                 QUIT,MCP-41
            MX_SMTP_DEBUG,8-5                 REMOVE,MCP-42
            MX_SMTP_SERVER_DEBUG,8-5          RESET,MCP-43
            MX_SMTP_SERVER_THREADS,5-3        REVIEW,MCP-45
            MX_UUCP_DEBUG,8-6                 SAVE,MCP-46
            MX_UUCP_REWRITE,4-9               SET DECNET_SMTP,MCP-47
            MX_UUCP_RMAIL_DEBUG,8-5           SET JNET,MCP-49
            MX_VMSMAIL_FROM_FORMAT,5-2        SET LOCAL,MCP-52
            MX_XSMTP_DEBUG,8-6                SET ROUTER,MCP-56
            MX_XSMTP_SERVER_DEBUG,8-6         SET SITE,MCP-58
          _______________________________     SET SMTP,MCP-59
                                              SET X25_SMTP,MCP-61
          M                                   SHOW,MCP-63
          _______________________________     SHUTDOWN,MCP-65
          Mail exchanger,4-2                  STATUS,MCP-67
          Mailing lists,MCP-11               MLFAKE utility,7-1
          MAILQUEUE utility,7-2              MLF_INFO file,8-2
          MCP commands                       MSG_TEXT file,8-2
            @,MCP-5                          MX___STARTUP.COM,9-1
            DEFINE ALIAS,MCP-6               MXBITNET.MAILERS file,4-7
            DEFINE FILE_SERVER,MCP-7         MX Control Program,MCP-3
            DEFINE LIST,MCP-11               MX_DECODE utility,7-3
            DEFINE PATH,3-2,  MCP-19         MX_LOGICALS.DAT,9-3
            DEFINE REWRITE_RULE,MCP-21       MX_MAILSHR,5-1
            DEFINE SYSTEM_USERS,MCP-23       MX_START.COM,9-1
            EXIT,MCP-25                      MX_STARTUP.COM,9-1
            HELP,MCP-26                      MX_STARTUP_INFO.DAT,9-3, 9-5
            MODIFY,MCP-27
            QUEUE CANCEL,MCP-28              _______________________________

            QUEUE COMPRESS,MCP-29            N
            QUEUE CREATE,MCP-31              _______________________________
            QUEUE EXTEND,MCP-32              NETDATA format,4-5, 4-7
            QUEUE PURGE,MCP-33               next hop,3-2
            QUEUE READY,MCP-34
            QUEUE SHOW,MCP-35
            QUEUE STATISTICS,MCP-39

          Index-2

 


                                                                      Index




          _______________________________
          P                                  Utilities (cont'd)

          _______________________________     MX_DECODE,7-3
          Percent-hack,3-4                   UUCP rewrite rules, using,4-9
          Process names,8-3                  UUCP_INFO file,8-2

          _______________________________    _______________________________

          Q                                  V
          _______________________________    _______________________________
          Queue files,8-1                    VMS MAIL
          Queue file types,8-2                foreign protocol,5-2
          Queue status,6-5                    protocol prefix,5-2
                                              restricting usage,5-1
          _______________________________    _______________________________

          R                                  X
          _______________________________    _______________________________
          rewrite rules,3-1,  4-9, MCP-21    XMAILER.NAMES file,4-5, 4-8

          _______________________________    XSMTP_INFO file,8-2

          S
          _______________________________
          Shutting down MX,4-10
          SITE_INFO file,8-2
          SMTP default router,4-2
          SMTP_INFO file,8-2
          SRC_INFO file,8-2
          startup command procedures,9-1
          startup components,9-1

          _______________________________

          T
          _______________________________
          Trace logs,8-4

          _______________________________

          U
          _______________________________
          Utilities
            MAILQUEUE,7-2
            MLFAKE,7-1

                                                                    Index-3
