 


















          Message Exchange User's Guide



          December 1995



          This manual provides information for users of Message
          Exchange, electronic mail software for VMS systems.




          Revision/Update Information:  This is a revised manual.

          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                                         v

          _______________________________________________________
          CHAPTER 1  USING MESSAGE EXCHANGE WITH VMS MAIL     1-1

                _________________________________________________
                1.1   SPECIFYING AN ADDRESS                   1-1

                1.1.1     Displaying MX Address
                          Translations  __________________    1-2

                1.1.2     Multiple Recipients  ___________    1-3

                1.1.3     Quotation Marks  _______________    1-3

                _________________________________________________
                1.2   USING SET FORWARD WITH MX               1-3

                _________________________________________________
                1.3   PERSONAL NAME                           1-4

                _________________________________________________
                1.4   SIGNATURE FILES                         1-4

                1.4.1     Automatic Signature Inclusion  _    1-5

                _________________________________________________
                1.5   REDIRECTING REPLIES                     1-5

                _________________________________________________
                1.6   RECEIPT ACKNOWLEDGMENT                  1-6

                _________________________________________________
                1.7   NETWORK DELIVERY DELAYS                 1-6

                1.7.1     Displaying MX Informational
                          Messages  ______________________    1-7

                                                              iii

 


          Contents





                _________________________________________________
                1.8   SENDING BINARY FILES TO OTHER VMS
                      USERS                                   1-7


          _______________________________________________________
          CHAPTER 2  THE MXALIAS UTILITY                      2-1

                _________________________________________________
                2.1   ADDING AN MX ALIAS                      2-2

                _________________________________________________
                2.2   USING AN MX ALIAS                       2-3

                2.2.1     Displaying MX Address
                          Translations  __________________    2-3

                2.2.2     MX As the Default Mail
                          Transport  _____________________    2-4

                _________________________________________________
                2.3   DISPLAYING ALIASES                      2-4

                _________________________________________________
                2.4   MODIFYING ALIASES                       2-5

                _________________________________________________
                2.5   REMOVING ALIASES                        2-5

          _______________________________________________________
          CHAPTER 3  ELECTRONIC MAILING LISTS                 3-1

                _________________________________________________
                3.1   INTERNET-STYLE LISTS                    3-1

                _________________________________________________
                3.2   BITNET-STYLE LISTS                      3-2



          iv

 


                                                         Contents





          _______________________________________________________
          CHAPTER 4  NETWORK FILE SERVERS                     4-1

                _________________________________________________
                4.1   GET HELP                                4-1

                _________________________________________________
                4.2   MX FILESERV COMMANDS                    4-2

                4.2.1     Packages  ______________________    4-3

                4.2.2     Binary Files  __________________    4-3

          _______________________________________________________
          APPENDIX A  MESSAGE HEADER FORMAT                   A-1

                _________________________________________________
                A.1   VMS MAIL HEADERS                        A-3

                A.1.1     From Header  ___________________    A-4

                A.1.2     To and CC Headers  _____________    A-4

                A.1.3     Subject Header  ________________    A-4
















                                                                v

 







          _______________________________________________________

          Preface

          Message Exchange (MX) is software that provides store-
          and-forward routing and delivery of electronic mail
          messages. It can also provide mailing list and file
          distribution services. MX can be used to enhance local
          electronic mail (E-mail) support, and it can be used
          with several kinds of network protocols to provide a
          unified E-mail interface to different networks.

          __________________________________________________________________

          Intended Audience

          This manual is intended for any VMS MAIL user who
          uses MX, and users of MX's mailing list and file
          distribution services. The reader should already know
          the basics of using VMS and the VMS MAIL utility.

          __________________________________________________________________

          Document Structure

          This guide consists of four chapters and one appendix.

          Chapter    Describes the MX/VMS MAIL interface.
          1

          Chapter    Describes the MXALIAS utility.
          2

          Chapter    Describes the mailing list handler.
          3

          Chapter    Describes the file server.
          4

          Appendix   Describes MX message formats in detail.
          A

                                                                v

 


          Preface




          __________________________________________________________________

          Related Documents

          You can find additional information in the following
          documents:

          o  Message Exchange Installation Guide describes the
             installation of MX.

          o  Message Exchange Management Guide describes the
             management and operation of MX.

          o  Message Exchange Mailing List/File Server Guide
             describes the management and operation of the MX
             mailing list and 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  VMS Mail Utility Manual describes the VMS MAIL
             utility in detail.


















          vi

 








          _______________________________________________________

   1      Using Message Exchange with VMS MAIL



          Message Exchange (MX) interfaces with VMS MAIL to
          provide the means for addressing outgoing mail through
          MX. It also ensures that mail that is delivered via
          MX has an appropriate source address for replies,
          and provides support for signature files and user-
          specified reply-to addresses.

          __________________________________________________________________

   1.1    Specifying an Address

          MX interfaces with VMS MAIL as a "foreign protocol".
          When using VMS MAIL, you address mail to be sent
          through MX by specifying an address of the form:

              MX%"user@host"

          The leading MX% tells VMS MAIL to invoke the MX
          protocol handler; the address, which should be
          surrounded by quotation marks to prevent the address
          from being converted to upper case and prevent the
          @-sign from being interpreted by VMS MAIL, is the
          network mail address of the user you wish to send mail
          to.

          If the user is on the local host, you can omit the
          @host part of the address, and the quotation marks,
          just specifying

              MX%username

          for an address.

          The MXALIAS utility can be used to define MX aliases
          for e-mail addresses; see Chapter 2, The MXALIAS
          Utility, for information about using MXALIAS. MX
          aliases are used just as if sending mail through MX
          to a local user:

                                                              1-1

 


          Using Message Exchange with VMS MAIL





              MX%alias

          Any MX% address given without the @host part of the
          address is checked to see if it is an MX alias. If it
          is, the equated address is used; if not, the specified
          address is assumed to be that of a local user.

          ___________________________

   1.1.1  Displaying MX Address Translations

          If you want to see all address translations made by
          MX for MX% addresses passed from VMS Mail, you can
          define the logical MX_VMSMAIL_SHOW_ADDR as shown in
          the following command:

              $ DEFINE MX_VMSMAIL_SHOW_ADDR TRUE

          If the logical is defined, MX displays the final
          address used for a given address:

              MAIL> SEND
              To:     MX%JOE, MX%"MX-List@WKUVX1.WKU.EDU", SYSTEM
                MX rewrote alias JOE as <SYSTEM@WKUVX1.WKU.EDU>
                MX rewrote MX-List@WKUVX1.WKU.EDU as <MX-List@WKUVX1.WKU.EDU>
              Subj:   ....

          Note that ``SYSTEM'' was not passed to MX because
          it was not specified with the MX% prefix. Also
          note that JOE had been defined as an alias equal
          to SYSTEM@WKUVX1.WKU.EDU using the MXALIAS utility
          (described in Chapter 2).

          Placing the MX_VMSMAIL_SHOW_ADDR logical definition
          in your LOGIN.COM will cause MX to always show you all
          address translations.




          1-2

 


                             Using Message Exchange with VMS MAIL




          ___________________________

   1.1.2  Multiple Recipients

          When sending messages to more than one recipient
          through MX, each recipient's address requires the MX%
          prefix (and quotation marks, if needed). For examples:

              MAIL> SEND
              To: SMITH, MX%"jones@otherhost.edu",BROWN,MX%NAMES-L

          Note that you can mix plain, local usernames with
          MX-directed addresses in the same message.

          ___________________________

   1.1.3  Quotation Marks

          VMS MAIL cannot handle quotation marks within an
          address. MX works around this problem by substituting
          apostrophes instead. For example, if the destination
          address is

              "node::user"@remote.host

          you can specify this address in VMS MAIL as

              MX%"'node::user'@remote.host"

          __________________________________________________________________

   1.2    Using SET FORWARD with MX

          You can use the SET FORWARD command in VMS MAIL to set
          a forwarding address for your mail through MX. To do
          this, however, requires that you add extra quotes to
          the address. The forwarding address should be quoted,
          and, since MX addresses must be quoted, the inner
          quotes must be doubled to comply with the command
          parsing. For example:

              MAIL> SET FORWARD "MX%""user@host"""

          You should be sure to check the forwarding address
          with SHOW FORWARD and to send yourself a test message
          to ensure that you specified the address correctly.

                                                              1-3

 


          Using Message Exchange with VMS MAIL




          __________________________________________________________________

   1.3    Personal Name

          The SET PERSONAL_NAME command in VMS MAIL lets you
          enter your real name, to be appended to your VMS
          username on outgoing mail. Messages sent via MX will
          also include your personal name if you have one set.

          __________________________________________________________________

   1.4    Signature Files

          The MX/VMS MAIL interface provides support for
          "signature" files. A signature file is a file that
          contains your name, E-mail address, and any other
          information that you would like to have included in
          your outgoing mail messages. It should be no more
          than a few lines long and should probably contain
          lines that do not exceed 80 characters in length. For
          example:

              Peter Shandy, Ph.D.
              Horticulture Department
              Balaclava Agricultural College
              shandy@buster.balaclava.edu

          Once you create a signature file, you inform MX of its
          existence by defining the logical name MX_SIGNATURE:

              $ DEFINE MX_SIGNATURE device:[directory]name.type

          You can then have the signature included in your
          message by entering the line

              /SIGNATURE

          in your message. To be recognized, there can be no
          other text on the line and no leading blanks. Case
          is not important, and you can abbreviate SIGNATURE
          to SIG. Your signature file will be inserted in the
          message at the point where you place the /SIGNATURE
          line.

          1-4

 


                             Using Message Exchange with VMS MAIL





          Note that the signature is included only in copies
          of the message that are sent via MX; if you also
          send your message to users not using the MX% prefix,
          they will just see the /SIGNATURE line and not your
          signature file.

          To enable your signature file every time you login,
          include the DEFINE command in your login command
          procedure.

          ___________________________

   1.4.1  Automatic Signature Inclusion

          Your signature file can be included automatically at
          the end of your message by defining the logical name
          MX_AUTO_SIGNATURE:

              $ DEFINE MX_AUTO_SIGNATURE text

          The text is not important; as long as the logical name
          is defined, the signature file you specify with MX_
          SIGNATURE will will automatically be appended to then
          end of all subsequent MX messages. A /SIGNATURE line
          can be used to place the signature anywhere in the
          message (overriding the automatic appending).

          If you wish to prevent the automatic inclusion of your
          signature file, enter a line

              /NOSIGNATURE

          in your message. The same formatting rules apply as
          for /SIGNATURE.

          __________________________________________________________________

   1.5    Redirecting Replies

          Normally when you send a message via MX from your VMS
          account, the message will include information that
          will direct any replies to the message back to your
          VMS account. If you would rather have replies go to
          a different account, or to an account on a different
          system, you can define the logical name MX_REPLY_TO to
          include this information in the message:

                                                              1-5

 


          Using Message Exchange with VMS MAIL





              $ DEFINE MX_REPLY_TO "user@host"

          Note that you should not include the MX% prefix on the
          address, and you should not change quotation marks to
          apostrophes when you specify the address.

          To have this reply address included in your messages
          every time you login, include the DEFINE command in
          your LOGIN.COM file.

          Some mailers, including MX, allow multiple addresses
          on the ``From:'' line for messages. You can include
          multiple addresses in the MX_REPLY_TO definition to
          allow replies to be returned to multiple addresses
          (assuming the remote mailer allows it). For example,
          if you want replies to your messages to go to two
          different accounts, you could define the logical as
          follows:

              $ DEFINE MX_REPLY_TO "user@host,user2@host2"

          __________________________________________________________________

   1.6    Receipt Acknowledgment

          Most network E-mail systems are modelled after the
          postal system: once you put an electronic mail message
          in the post, you have no way of knowing whether the
          message will ever get to its intended recipient.
          Some systems support some primitive return receipt
          mechanism, but there is no standard for this on the
          Internet. MX does not support any form of receipt
          acknowledgment.

          __________________________________________________________________

   1.7    Network Delivery Delays

          Messages sent over any network can be delayed due to
          network outages, system loading, or other reasons.
          Once a message leaves the local system, there is no
          way to determine where the message may be held up.
          However, messages still on the local system awaiting
          network transfer can be displayed with the MAILQUEUE
          utility:

          1-6

 


                             Using Message Exchange with VMS MAIL





              $ RUN MX_EXE:MAILQUEUE

          MAILQUEUE lists any messages you have sent that are
          waiting for network transfer. All messages that cannot
          be sent are tried periodically, based on settings
          established by your system manager. If the number of
          attempts exceeds the established limit, the message is
          returned to sender with a message explaining why the
          transfer did not occur.

          ___________________________

   1.7.1  Displaying MX Informational Messages

          If you want MX to display information messages
          indicating that your VMS Mail message has been
          successfully delivered to MX, you can define the
          logical MX_VMSMAIL_SHOW_INFO as shown in the following
          command:

              $ DEFINE MX_VMSMAIL_SHOW_INFO TRUE

          If the logical is defined, MX displays a line like the
          following when the message has been queued to MX:

              %MX-I-MAIDLVR, message (entry number 22643) successfully delivered to MX

          An informational message will also be displayed when a
          message is sent with SEND/FOREIGN:

              %MX-I-BASE64, encoding MX foreign message using BASE64

          Placing the MX_VMSMAIL_SHOW_INFO logical definition
          in your LOGIN.COM will cause MX to always display the
          informational messages.

          __________________________________________________________________

   1.8    Sending binary files to other VMS users

          The VMS Mail command SEND accepts an undocumented
          qualifier, /FOREIGN. SEND/FOREIGN allows you to mail
          any VMS file to another user on the same system or
          over DECnet. The file retains all of the VMS file
          attributes. When the recipient tries to read the mail

                                                              1-7

 


          Using Message Exchange with VMS MAIL





          message containing the file, the following information
          is displayed:

              #2          14-APR-1993 15:28:02.11             NEWMAIL
          From:   GOATHUNTER
          To:     GOATHUNTER
          CC:
          Subj:   RESET.EXE

          You cannot read this foreign format message
                  Use the EXTRACT command to copy the message to an external file

          MAIL>

          The EXTRACT command copies the message to the named
          external file with all VMS file attributes intact.

          The SEND/FOREIGN command can also be used to send
          VMS binary files through MX, if the target user is
          on a system running MX V3.3 or higher, MultiNet V3.3
          or higher, or PMDF V4.1 or higher. When SEND/FOREIGN
          is used, MX encodes the message using an algorithm
          called BASE64, which is defined in RFC 1341, a
          document describing MIME (Multipurpose Internet Mail
          Extensions). The BASE64-encoded file is wrapped in a
          MIME-compliant message and mailed to the recipients.
          When the message is received on a system running the
          appropriate versions of either MX, MultiNet, or PMDF,
          the encoded binary file is automatically decoded
          and mailed to the local user as a foreign file. The
          recipient will receive two messages-one containing the
          headers for the message, and the other containing the
          foreign file as shown above.

          The MIME ``Content-Type:'' for the file is
          ``APPLICATION/VMS-RMS''. MX will automatically
          recognize and decode incoming ``VMS-RMS'' files that
          are encoded using BASE64, as well as QUOTED-PRINTABLE
          files.

          Note: The encoding done by MX is only compatible with
          the VMS mailers specified above. SEND/FOREIGN cannot

          1-8

 


                             Using Message Exchange with VMS MAIL





          be used to send binary files to non-VMS MIME-compliant
          mailers.

          The following example demonstrates sending a binary
          file through MX:

              $ mail

              MAIL> send/noedit/foreign program.exe
              To:     MX%"gene@KISS.COM"
              Subj:   Here is that program I promised to send

              Encoding MX foreign message using BASE64
              Message (entry number 22244) successfully delivered to MX

              MAIL>

          Note: Non-VMS recipients or VMS recipients on systems
          not running the appropriate software will receive a
          single message containing the BASE64-encoded file.
          This message will most likely be meaningless for those
          recipients.

          From the DCL prompt, the command MAIL/FOREIGN can be
          used to send a binary file to one or more recipients:

              $ mail/foreign/subj="My LOGIN.COM" login.com "mx%""user@node.edu"""













                                                              1-9

 








          _______________________________________________________

   2      The MXALIAS Utility



          MXALIAS is a simple database manager for user-defined
          MX aliases. An alias is a name that is equated with
          a mail address that can be used to address electronic
          mail. For example, the address ``BOB'' can be equated
          with ``smithjb@node1.school.edu''; it can then be
          used in VMS Mail by specifying MX%BOB at the ``To:''
          prompt:

              MAIL> SEND
              To:     MX%BOB
              Subj:   ....

          MX aliases are stored, by default, in a file called
          MX_ALIAS_DATABASE.DAT in your login directory
          (SYS$LOGIN:). You can define the MX_ALIAS_DATABASE
          logical in your LOGIN.COM to relocate the database
          file:

              $ DEFINE MX_ALIAS_DATABASE dev:[user.MAIL]ALIASES.DAT

          MXALIAS will automatically create the MX alias
          database the first time you add an alias definition.

          MXALIAS can be executed by setting up a foreign symbol
          in your LOGIN.COM:

              $ mxalias :== $mx_exe:mxalias.exe

          Your system manager may have already defined it for
          you in the system login procedure. You can also just
          use RUN MX_EXE:MXALIAS to run MXALIAS.

          When MXALIAS is invoked without any parameters on the
          DCL command, your are put into an interactive mode.
          The prompt is ``MXalias>'':

                                                              2-1

 


          The MXALIAS Utility





              $ mxalias
              MXalias>

          At the MXALIAS prompt, you can ADD aliases, MODIFY
          them, REMOVE them, and list them using the DIRECTORY
          command. There is on-line help available by typing
          HELP at the MXalias> prompt.

          __________________________________________________________________

   2.1    Adding an MX Alias

          The MXALIAS command ADD is used to add an alias to
          the database. ADD takes three parameters: the alias
          to define, the equivalent address, and an optional
          description for the alias. The following example shows
          a typical definition:

              MXalias> add joe "smith@somewhere.com" "Joe Smith, Somewhere, Inc."
              Added alias JOE to MX alias database
              MXalias>

          The alias, JOE in the example above, can be a string
          of up to 20 alphanumeric characters (plus $, -, _,
          and .) that is equated with the given e-mail address.
          The alias is the address given to MX from the VMS Mail
          ``To:'' line using a format like MX%alias. All aliases
          are converted to uppercase.

          The given address must be a valid address in the form
          ``user@host''. If the domain is omitted, it defaults
          to the local host (as defined by the MX_VMSMAIL_
          LOCALHOST logical). The maximum length of the address
          is 255 characters. If you want to preserve the case
          of an address, or if the address contains the ``!''
          character, you must enclose the address in double-
          quotes. If the address includes quotes, the address
          should be quoted, with the inside quotes doubled
          ("""node::user""@domain").

          The description is any quoted string of up to 255
          characters. The description is displayed by the
          DIRECTORY command; it is not included in the mail
          headers of the outgoing message.

          2-2

 


                                              The MXALIAS Utility




          __________________________________________________________________

   2.2    Using an MX Alias

          Once an MX alias has been added to the MX alias
          database, it can be used on the VMS Mail ``To:'' line
          by simply prefixing the alias name with MX%. MX will
          check every address that does not include the ``@''
          character to see if it is an MX alias. For example, if
          JOE is defined as an alias, the following ``To:'' line
          would be specified:

              MAIL> SEND
              To:     MX%JOE
              Subj:   ....

          Sending to MX%``JOE@localhost'' will prevent MX from
          performing the alias translation, in case you want to
          send mail to a local user name JOE.

          ___________________________

   2.2.1  Displaying MX Address Translations

          To see the resulting addresses used by MX for all MX%
          addresses, define the logical MX_VMSMAIL_SHOW_ADDR as
          TRUE:

              $ define mx_vmsmail_show_addr true
              $ mail

              MAIL> SEND
              To:     MX%JOE, MX%"MX-List@WKUVX1.WKU.EDU", SYSTEM
                MX rewrote alias JOE as <SYSTEM@WKUVX1.WKU.EDU>
                MX rewrote MX-List@WKUVX1.WKU.EDU as <MX-List@WKUVX1.WKU.EDU>
              Subj:   ....

          The MX_VMSMAIL_SHOW_ADDR works regardless of whether
          or not MX aliases are specified. If you always want
          to see MX address translations, you can put the DEFINE
          command in your LOGIN.COM.

                                                              2-3

 


          The MXALIAS Utility




          ___________________________

   2.2.2  MX As the Default Mail Transport

          The undocumented VMS Mail command SET TRANSPORT can
          be used to establish MX as the default transport to be
          used for all mail messages. The format of the command
          is:

              MAIL> SET TRANSPORT MX%

          The MX% prefix can be omitted from MX aliases when the
          default transport has been set. Note that non-alias
          "user@domain" addresses must still be prefixed.

          The MAIL command SET NOTRANSPORT can be used to
          disable the default transport.

          Note: The SET TRANSPORT command is undocumented; its
          behavior could change with a future release of VMS.
          Also, once it has been set, all local mail will be
          delivered through MX.

          __________________________________________________________________

   2.3    Displaying Aliases

          The MXALIAS command DIRECTORY is used to display
          your defined aliases. By default, the brief directory
          listing shows only the alias and the comment, if there
          is one:

              MXalias> dir

              MX Alias              Description
              ------------          -----------
              JOE                   Joe Smith, Somewhere, Inc.

              MXalias>

          Wildcards can be given to limit the display to aliases
          matching the given pattern. The DIRECTORY/FULL command
          can be used to show the equivalent e-mail addresses.

          The /OUTPUT=file qualifier can be used to write the
          directory listing to a text file.

          2-4

 


                                              The MXALIAS Utility




          __________________________________________________________________

   2.4    Modifying Aliases

          The MODIFY command is used to modify an existing alias
          definition. It accepts the alias name as a parameter
          and the qualifiers /ADDRESS and /DESCRIPTION. For
          example:

              MXalias> MODIFY JOE/DESCRIPTION="Local system manager"
              Modified alias JOE
              MXalias>

          __________________________________________________________________

   2.5    Removing Aliases

          The REMOVE command is used to remove an alias
          definition from the MX alias database. By default,
          it prompts the user for confirmation before removing
          the specified alias:

              MXalias> remove joe
              Remove JOE <SYSTEM@WKUVX1.WKU.EDU> [N]? y
              Removed alias JOE
              MXalias>

          You can supply the qualifier /NOCONFIRM to override
          the confirmation prompt.












                                                              2-5

 








          _______________________________________________________

   3      Electronic Mailing Lists



          When talking about electronic mail, the term mailing
          list is generally used to describe an E-mail address
          that forwards messages to more than one user. Mailing
          lists abound on the Internet and BITNET, on a wide
          variety of technical and non-technical topics.

          Unfortunately, there are no standards on the
          implementation of mailing lists, so their use will
          vary depending on the systems on which the mailing
          lists are set up. For the most part however, mailing
          lists can be broken down into two basic types:
          Internet and BITNET.

          __________________________________________________________________

   3.1    Internet-Style Lists

          For an Internet-style mailing list, there are
          generally two addresses: one for the mailing list
          itself, and one for "administrivia" (subscription
          requests, etc.). The administrative address is usually
          the mailing list name with "-request" added. For
          example, the mailing list for discussing Message
          Exchange is MX-List@WKUVX1.WKU.EDU. Subscription
          requests, removals, or comments about the list are
          sent to MX-List-request@WKUVX1.WKU.EDU.

          Most Internet-style mailing lists are managed
          manually, so mail sent to -request addresses can
          usually be free-form. However, a few systems, MX
          included, have mailing list handlers which process
          some types of requests automatically, without human
          intervention. The syntax of the commands you send
          to these automated handlers will vary from system to
          system. For example, the MX mailing list processor
          accepts the following commands:

                                                              3-1

 


          Electronic Mailing Lists






          SUBSCRIBE          for getting added to the list

          SIGNOFF            for getting removed from the list

          REVIEW             for getting a list of the
                             subscribers

          HELP               for getting a help message

          QUERY              for getting the status of your
                             subscriber entry

          QUIT               for preventing the parsing of a
                             mail signature

          Commands must generally be placed in the body of a
          mail message, rather than on the Subject line.

          __________________________________________________________________

   3.2    BITNET-Style Lists

          Most mailing lists on BITNET hosts are implemented
          using LISTSERV, a package developed specifically for
          automated handling of mailing lists. One LISTSERV on
          a system, at address LISTSERV@hostname, manages all
          the mailing lists offered on that system, and provides
          automatic administrative request handling.

          LISTSERV will usually handle the following commands:

          SUBSCRIBE list-    for getting added to the list
          name

          SIGNOFF list-name  for getting removed from the list

          REVIEW list-name   for getting a list of the
                             subscribers

          QUERY list-name    for getting the status of your
                             subscriber entry

          HELP               for getting a help message

          LIST               for getting a list of available
                             mailing lists

          3-2

 


                                         Electronic Mailing Lists





          Along with several more. The MX mailing list
          processor, MXSERVER, also provides LISTSERV-style
          command handling, but supports only the commands
          listed above plus a QUIT command to prevent the
          unintentional parsing of a mail signature.



































                                                              3-3

 








          _______________________________________________________

   4      Network File Servers



          The term file server, for the purposes of this
          document, refers to a network entity that maintains a
          library of files and delivers them to users on demand.

          As with mailing lists, there are no standards for file
          servers. There are several file server implementations
          in existence: LISTSERV, VMSSERV, MAILSERV, and
          several others. MX also includes a file server module,
          generally referred to as FileServ. Some of these file
          servers accept commands via BITNET immediate messages,
          some only by E-mail messages. Some take commands on
          the subject line of a message, and some in the body of
          a message. The way files are distributed can also vary
          from server to server.

          __________________________________________________________________

   4.1    Get HELP

          If you want to obtain files from a file server, and
          you are unsure of the commands you need to use, you
          should begin by requesting help information from the
          server. The best way to do this is to send an E-mail
          message to the file server's address with the word
          HELP on the subject line and on the first and only
          line of the body of the message. Most servers will
          mail you back a message listing the commands they
          accept and the format the commands should take, along
          with other helpful information.

          If you cannot get assistance from the file server
          itself, you may be able to get some from the
          postmaster on the file server's system.

                                                              4-1

 


          Network File Servers




          __________________________________________________________________

   4.2    MX FileServ Commands

          The MX file server, usually called FileServ, accepts
          commands, one command per line, in the body of an
          E-mail message. The commands it accepts are:

          ADDRESS valid-     provides a valid e-mail address
          address

          LIST [pattern]     lists all packages matching
                             "pattern"

          DIRECTORY          same as LIST
          [pattern]

          SENDME             sends an entire package or the
          package[.part]     specified part

          HELP               sends a help message

          QUIT               causes any lines following this
                             command to be ignored

          FileServ commands may be abbreviated to their shortest
          unique string.

          ADDRESS provides the user with the ability to specify
          a valid RFC822-compliant e-mail address to which any
          FileServ output is to be sent. Normally, any files
          requested from FileServ are sent to the address in
          the ``Reply-To:'' or ``From:'' lines in the message
          headers. However, addresses are sometimes corrupted by
          gateways through which the message passes, resulting
          in an invalid return address. File server users can
          use the ADDRESS command to provide a valid alternate
          to the ``From:'' address.

          Note: When an ADDRESS command is processed, the file
          server transaction log includes the original ``From:''
          address. Any user receiving unasked-for files can use
          it to determine from whom the request came.

          4-2

 


                                             Network File Servers




          ___________________________

   4.2.1  Packages

          A package is a collection of related files that are
          grouped together distribution. FileServ, along with
          other file servers, distributes files in packages.
          These packages are usually in a special format for
          distribution over the network via E-mail; once you
          collect all of the parts in a package, the parts are
          combined together and fed through an unpacking program
          (sometimes contained within the package itself) to
          recreate the original collection of files.

          ___________________________

   4.2.2  Binary Files

          Because E-mail systems generally do not properly
          handle binary data, binary files (such as executable
          images or compressed files) are generally encoded
          before being packaged and distributed by a file
          server. Once unloaded from the package, the encoded
          file must then be decoded to recreate the binary file.
          The type of encoding will vary from system to system.

          In addition, large files may be compressed before
          being encoded and packaged, to cut down on the
          network bandwidth required when transmitting the
          package. Restoring the original files then requires
          an additional decompression program.










                                                              4-3

 








          _______________________________________________________

   A      Message Header Format



          Most network mail systems require or include more
          information about messages than VMS MAIL can handle.
          MX, for example, follows the Internet message format
          standard, usually called RFC 822 after the number of
          the document that describes the format.

          When you receive a message via MX, the FROM address
          identified in the VMS MAIL headers will begin with the
          MX% prefix, which allows you to REPLY to the message.
          In addition to the VMS MAIL headers, you will also
          see the RFC 822 header information, which is usually
          displayed as the first part of the message text (this
          is under the control of the system manager). For
          example:

                  #1          29-FEB-1992 10:36:22.11                       NEWMAIL
              From:   MX%"idiot@myhost.mycompany.com"
              To:     MADISON
              CC:
              Subj:   Question














                                                              A-1

 


          Message Header Format





              Return-Path: <idiot@myhost.mycompany.com>
              Received: from myhost.mycompany.com by mgrsta.mycompany.com (MX V3.0);
                        Thu, 29 Feb 1992 10:35:10 EST
              Received: by myhost.mycompany.com (MX V3.0) id 31437; Thu, 29 Feb 1992
                        10:35:05 EST
              Resent-Date: Thu, 29 Feb 1992 10:35:01 EST
              Resent-From: system@myhost.mycompany.com
              Resent-To: manager@mgrsta.mycompany.com
              Sender: <idiot@myhost.mycompany.com>
              Date: Thu, 29 Feb 1992 10:34:55 EST
              From: Idiot User <idiot@myhost.mycompany.com>
              Reply-To: idiot@myhost.mycompany.com
              Message-ID: <00933068.08a17f00.31437@myhost.mycompany.com>
              To: system@myhost.mycompany.com
              Subject: Question

              How do I send E-mail?

          The first five lines of this message are the VMS MAIL
          headers. The message text starts with the RFC 822
          headers, followed by the message itself. The following
          sections explain the meaning of the RFC 822 headers.

          Return-Path. The return address as appears on the
          envelope of the message. This usually identifies the
          route the message took in getting to you, and can be
          used to identify forged messages in some cases. The
          return path is used as the VMS MAIL From address if no
          other address is available.

          Received. There may be several of these lines for
          a message. They usually indicate how and when the
          message was transferred from one system to another.
          They are provided for informational purposes only.

          Resent- lines. If the message is forwarded (usually by
          an automatic mechanism such as SET FORWARD in VMS
          MAIL), some messaging systems (MX included) will
          include information about when it was forwarded and
          who it was forwarded to. One set of Resent lines
          usually appears for each forwarding hop.

          A-2

 


                                            Message Header Format





          Sender. This line indicates the sender of the message,
          which could be different from the address in the From
          line.

          Date. This line indicates the date and time the
          message was entered into the mail system by the
          sender. It will usually include the local time for
          the sender, which may be in a different time zone.

          From. This line indicates who the message is from.
          If the message was sent by someone on behalf of
          another person or group, the message will also include
          a Sender line to identify the person or agent who
          actually sent the message.

          Reply-To. If the sender wants to receive replies at
          an address different from the From address, a Reply-To
          line will be included to redirect the replies.

          Message-ID. The message identifier uniquely identifies
          a message. Message-ID's are used by some mail systems
          for tracking messages and replies.

          To. Identifies the target user or users for the
          message. Also included can be CC and BCC lines that
          identify users to whom a carbon copy and "blind"
          carbon copy of the message is sent.

          Subject. A brief description of the subject of the
          message.

          Other headers are also possible, some of which are
          extensions to the RFC 822 message standard. Also, the
          order in which the headers appear may vary from system
          to system.

          __________________________________________________________________

   A.1    VMS MAIL Headers

          MX automatically translates some of the RFC 822 header
          information into VMS MAIL headers.

                                                              A-3

 


          Message Header Format




          ___________________________

   A.1.1  From Header

          There are several RFC 822 headers used for identifying
          the originator of a message. VMS MAIL, however, allows
          only one. To allow the REPLY command to work properly,
          therefore, MX fills in the VMS MAIL From line with
          the address that should be used in generating a
          reply. This reply address is selected from one of
          the following header lines, listed here in order of
          preference:

          1  Reply-To

          2  From

          3  Sender

          4  Return-Path

          MX will only use the address from one of these headers
          if it is syntactically valid. Since most mail systems
          provide a valid address in the Reply-To and/or From
          headers, this should not be a problem.

          ___________________________

   A.1.2  To and CC Headers

          The VMS MAIL To and CC headers will list only the
          users on the local system receiving the message. To
          see the actual list of recipients, examine the To, CC,
          and BCC lines in the RFC 822 headers.

          ___________________________

   A.1.3  Subject Header

          The VMS MAIL Subject header should be identical to the
          RFC 822 Subject header, if one exists.

          A-4
