 


















          Message Exchange Mailing List/File
          Server 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 1994

          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                                       vii

          _______________________________________________________
          CHAPTER 1  THE MAILING LIST/FILE SERVER             1-1

                _________________________________________________
                1.1   MAILING LISTS                           1-1

                _________________________________________________
                1.2   FILE SERVERS                            1-2


          _______________________________________________________
          CHAPTER 2  USING MLF_CONFIG.COM                     2-1

                _________________________________________________
                2.1   LIST SERVER MANAGERS                    2-1

                _________________________________________________
                2.2   MAILING LISTS                           2-2

                _________________________________________________
                2.3   FILE SERVERS                            2-2

                _________________________________________________
                2.4   USING THE RESULTS                       2-3


          _______________________________________________________
          CHAPTER 3  MAILING LISTS                            3-1

                _________________________________________________
                3.1   ARCHIVES                                3-1




                                                              iii

 


          Contents





                _________________________________________________
                3.2   PROTECTION CODES                        3-2

                _________________________________________________
                3.3   AUTOMATIC REQUEST HANDLING              3-4

                3.3.1     Control Commands  ______________    3-7

                _________________________________________________
                3.4   USER NOTIFICATION MESSAGES              3-7

                _________________________________________________
                3.5   VMS MAIL FORWARDING                     3-9

                _________________________________________________
                3.6   USING THE ADD AND REMOVE COMMANDS       3-9

                3.6.1     ADD  ___________________________    3-9

                3.6.2     REMOVE  ________________________   3-12

                _________________________________________________
                3.7   DELETING A MAILING LIST                3-13

                _________________________________________________
                3.8   MAILING LIST DIGEST SUPPORT            3-13

          _______________________________________________________
          CHAPTER 4  FILE SERVERS                             4-1

                _________________________________________________
                4.1   PACKAGES                                4-1

                _________________________________________________
                4.2   HELP FILE                               4-3

                _________________________________________________
                4.3   TRANSACTION LOGS                        4-3


          iv

 


                                                         Contents





                _________________________________________________
                4.4   FILE SERVER COMMANDS                    4-4


          _______________________________________________________
          APPENDIX A  TROUBLESHOOTING MLF PROBLEMS            A-1

                _________________________________________________
                A.1   CASE SENSITIVITY                        A-1


          _______________________________________________________
          APPENDIX B  EXAMPLE: MAILING LIST WITH ARCHIVE
                      SERVER                                  B-1


          _______________________________________________________
          TABLES

                3-1       Mailing list protection
                          classes  _______________________    3-2

                3-2       Mailing list protection codes  _    3-2

                3-3       Typical protection codes  ______    3-3

                3-4       MLF -Request commands  _________    3-4

                3-5       MLF MXSERVER commands  _________    3-5

                3-6       User notification messages  ____    3-7









                                                                v

 







          _______________________________________________________

          Preface

          This guide describes the management and operation
          of the Message Exchange Mailing List/File Server (MX
          MLF).

          __________________________________________________________________

          Intended Audience

          This manual is intended for use by the system
          manager or any individual responsible for installing
          and maintaining MX, and for users responsible for
          creating or managing MX-based mailing lists and file
          servers. The reader should be generally familiar
          with VMS system concepts, electronic mail systems and
          networking terminology.

          __________________________________________________________________

          Document Structure

          This guide consists of

          Chapter    Contains a general description of MLF.
          1

          Chapter    Describes how to use the MLF_CONFIG
          2          procedure.

          Chapter    Describes how to manage a mailing list.
          3

          Chapter    Describes how to manage a file server.
          4

          __________________________________________________________________

          Related Documents

          You can find additional information in the following
          documents:

          o  Message Exchange Management Guide describes how to
             manage MX and contains the command dictionary for
             the MX Control Program (MCP).

                                                              vii

 


          Preface





          o  Message Exchange User's Guide describes MX features
             available to general users.






































          viii

 








          _______________________________________________________

   1      The Mailing List/File Server



          Message Exchange (MX) includes a program called the
          Mailing List/File Server (MLF). This program provides
          the services needed to distribute messages to mailing
          lists and manage those lists through mailed commands.
          It also provides services for distributing packages of
          files by electronic mail.

          __________________________________________________________________

   1.1    Mailing Lists

          When talking about electronic mail, the term mailing
          list is generally used to describe an E-mail address
          that forwards messages to one or more subscribers.
          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.

          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.

                                                              1-1

 


          The Mailing List/File Server





          Most mailing lists on BITNET hosts are implemented
          using Eric Thomas's 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.

          MLF provides support for both the Internet -request
          interface and the BITNET LISTSERV interface for its
          automatic command handling. The special addresses
          MXSERVER and MXSERV are recognized by MX Router as
          the MLF LISTSERV-style interface. If you also want
          LISTSERV to be recognized, then you must define it
          as an alias using the MCP command DEFINE ALIAS. For
          example:

              MCP> DEFINE ALIAS LISTSERV "MXserver@hostname"

          __________________________________________________________________

   1.2    File Servers

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

          The MLF file server command interface accepts commands
          by E-mail only, and returns files only by E-mail.

          MX allows the use of any name for the file server;
          FileServ is commonly used.


          1-2

 








          _______________________________________________________

   2      Using MLF_CONFIG.COM



          MLF comes with a command procedure, MLF_CONFIG.COM,
          which is placed at installation time in the MX_DIR:
          directory. This command procedure uses a simple
          question-and-answer script to develop the MCP commands
          needed to create mailing lists and file servers.

          __________________________________________________________________

   2.1    List Server Managers

          MLF_CONFIG begins by reading in your current MX
          configuration and checking to see if you have any
          list server managers (called SYSTEM_USERS in MCP)
          defined. If not, MLF_CONFIG will prompt you first for
          the primary list server manager's address, followed by
          any other users who should be given manager access to
          mailing lists.

          List server managers are granted control access to
          all mailing lists on the system, allowing them to use
          the ADD and REMOVE commands. In addition, they are
          granted access through the SYSTEM protection class on
          all mailing lists.

          Note: Unless the list is defined with /NOCASE_
          SENSITIVE, the mailing list processor is case
          sensitive when matching the username portion of
          addresses. Be sure to enter the list manager addresses
          using the correct case. MX, by default, converts all
          usernames to lower case for local users, so you should
          generally use lower case when specifying local list
          managers' addresses.


                                                              2-1

 


          Using MLF_CONFIG.COM





          Primary List Server Manager

          The first address on the SYSTEM_USERS list is for
          the primary list server manager. The primary list
          server manager's address is used as the return address
          for non-list-related mail messages sent by MLF. If
          you would rather not have an actual person's E-mail
          address be used for that purpose, you should set up an
          alias.

          __________________________________________________________________

   2.2    Mailing Lists

          Once you have defined your list server managers, or if
          they were already defined before you ran MLF_CONFIG,
          you can then set up one or more mailing lists. MLF_
          CONFIG will prompt you for the name of the mailing
          list and the address of the owner of the list, which
          are required. It will then prompt you for the optional
          information related to the list.

          To move on to the File Server section of MLF_CONFIG,
          just press RETURN when prompted for a mailing list
          name.

          Note: Unless the list is defined with /NOCASE_
          SENSITIVE, the mailing list processor is case
          sensitive when matching the username portion of
          addresses. Be sure to enter the owner addresses
          using the correct case. MX, by default, converts all
          usernames to lower case for local users, so you should
          generally use lower case when specifying local owner
          addresses.

          __________________________________________________________________

   2.3    File Servers

          After the mailing lists phase, MLF_CONFIG will ask
          you about file servers. To create a file server, you
          must specify the name, manager's address, and the
          device and directory that will serve as the root of
          the file server. MLF_CONFIG will prompt you for this

          2-2

 


                                             Using MLF_CONFIG.COM





          information, and will create the root directory for
          you, if you wish. It will then prompt for optional
          information regarding the file server.

          __________________________________________________________________

   2.4    Using the Results

          When MLF_CONFIG finishes, it leaves you with an
          MCP command file, called MX_DIR:MLF_CONFIG.MCP by
          default. You should review the contents of that
          file; if satisfied with the results, you should then
          execute the command file in MCP, save the resulting
          configuration information, then reset the Router and
          MLF processes to have the new mailing lists and file
          servers recognized:

              $ MCP
              MCP> @MLF_CONFIG.MCP
              MCP> SAVE
              MCP> RESET/CLUSTER ROUTER,MLF

          Your newly-created mailing lists and file servers will
          then be ready.
















                                                              2-3

 








          _______________________________________________________

   3      Mailing Lists



          The MCP DEFINE LIST command is used to create a
          mailing list. The mailing list processor supports
          the automatic archiving of mailing list messages,
          automatic subscription processing, and limited remote
          control of mailing lists. In addition, mailing lists
          can be protected in a variety of ways to restrict the
          automatic subscription facility as well as postings to
          t|e list.
           |
          F|ur local addresses are set up for each mailing list:
          o|e for the list itself, a request address (list-name-
          R|QUEST), an owner address (owner-list-name), and a
          d|gest address (list-name-digest) for those lists
          s|pporting digests. The mailing list processor accepts
          subscription requests and other control messages on a
          list's request address.

          The list of subscribers is maintained by the MLF agent
          in the file MX_MLIST_DIR:list-name.MAILING_LIST. The
          format used for this file is not readable by humans;
          you should use the list server command interface
          or the MCP REVIEW command to examine the subscriber
          list.

          __________________________________________________________________

   3.1    Archives

          A mailing list is archived automatically by the
          mailing list processor when the /ARCHIVE qualifier
          is used on the DEFINE LIST command. You must specify
          at least a device and directory for the archive. The
          file name for the archive defaults to the name of
          the mailing list, and the file type for the archive
          defaults to yyyy-mm, the current year and month. By

                                                              3-1

 


          Mailing Lists





          keeping with the default, a new archive file will be
          created every month.

          __________________________________________________________________

   3.2    Protection Codes

          The standard VMS protection code syntax is used to
          describe access to mailing lists. Table 3-1 describes
          how each of the protection classes relates to mailing
          lists, and Table 3-2 describes the protection codes.

          Table_3-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___________________________

          Table_3-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 Enroll access is only meaningful to WORLD-
          class users, and Delete access is only meaningful
          to GROUP-class users. For most, if not all, mailing
          lists, you should grant RWED access to both SYSTEM

          3-2

 


                                                    Mailing Lists





          and OWNER classes. SYSTEM and OWNER also implicitly
          have Control access, allowing them to add and remove
          other users from the mailing list. Some typical
          protection codes for GROUP and WORLD users are given
          in Table 3-3.

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

          By default, information about all defined mailing
          lists is returned to a user in response to a DIRECTORY
          command sent to MXSERVER or a -Request address. The
          /PRIVATE qualifier can be given on the DEFINE LIST
          command to prevent information about a list from being
          included in MXSERVER directories. The list information
          will only include those lists that are not marked
          /PRIVATE.

                                                              3-3

 


          Mailing Lists




          __________________________________________________________________

   3.3    Automatic Request Handling

          MLF will answer requests automatically at both a
          list's -Request address and through the MXSERVER
          interface. The commands it recognizes through the -
          Request interface are listed in Table 3-4. MXSERVER
          commands are listed in Table 3-5.

          Table_3-4__MLF_-Request_commands_______________________

          Command_________________Description____________________

          ADD address[,...]       Control command: allows list
                                  owner to add other users to the
                                  list.

          HELP                    Sends file MX_MLIST_DIR:MLIST_
                                  HELP.TXT.

          LIST                    Lists all available non-private
                                  mailing lists.

          QUERY                   Returns the subscriber's status
                                  on the list.

          QUIT                    Causes all remaining lines in
                                  the message to be ignored.

          REMOVE address[,...]    Control command: allows list
                                  owner to remove other users
                                  from the list.

          REVIEW                  Returns the list of
                                  subscribers.

          SET [NO]MAIL            Enables/disables receipt of
                                  list messages.

          SET [NO]CONCEAL         Controls whether subscriber is
                                  concealed from view in REVIEW
                                  listings.

          SET [NO]REPRO           Controls whether subscriber
                                  receives a posting s/he makes
                                  to the mailing list.

          3-4

 


                                                    Mailing Lists





          T|ble_3-4_(Cont.)__MLF_-Request_commands_______________
           |
          C|mmand_________________Description____________________
           |
          S|T [NO]DIGEST          Controls whether subscriber
           |                      receives all posts or a daily
           |                      digest of posts to a list.

          SIGNOFF                 Removes the user from the list
                                  of subscribers.

          SUBSCRIBE               Adds the user to the subscriber
          ________________________list.__________________________

          Table_3-5__MLF_MXSERVER_commands_______________________

          Command_________________Description____________________

          ADD list-name           Control command: allows list
          address[,...]           owner to add other users to the
                                  list.

          HELP                    Sends file MX_MLIST_DIR:MLIST_
                                  HELP.TXT.

          LIST                    Lists all available non-private
                                  mailing lists.

          QUERY list-name         Returns the subscriber's status
                                  on the list.

          QUIT                    Causes all remaining lines in
                                  the message to be ignored.

          REMOVE list-name        Control command: allows list
          address[,...]           owner to remove other users
                                  from the list.

          REVIEW list-name        Returns the list of
                                  subscribers.

          SET list-name           Enables/disables receipt of
          [NO]MAIL                list messages.

                                                              3-5

 


          Mailing Lists





          Table_3-5_(Cont.)__MLF_MXSERVER_commands_______________

          Command_________________Description____________________

          SET list-name           Controls whether subscriber is
          [NO]CONCEAL             concealed from view in REVIEW
                                  listings.

          SET list-name           Controls whether the subscriber
          [NO]REPRO               receives a posting s/he makes
                                  to the mailing list.
           |
          S|T list-name           Controls whether subscriber
          [|O]DIGEST              receives all posts or a daily
           |                      digest of posts to a list.

          SIGNOFF list-name       Removes the user from the list
                                  of subscribers.

          SUBSCRIBE list-name     Adds the user to the subscriber
          ________________________list.__________________________

          SUBSCRIBE requests are handled automatically only
          if the WORLD protection class is granted E (Enroll)
          access to the list. Otherwise, they are forwarded to
          the list owners for manual handling.

          SIGNOFF requests are handled automatically only if the
          GROUP protection class is granted D (Delete) access
          to the list. Otherwise, they are forwarded to the list
          owners for manual handling.

          REVIEW requests are handled automatically only if
          the requesting user is granted R (Read) access to the
          list. Read access may be granted only to GROUP (i.e.,
          the subscribers of the list) or to GROUP and WORLD.
          If access is denied, the request is returned with an
          error message.


          3-6

 


                                                    Mailing Lists




          ___________________________

   3.3.1  Control Commands

          The mailing list processor currently supports two
          control requests: ADD and REMOVE. They may be used by
          the owners of a mailing list to add and remove other
          users to and from the list of subscribers.

          The owners of a mailing list also receive the
          full list of subscribers when they REVIEW their
          list, regardless of the CONCEAL setting of each
          subscriber. Non-owners receive a list consisting of
          subscribers who have not set the CONCEAL flag for
          their subscription to the list.

          __________________________________________________________________

   3.4    User Notification Messages

          You can control the text of the message that is sent
          to the user when he or she subscribes or signs off
          from a mailing list, on a per-list and/or global
          basis. Table 3-6 lists the types of messages you can
          set up and when they are sent.

          Table_3-6__User_notification_messages__________________

          Per-list
          qualifier__________Global_default__________When_sent___

          /ADD_MESSAGE       MLIST_ADD_MESSAGE.TXT   when a user
                                                     is added to
                                                     a mailing
                                                     list

          /REMOVE_MESSAGE    MLIST_REMOVE_           when a user
                             MESSAGE.TXT             is removed
                                                     from a
                                                     mailing
                                                     list

                                                              3-7

 


          Mailing Lists





          Table_3-6_(Cont.)__User_notification_messages__________

          Per-list
          qualifier__________Global_default__________When_sent___

          /FORWARD_MESSAGE   MLIST_FORWARD_          when a user
                             MESSAGE.TXT             attempts to
                                                     subscribe
                                                     to a list
                                                     with no W:E
          ___________________________________________access______

          The global default message files are located in MX_
          MLIST_DIR. You can customize these files to suit your
          site's needs for all mailing lists, or use them as
          templates for the per-list files.

          Customization Variables

          The text of a notification message can contain
          references to customization "variables" whose values
          are supplied by the mailing list processor. Available
          variables are:

          {list-address}     the RFC822 address of the mailing
                             list

          {request-address}  the RFC822 address of the list's
                             -Request address

          {list-name}        the name of the mailing list (no
                             @hostname)

          {list-desc}        the contents of the list
                             description, as specified by the
                             /DESCRIPTION qualifier on the
                             DEFINE LIST command

          {list-owner}       the address of the owner of the
                             mailing list (if there are multiple
                             owner addresses, only the first is
                             used)

          3-8

 


                                                    Mailing Lists





          Note that each variable name must be surrounded
          by curly braces to be recognized. All other text
          (including unrecognized variable references) is sent
          verbatim.

          __________________________________________________________________

   3.5    VMS Mail Forwarding

          You can make it easier for local users and DECnet-
          connected users to send messages to a mailing list by
          creating a forwarding address in VMS Mail for the list
          name:

              $ MAIL
              MAIL> SET FORWARD/USER=list-name MX%list-name

          This will allow users to use just the list name when
          addressing the mailing list, without the MX% prefix.

          If the list name ever changes or the list is deleted,
          you should remember to remove the forwarding address
          from VMS Mail for the list name:

              MAIL> REMOVE list-name

          This will prevent a possible mail looping problem from
          occurring.

          __________________________________________________________________

   3.6    Using the ADD and REMOVE Commands

          The list processor provides two commands for use
          exclusively by list owners and list server managers:
          ADD and REMOVE.

          ___________________________

   3.6.1  ADD

          The ADD command adds other users to a mailing list.
          The syntax for this command for the -Request interface
          i|:
           |
           |                 ADD [/NONOTIFY] [/NOMAIL] [/NOCASE] [/CONCEAL] [/NOREPRO] [/ACCESS] [/DIGEST] [/DENY] address [,...]

          The syntax for the MXSERVER interface is:

                                                              3-9

 


          Mailing Lists





                             ADD [/NONOTIFY]  list-name  address [,...]

          You may specify multiple addresses to be added by
          separating the list with commas, but note that the
          entire command must fit on one line in the E-mail
          message.

          For address, you should enter the RFC822-type address
          for the user to be added. It should generally appear
          exactly as it does on the From line of a message,
          since the mailing list processor is case sensitive in
          the username part of addresses. You may include the
          personal name, if desired: ADD/NONOTIFY "Joe User"
          <user@host.site.domain>

          Use the /NONOTIFY qualifier when you do not want the
          new subscribers to receive the "you have been added"
          message for the mailing list:

          The /NOMAIL qualifier is used to add the user to the
          mailing list as a NOMAIL subscriber. That is, the
          user is on the list without receiving any mail from
          the list. NOMAIL subscriptions are used for private
          mailing lists, where only the subscribers are allowed
          to post, and for mailing lists that control access
          to file servers; a subscriber might have multiple
          addresses and may need access to the list or file
          server from any of those addresses.

          The /NOCASE qualifier is used to add the user to the
          mailing list while having the list processor disregard
          the case of the username portion of the address.
          Normally, the list processor is case-sensitive
          regarding usernames unless the list was defined with
          DEFINE LIST/NOCASE_SENSITIVE.

          The /CONCEAL qualifier is used to set the CONCEAL flag
          in the subscriber's entry in the list. CONCEALed users
          do not appear in REVIEW listings, except for those
          requested by the list owners.

          3-10

 


                                                    Mailing Lists





          The /NOREPRO qualifier is used to prevent the
          subscriber from receiving a copy of postings s/he
          m|kes to the list.
           |
          T|e /DIGEST qualifier is used to mark the subscriber
          e|try so that it will receive mailing lists posts
          m|de to the "-digest" address for a list. For more
          i|formation on digests, see Section 3.8.
           |
          T|e /DENY qualifier can be used to add a subscriber
          t| a closed mailing list (one which does not allow
          W|RLD writes) and still prevent that subscriber from
          p|sting to the list, thus denying the subscriber
          a|cess to the list. Subscribers with the DENY flag
          s|t cannot post to the list, will not receive posts
          t| the list, cannot change their subscriber entry, and
          c|nnot remove themselves from the list.
           |
          T|e DENY setting was added specifically to provide
          t|e list owner with the ability to keep problem
          s|bscribers from accessing the list.

          The /ACCESS qualifier is used to establish an access
          control address for the list. Access control addresses
          can be used to provide normal VMS wildcard matching
          for determining access to a mailing list. Any address
          that matches an access control entry is granted
          the corresponding GROUP privileges for the list.
          For example, if a list is open to posts only from
          members of the list, an access control address can be
          specified to allow any user from a particular site to
          post a message.

          In addition, file servers, described in Chapter 4,
          can be set up so that they are associated with a
          mailing list. Any user wishing to use such a file
          server must be subscribed to the associated mailing
          list, or access to the file server will be denied. The
          /ACCESS qualifier provides a way to allow unrestricted
          file server access to certain addresses without having
          to subscribe every possible address to the mailing
          list.

                                                             3-11

 


          Mailing Lists





          For example, suppose you have a file server that is
          to be used only by users from systems at XYZ.COM and
          YYZ.COM. Instead of listing each possible user at both
          sites, ACCESS entries can be made to the list that
          will match users at those sites:

              ADD/ACCESS/NOCASE <*@*.XYZ.COM>
              ADD/ACCESS/CONCEAL <*@*.YYZ.COM>

          These addresses are automatically marked /NOMAIL and
          /NOREPRO so that they never receive messages posted
          to the mailing list. They also never receive any
          notifications when added to or removed from the list.
          The /NOCASE and /CONCEAL qualifiers may be given as
          desired.

          Subscriber reviews of lists containing access control
          entries show those entries as having the ACCESS
          attribute.

          Note that the MXSERVER ADD command supports only the
          /NONOTIFY qualifier.

          ___________________________

   3.6.2  REMOVE

          The REMOVE command removes other users from a mailing
          list. The syntax for this command for the -Request
          i|terface is:
           |
           |                 REMOVE [/NONOTIFY] [/NOCASE] address [,...]

          The syntax for the MXSERVER interface is:

                             REMOVE [/NONOTIFY]  list-name  address [,...]

          You may specify multiple addresses to be added by
          separating the list with commas, but note that the
          entire command must fit on one line in the E-mail
          message.

          3-12

 


                                                    Mailing Lists





          For address, you should enter the RFC822-type address
          for the user to be removed. It should appear exactly
          as it does in the subscriber list (use the REVIEW
          command to check this). You may include the personal
          name, if desired, but only the address part is checked
          when MLF does the removal.

          Use the /NONOTIFY qualifier when you do not want the
          subscribers to receive the "you have been removed"
          m|ssage for the mailing list.
           |
          T|e /NOCASE qualifier is used to remove the user from
          t|e mailing list while having the list processor
          d|sregard the case of the username portion of the
          a|dress. Normally, the list processor is case-
          s|nsitive regarding usernames unless the list was
          d|fined with DEFINE LIST/NOCASE_SENSITIVE.

          __________________________________________________________________

   3.7    Deleting a Mailing List

          The MCP REMOVE LIST command removes the definition of
          a mailing list from the MX configuration database. The
          file containing the list of subscribers will remain
          after the definition is removed, however. You should
          delete that file also:

              $ DELETE MX_MLIST_DIR:list-name.MAILING_LIST;*

          You should also remember to delete any add, remove, or
          forward message files you set up for the mailing list
          a| creation time.

          __________________________________________________________________

   3.8    Mailing List Digest Support

          T|e MX MLF processor supports mailing list digests
          i| that subscriber entries can be marked "DIGEST" and
          m|il sent to a "-digest" list address (for example,
          "|ist-digest") will be forwarded only to those
          s|bscribers. Digest subscribers do not receive posts
          m|de to the standard mailing list address.

                                                             3-13

 


          Mailing Lists





          M| MLF does not provide any support for creating the
          m|iling list digests. However, the MX_ROOT:[CONTRIB]
          d|rectory does contain a package, MX_DIGEST, for
          c|eating digests. You can use MX_DIGEST to implement
          m|iling list digests, or you can supply your own
          s|ftware to do so.
           |
          A|l digest posts should be mailed to the "-digest"
          a|dress for the list. For example, digests for "MX-
          L|st" would be mailed to "MX-List-Digest". Only the
          l|st owner(s) and system user(s) can post to the "-
          d|gest" address. All other posts are treated as if
          t|ey had been address to the standard list.



























          3-14

 








          _______________________________________________________

   4      File Servers



          The MCP DEFINE FILE_SERVER command is used to set
          up a file server. Each file server can automatically
          service requests for single files or groups of files.
          Large files can be delayed to non-prime-time hours,
          on a per-server basis. You can specify a per-server,
          per-host, and/or per-user byte count limit, to prevent
          users from overtaxing the mail system with file server
          requests. In addition, you can link a file server
          to a mailing list, so that only those users who are
          subscribed to the list can gain access to the file
          server.

          Access control entries in a mailing list can be used
          to allow any user at particular sites to access the
          file server. See Section 3.6.1 for more information on
          access control entries.

          __________________________________________________________________

   4.1    Packages

          The file server is designed to handle groups of files,
          called packages. When you create a package, you create
          a directory with the name of that package; all files
          in that directory that are to be shipped when the
          package is requested must have file names that are the
          same as the package name.

          In addition, you must place a description file
          either above the package directory or in the package
          directory itself. This description file is sent when a
          user requests a listing of available packages.

          The description file must be named
          package.DESCRIPTION, where package is again the
          package name.

                                                              4-1

 


          File Servers





          This structure works best when you use a program such
          as VMS_SHARE to put together your packages. VMS_SHARE
          is readily available around the Internet and BITNET.
          It is used to collect together text files, format
          them so as to improve the chances of their being
          transferable through most mail systems, and split them
          up into easily mailable chunks. When all the chunks
          are put together on the receiving end, they form a DCL
          command procedure that re-creates the original files.

          Example

          To demonstrate the structure used by the file server,
          let us suppose you have created a package called
          STUFF. You used VMS_SHARE to create the package, which
          split the package into three parts.

          First, you would create a directory for the package:

              $ CREATE/DIRECTORY disk:[FILESERV.STUFF]

          Next, you would copy the VMS_SHARE files into that
          directory. They must have file names the same as the
          package name:

              $ COPY STUFF.* disk:[FILESERV.STUFF]

          Next, you would create a file containing a brief
          description of the package and place it above the
          STUFF directory:

              $ EDIT disk:[FILESERV]STUFF.DESCRIPTION

          If you prefer, the .DESCRIPTION files for all
          packages under [FILESERV] can be placed in the package
          directories with the other files. However, description
          files cannot be located in both places.

          Finally, you would need to set up the file server in
          MCP:

              MCP> DEFINE FILE_SERVER FILESERV/ROOT=disk:[FILESERV.]

          The file server FILESERV will now automatically handle
          distribution of the STUFF package.

          4-2

 


                                                     File Servers




          __________________________________________________________________

   4.2    Help File

          The file FILESERV_HELP.TXT, provided by the
          installation procedure in directory MX_ROOT:[MLF],
          contains a description of the file service commands.
          You should update this file to include the address
          you have chosen for your file server and any other
          information specific to the file server that you
          wish to include. Place the edited copy in the root
          directory of your file server to have it sent when a
          user sends a HELP command to your file server.

          __________________________________________________________________

   4.3    Transaction Logs

          For each mail message received by the file server, a
          transaction log is created that contains the results
          of each command in the message. When all commands have
          been processed, this transaction log is mailed back
          to the user. The transaction log lets the user know
          the status of the files requested, for example, when
          they'll be mailed, if the file server has been defined
          to delay files to off-hours times.

          If you have important information that you want all
          users accessing your file server to see, you can
          create a file called FILESERV_TRANSACTION.TXT that
          contains the text. When this file is placed in the
          root directory for the file server, its contents will
          be included at the beginning of every transaction log
          mailed out. This transaction header can be useful for
          letting users know of scheduled downtimes or a change
          in package availability, for example.





                                                              4-3

 


          File Servers




          __________________________________________________________________

   4.4    File Server Commands

          The five commands accepted by the file server are
          SENDME, LIST (or DIRECTORY), HELP, QUIT, and ADDRESS.
          Each may be abbreviated to the smallest unique string.
          One command is allowed per line of text in a request
          message, but several command lines may be sent in one
          request.

          SENDME takes either a package name (to have all parts
          of a package sent) or a file name (to have just one
          part sent). Large files are delayed until non-prime-
          time hours if enabled when file service is set up.

          LIST takes a pattern which is used to match against
          package names. The description file for each matching
          package is added to a message that is returned to the
          requesting user. If no pattern is specified, "*" is
          used.

          HELP causes the file FILESERV_HELP.TXT (located in the
          root directory of the file server) to be sent to the
          requesting user.

          QUIT causes the file server to ignore any remaining
          lines in the mail message. Because many people have
          mail signatures automatically included messages, the
          QUIT command can be used to prevent the unintentional
          parsing of those signatures as file server commands.

          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:''

          4-4

 


                                                     File Servers





          address. Any user receiving unasked-for files can use
          it to determine from whom the request came.






































                                                              4-5

 








          _______________________________________________________

   A      Troubleshooting MLF Problems



          MLF includes a debug mode that displays information
          about what it is doing when processing mailing list
          and file server requests. If you are experiencing
          problems with either a mailing list or a file server,
          you can enable this debug mode with the command:

              $ DEFINE/SYSTEM MX_MLF_DEBUG TRUE

          If you are in a VMScluster, this logical must be
          defined on the same node as the currently active MX
          MLF process to have any effect.

          Debug log files created by MLF are called MX_MLF_
          DIR:MX_MLF_LOG.LOG.

          __________________________________________________________________

   A.1    Case Sensitivity

          Unless the list was created with DEFINE LIST/NOCASE_
          SENSITIVE, the mailing list processor uses case-
          sensitive matching on the username part of addresses
          when looking up users on the subscriber list (except
          for subscribers with the NOCASE flag set), owner list,
          and SYSTEM_USERS list. Be careful when adding and
          removing users from these lists that the case of the
          username part of the address exactly matches what will
          be in the From: header of the address.

          Remember that MX automatically converts usernames
          to lower case, by default, when creating the From:
          header, so messages originating on the local system
          will have lower case usernames.

                                                              A-1

 








          _______________________________________________________

   B      Example: Mailing List with Archive Server



          This example creates a mailing list whose archives are
          made available through a file server.

              $ CREATE/DIRECTORY SOME_DISK:[ARCHIVES.MAILLIST]
              $ MCP
              MCP> DEFINE LIST "MailList" -
              _MCP>     /OWNER="me@myhost.mycompany.ORG"-
              _MCP>     /PROTECTION=(S:RWED,O:RWED,G:RWED,W:RWE)-
              _MCP>     /ARCHIVE=SOME_DISK:[ARCHIVES.MAILLIST]

          This would set up a public mailing list, with the list
          owner being user "me", who would also receive all the
          bounced mail from the mailing list (by default, since
          no /ERRORS_TO was specified). The archive will be
          created in directory SOME_DISK:[ARCHIVES.MAILLIST] a
          file name of MAILLIST (defaulting from the list name)
          and a file type of yyyy-mm (the year and month).

          You could then create a file server called Archives:

              MCP> DEFINE FILE_SERVER "Archives" -
              _MCP>     /MANAGER="me@myhost.mycompany.ORG"-
              _MCP>     /ROOT=SOME_DISK:[ARCHIVES.]-
              _MCP>     /MAILING_LIST=MailList

          This file server could then respond to requests
          for sending some or all of the monthly archives for
          mailing list MailList. The mailing list link prevents
          those users who are not subscribed to MailList from
          obtaining the archives. To complete the setup, you
          would also need to create the files FILESERV_HELP.TXT
          and MAILLIST.DESCRIPTION to be placed in directory
          SOME_DISK:[ARCHIVES], to describe the file server and
          the MailList archive "package".

                                                              B-1
