                                       ,           Message Exchange Mailing List/File           Server Guide                 October, 1998       <           This manual describes the management and operation?           of Message Exchange, electronic mail software for VMS            systems.        A           Revision/Update Information:  This is a revised manual. >                                         Revision bars indicate>                                         changes made since the;                                         last version of the 1                                         software.   9           Operating System and Version: VMS V5.2 or later   A                                         OpenVMS AXP V1.0 or later   =           Software Version:             Message Exchange V5.1   )           Matt Madison and Hunter Goatley            MadGoat Software         "           17_October_1998_________  ?           The information in this document is subject to change 9           without notice and should not be construed as a :           commitment by MadGoat Software. MadGoat Software;           assumes no responsibility for any errors that may "           appear in this document.  8           No part of this publication may be reproduced,9           transmitted, transcribed, stored in a retrieval =           system, or translated into any language or computer ;           language, in any form or by any means electronic, ?           mechanical, magnetic, optical, chemical, or otherwise 9           without the prior written permission of MadGoat            Software.   ;           Use of this software and documentation is subject >           to the terms and conditions set forth in the License           Agreement.  =           The Licensed Materials are provided with RESTRICTED 8           RIGHTS. Use, duplication, or disclosure by the<           Government is subject to restrictions as set forth?           in subparagraph (c)(1)(ii) of the Rights in Technical >           Data and Computer Software clause at DFARS 252.227-@           7013 or subparagraphs (c)(1) and (2) of the Commercial@           Computer Software-Restricted Rights at 48 CFR 52.227-           19, as applicable.  =           MadGoat, Message Exchange, and MX are trademarks of            MadGoat Software.   ;           The following are trademarks of Digital Equipment            Corporation:  7           DEC                DECnet              P.S.I. ;           ULTRIX             VAX                 VAXcluster ;           VMS                AXP                 VMScluster   @           Jnet is a registered trademark of Wingra Technologies,           Inc.  ;           MultiNet and TCPware are registered trademarks of '           Process Software Corporation.   6           LISTSERV is a registered trademark of L-Soft           International.  :           WIN/TCP and Pathway are registered trademarks of           Attachmate, Inc.             __________@           Copyright 1998 MadGoat Software. ALL RIGHTS RESERVED.                       A           _______________________________________________________              Contents  A                 _________________________________________________ A                 PREFACE                                       vii   A           _______________________________________________________ A           CHAPTER 1  THE MAILING LIST/FILE SERVER             1-1   A                 _________________________________________________ A                 1.1   MAILING LISTS                           1-1   A                 _________________________________________________ A                 1.2   FILE SERVERS                            1-2     A           _______________________________________________________ A           CHAPTER 2  USING MLF_CONFIG.COM                     2-1   A                 _________________________________________________ A                 2.1   LIST SERVER MANAGERS                    2-1   A                 _________________________________________________ A                 2.2   MAILING LISTS                           2-2   A                 _________________________________________________ A                 2.3   FILE SERVERS                            2-2   A                 _________________________________________________ A                 2.4   USING THE RESULTS                       2-3     A           _______________________________________________________ A           CHAPTER 3  MAILING LISTS                            3-1   A                 _________________________________________________ A                 3.1   ARCHIVES                                3-1         A                                                               iii                     Contents          A                 _________________________________________________ A                 3.2   PROTECTION CODES                        3-2   A                 _________________________________________________ A                 3.3   AUTOMATIC REQUEST HANDLING              3-4   A                 3.3.1     Control Commands  ______________    3-7   A                 _________________________________________________ A                 3.4   USER NOTIFICATION MESSAGES              3-7   A                 _________________________________________________ A                 3.5   VMS MAIL FORWARDING                     3-9   A                 _________________________________________________ A                 3.6   USING THE ADD AND REMOVE COMMANDS       3-9   A                 3.6.1     ADD  ___________________________    3-9   A                 3.6.2     REMOVE  ________________________   3-13   A                 _________________________________________________ A                 3.7   DELETING A MAILING LIST                3-14   A                 _________________________________________________ A                 3.8   MAILING LIST DIGEST SUPPORT            3-14   A                 _________________________________________________ A                 3.9   CONTROLLING MAILING LIST PROCESSING    3-15   A                 _________________________________________________ A                 3.10  MAILING LIST HEADERS                   3-16   A           _______________________________________________________ A           CHAPTER 4  FILE SERVERS                             4-1   A                 _________________________________________________ A                 4.1   PACKAGES                                4-1                iv         A                                                          Contents           A                 _________________________________________________ A                 4.2   HELP FILE                               4-3   A                 _________________________________________________ A                 4.3   TRANSACTION LOGS                        4-3   A                 _________________________________________________ A                 4.4   FILE SERVER COMMANDS                    4-4     A           _______________________________________________________ A           APPENDIX A  TROUBLESHOOTING MLF PROBLEMS            A-1   A                 _________________________________________________ A                 A.1   CASE SENSITIVITY                        A-1     A           _______________________________________________________ 8           APPENDIX B  EXAMPLE: MAILING LIST WITH ARCHIVEA                       SERVER                                  B-1     A           _______________________________________________________            TABLES  1                 3-1       Mailing list protection A                           classes  _______________________    3-2   A                 3-2       Mailing list protection codes  _    3-2   A                 3-3       Typical protection codes  ______    3-3   A                 3-4       MLF -Request commands  _________    3-4   A                 3-5       MLF MXSERVER commands  _________    3-5   A                 3-6       User notification messages  ____    3-7       A                                                                 v                    A           _______________________________________________________              Preface   ;           This guide describes the management and operation >           of the Message Exchange Mailing List/File Server (MX           MLF).   L           __________________________________________________________________             Intended Audience   7           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.   L           __________________________________________________________________             Document Structure              This guide consists of  ;           Chapter    Contains a general description of MLF.            1   8           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   L           __________________________________________________________________             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).  A                                                               vii                     Preface           @           o  Message Exchange User's Guide describes MX features(              available to general users.                                                                                       viii                     A           _______________________________________________________   &    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.   L           __________________________________________________________________      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.   6           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, mailing8           lists can be broken down into two basic types:           Internet and BITNET.  7           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 Message7           Exchange is MX-List@MadGoat.Com. Subscription <           requests, removals, or comments about the list are.           sent to MX-List-request@MadGoat.Com.  A                                                               1-1          &           The Mailing List/File Server          <           Most mailing lists on BITNET hosts are implemented;           using Eric Thomas's LISTSERV, a package developed 8           specifically for automated handling of mailing5           lists. One LISTSERV on a system, at address :           LISTSERV@hostname, manages all the mailing lists8           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:  I                            MCP> DEFINE ALIAS LISTSERV "MXserver@hostname"   L           __________________________________________________________________      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                      A           _______________________________________________________       2      Using MLF_CONFIG.COM      =           MLF comes with a command procedure, MLF_CONFIG.COM, =           which is placed at installation time in the MX_DIR: 9           directory. This command procedure uses a simple @           question-and-answer script to develop the MCP commands:           needed to create mailing lists and file servers.  L           __________________________________________________________________      2.1    List Server Managers  9           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.  8           Note: Unless the list is defined with /NOCASE_7           SENSITIVE, the mailing list processor is case 9           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.    A                                                               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.  L           __________________________________________________________________      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.t  8           Note: Unless the list is defined with /NOCASE_7           SENSITIVE, the mailing list processor is case 9           sensitive when matching the username portion of 9           addresses. Be sure to enter the owner addresses0>           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.  L           __________________________________________________________________      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 thei=           device and directory that will serve as the root ofr>           the file server. MLF_CONFIG will prompt you for this  
           2-2r m  e    A                                              Using MLF_CONFIG.COM           =           information, and will create the root directory forh<           you, if you wish. It will then prompt for optional0           information regarding the file server.  L           __________________________________________________________________      2.4    Using the Results   9           When MLF_CONFIG finishes, it leaves you with an ;           MCP command file, called MX_DIR:MLF_CONFIG.MCP by 9           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.MCPo$                            MCP> SAVE8                            MCP> RESET/CLUSTER ROUTER,MLF  @           Your newly-created mailing lists and file servers will           then be ready.                                A                                                               2-3     t                A           _______________________________________________________t      3      Mailing Listse      9           The MCP DEFINE LIST command is used to create a ;           mailing list. The mailing list processor supports ;           the automatic archiving of mailing list messages,r?           automatic subscription processing, and limited remote_>           control of mailing lists. In addition, mailing lists?           can be protected in a variety of ways to restrict the_@           automatic subscription facility as well as postings to           the list._  @           Four local addresses are set up for each mailing list:@           one for the list itself, a request address (list-name-=           REQUEST), an owner address (owner-list-name), and aT;           digest address (list-name-digest) for those lists @           supporting 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.A  L           __________________________________________________________________      3.1    Archives  9           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 ofT=           the mailing list, and the file type for the archive_=           defaults to yyyy-mm, the current year and month. ByI  A                                                               3-1_ _  _               Mailing Lists_          >           keeping with the default, a new archive file will be           created every month.  L           __________________________________________________________________      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.  A           Table_3-1__Mailing_list_protection_classes_____________   A           Class______Description_________________________________   >           SYSTEM     any address matching one of the addresses@                      on the system user list (see DEFINE SYSTEM_                      USERS)A  :           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   A           WORLD______any_other_address___________________________   A           Table_3-2__Mailing_list_protection_codes_______________.  A           Code_______Description__________________________________  9           R (Read)   allows the use of the REVIEW command   A           W          allows the user to post messages to the list            (Write)_  9           E          allows the automatic handling of theT&           (Enroll)   SUBSCRIBE command  A           D          allows the automatic handling of the SIGNOFF A           (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          A                                                     Mailing Lists           =           and OWNER classes. SYSTEM and OWNER also implicitly_>           have Control access, allowing them to add and remove9           other users from the mailing list. Some typical_>           protection codes for GROUP and WORLD users are given           in Table 3-3.   A           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 8                          and sign off the list, but only>                          subscribers can review or post to the                          list.  ;           (G:W,W)        Private list. Only subscribers canX?                          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 allA           _______________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. Thes<           /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 markedh           /PRIVATE.   A                                                               3-3l o  n               Mailing Listsa        L           __________________________________________________________________  $    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. MXSERVERu+           commands are listed in Table 3-5.   A           Table_3-4__MLF_-Request_commands_______________________   A           Command_________________Description____________________   >           ADD address[,...]       Control command: allows listA                                   owner to add other users to theb'                                   list.   @           HELP                    Sends file MX_MLIST_DIR:MLIST_+                                   HELP.TXT.t  A           LIST                    Lists all available non-private 0                                   mailing lists.  A           QUERY                   Returns the subscriber's statusn.                                   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 0                                   from the list.  5           REVIEW                  Returns the list of .                                   subscribers.  =           SET [NO]MAIL            Enables/disables receipt of 0                                   list messages.  @           SET [NO]CONCEAL         Controls whether subscriber is?                                   concealed from view in REVIEWt+                                   listings.l  =           SET [NO]REPRO           Controls whether subscribere?                                   receives a posting s/he makesl6                                   to the mailing list.  
           3-4_ _  _    A                                                     Mailing Lists           A           Table_3-4_(Cont.)__MLF_-Request_commands_______________l  A           Command_________________Description____________________.  =           SET [NO]DIGEST          Controls whether subscriber ?                                   receives all posts or a daily <                                   digest of posts to a list.  @           SIGNOFF                 Removes the user from the list1                                   of subscribers.   A           SUBSCRIBE               Adds the user to the subscriber A           ________________________list.__________________________n  A           Table_3-5__MLF_MXSERVER_commands_______________________   A           Command_________________Description____________________   >           ADD list-name           Control command: allows listA           address[,...]           owner to add other users to the '                                   list.d  @           HELP                    Sends file MX_MLIST_DIR:MLIST_+                                   HELP.TXT.S  A           LIST                    Lists all available non-privatet0                                   mailing lists.  A           QUERY list-name         Returns the subscriber's status-.                                   on the list.  ?           QUIT                    Causes all remaining lines ini<                                   the message to be ignored.  >           REMOVE list-name        Control command: allows list=           address[,...]           owner to remove other users 0                                   from the list.  5           REVIEW list-name        Returns the list ofm.                                   subscribers.  =           SET list-name           Enables/disables receipt of 0           [NO]MAIL                list messages.  A                                                               3-5r e                  Mailing Lists           A           Table_3-5_(Cont.)__MLF_MXSERVER_commands_______________f  A           Command_________________Description____________________f  @           SET list-name           Controls whether subscriber is?           [NO]CONCEAL             concealed from view in REVIEWA+                                   listings.   A           SET list-name           Controls whether the subscriber ?           [NO]REPRO               receives a posting s/he makese6                                   to the mailing list.  =           SET list-name           Controls whether subscriberT?           [NO]DIGEST              receives all posts or a dailyh<                                   digest of posts to a list.  @           SIGNOFF list-name       Removes the user from the list1                                   of subscribers.a  A           SUBSCRIBE list-name     Adds the user to the subscriberiA           ________________________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 ifr?           the requesting user is granted R (Read) access to the ?           list. Read access may be granted only to GROUP (i.e.,l=           the subscribers of the list) or to GROUP and WORLD._>           If access is denied, the request is returned with an           error message.    
           3-6r r  t    A                                                     Mailing Lists         %           ___________________________       3.3.1  Control Commands  ;           The mailing list processor currently supports twom?           control requests: ADD and REMOVE. They may be used bye>           the owners of a mailing list to add and remove other4           users to and from the list of subscribers.  7           The owners of a mailing list also receive thee9           full list of subscribers when they REVIEW theira9           list, regardless of the CONCEAL setting of eachh=           subscriber. Non-owners receive a list consisting of ;           subscribers who have not set the CONCEAL flag for )           their subscription to the list.o  L           __________________________________________________________________  $    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.  A           Table_3-6__User_notification_messages__________________              Per-listA           qualifier__________Global_default__________When_sent____  @           /ADD_MESSAGE       MLIST_ADD_MESSAGE.TXT   when a user@                                                      is added to>                                                      a mailing9                                                      liste  @           /REMOVE_MESSAGE    MLIST_REMOVE_           when a user?                              MESSAGE.TXT             is removed_;                                                      from al<                                                      mailing9                                                      liste  A                                                               3-7n i  .               Mailing Lists           A           Table_3-6_(Cont.)__User_notification_messages__________              Per-listA           qualifier__________Global_default__________When_sent___l  @           /FORWARD_MESSAGE   MLIST_FORWARD_          when a user@                              MESSAGE.TXT             attempts to>                                                      subscribe>                                                      to a list@                                                      with no W:EA           ___________________________________________access______u  =           The global default message files are located in MX_e?           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.d  !           Customization Variables_  8           The text of a notification message can contain>           references to customization "variables" whose values?           are supplied by the mailing list processor. Availablei           variables are:  >           {list-address}     the RFC822 address of the mailing!                              list   =           {request-address}  the RFC822 address of the list'so-                              -Request address   =           {list-name}        the name of the mailing list (no '                              @hostname)a  5           {list-desc}        the contents of the listt=                              description, as specified by the :                              /DESCRIPTION qualifier on the0                              DEFINE LIST command  <           {list-owner}       the address of the owner of the@                              mailing list (if there are multiple?                              owner addresses, only the first isf"                              used)  
           3-8, u  o    A                                                     Mailing Lists           9           Note that each variable name must be surrounded :           by curly braces to be recognized. All other text>           (including unrecognized variable references) is sent           verbatim.   L           __________________________________________________________________      3.5    VMS Mail ForwardingE  <           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:t  !                            $ MAIL_H                            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:  1                            MAIL> REMOVE list-namet  @           This will prevent a possible mail looping problem from           occurring.  L           __________________________________________________________________  +    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.t  %           ___________________________l  
    3.6.1  ADDr  =           The ADD command adds other users to a mailing list.g@           The syntax for this command for the -Request interface
           is:   <                              ADD [qualifiers] address [,...]  3           The syntax for the MXSERVER interface is:o  A                                                               3-9l    v               Mailing Lists           I                              ADD [/qualifiers]  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-maile           message.  ?           For address, you should enter the RFC822-type addressy>           for the user to be added. It should generally appear;           exactly as it does on the From line of a message,T?           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>n  5           Valid qualifiers that can be specified are:              o  /[NO]NOTIFY             o  /[NO]MAIL             o  /[NO]CASE             o  /[NO]CONCEAL_             o  /[NO]REPRO              o  /[NO]DIGEST             o  /[NO]DENY             o  /[NO]ACCESS             o  /[NO]POST  ?           By default, subscriber entries are set to MAIL, CASE,a;           NOCONCEAL, REPRO, NODIGEST, NODENY, NOACCESS, andi:           POST. The default settings for a list can be set;           using the /SETTINGS qualifier on the MCP commands ?           DEFINE LIST and MODIFY LIST. See the Message Exchange_0           Management Guide for more information.  >           Use the /NONOTIFY qualifier when you do not want the>           new subscribers to receive the "you have been added"'           message for the mailing list:o             3-10         A                                                     Mailing Listsy          >           The /NOMAIL qualifier is used to add the user to the;           mailing list as a NOMAIL subscriber. That is, ther=           user is on the list without receiving any mail fromi=           the list. NOMAIL subscriptions are used for private_?           mailing lists, where only the subscribers are allowedR<           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 filei-           server from any of those addresses.a  >           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.8           Normally, the list processor is case-sensitive>           regarding usernames unless the list was defined with'           DEFINE LIST/NOCASE_SENSITIVE.s  @           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.c  7           The /NOREPRO qualifier is used to prevent the ;           subscriber from receiving a copy of postings s/hed           makes to the list.  6           The /NOPOST qualifier is used to prevent the?           subscriber from posting to the list. Note that if theE@           list protection allows WORLD=WRITE access, /NOPOST has           no effect.  >           The /DIGEST qualifier is used to mark the subscriber;           entry so that it will receive mailing lists postsu<           made to the "-digest" address for a list. For more2           information on digests, see Section 3.8.  =           The /DENY qualifier can be used to add a subscriberW<           to a closed mailing list (one which does not allow>           WORLD writes) and still prevent that subscriber from:           posting to the list, thus denying the subscriber<           access to the list. Subscribers with the DENY flag=           set cannot post to the list, will not receive posts   A                                                              3-11t s  c               Mailing Lists_          @           to the list, cannot change their subscriber entry, and1           cannot remove themselves from the list.o  <           The DENY setting was added specifically to provide9           the list owner with the ability to keep problema.           subscribers 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 9           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 fromr?           members of the list, an access control address can be ?           specified to allow any user from a particular site tot           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 fileu=           server must be subscribed to the associated mailingc@           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._  =           For example, suppose you have a file server that isl>           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.E=           The /NOCASE and /CONCEAL qualifiers may be given as            desired.             3-12 e  s    A                                                     Mailing ListsI          ?           Subscriber reviews of lists containing access control 9           entries show those entries as having the ACCESSi           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           interface is:   H                              REMOVE [/NONOTIFY] [/NOCASE] address [,...]  3           The syntax for the MXSERVER interface is:   J                              REMOVE [/NONOTIFY]  list-name  address [,...]  ;           You may specify multiple addresses to be added byl<           separating the list with commas, but note that the;           entire command must fit on one line in the E-mailr           message.  ?           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"'           message for the mailing list.   ?           The /NOCASE qualifier is used to remove the user fromr:           the mailing list while having the list processor;           disregard the case of the username portion of the 8           address. Normally, the list processor is case-;           sensitive regarding usernames unless the list was 4           defined with DEFINE LIST/NOCASE_SENSITIVE.  A                                                              3-13  u                  Mailing Lists         L           __________________________________________________________________  !    3.7    Deleting a Mailing List   ?           The MCP REMOVE LIST command removes the definition ofE@           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:  I                            $ DELETE MX_MLIST_DIR:list-name.MAILING_LIST;*n  @           You should also remember to delete any add, remove, or?           forward message files you set up for the mailing list            at creation time.   L           __________________________________________________________________  %    3.8    Mailing List Digest Support_  <           The MX MLF processor supports mailing list digests?           in that subscriber entries can be marked "DIGEST" and]=           mail sent to a "-digest" list address (for example, 8           "List-digest") will be forwarded only to those>           subscribers. Digest subscribers do not receive posts4           made to the standard mailing list address.  >           MX MLF does not provide any support for creating the>           mailing list digests. However, the MX_ROOT:[CONTRIB]:           directory does contain a package, MX_DIGEST, for>           creating digests. You can use MX_DIGEST to implement:           mailing list digests, or you can supply your own           software to do so.  <           All digest posts should be mailed to the "-digest"=           address for the list. For example, digests for "MX-t=           List" would be mailed to "MX-List-Digest". Only thee:           list owner(s) and system user(s) can post to the:           "-digest" address; messages from other users are=           diverted to the mailing list address and treated as            normal postings.             3-14 s  e    A                                                     Mailing Lists         L           __________________________________________________________________  -    3.9    Controlling Mailing List Processing   <           Large and busy mailing lists can put a significant@           burden on a single MX installation, especially if they<           have many remote subscribers. This can cause large>           backlogs to develop in the MX message queue, and may?           prevent non-mailing list mail from being processed in ?           a timely fashion. If you intend to host several large ;           mailing lists, you may want to dedicate an entire 6           system just to processing mailing list mail.  :           There are two mechanisms you can use, separately;           or together, to prevent mailing list traffic fromO;           dominating your mailer. One is to set up multiplei:           delivery agents (SMTP agents, in particular, for=           Internet-connected systems). The number of deliverya=           agents your system can reasonably support will varyR@           based on your CPU and memory configuration, as well as/           the speed of your network connection.a  8           The second mechanism is to limit the number of>           recipients per message generated by the mailing list;           processor, using the /RECIPIENT_MAXIMUM qualifier_:           on either the DEFINE LIST command or the SET MLF?           command in MCP. When a message comes in for a mailingt;           list with a large number of subscribers, MLF willf=           create several copies of the outgoing message, each <           with no more than the maximum number of recipients;           you set. By breaking up the messages into smaller-@           numbers of recipients, you can enhance the parallelism;           of having multiple delivery agents, and prevent ae=           single message from tying up any one delivery agentT>           for an extended period of time. However, setting the?           recipient maximum to too low a value can increase the <           storage requirements for your MX message queue and.           create a larger backlog of messages.  :           Finding the right combination of delivery agents:           and recipient limits requires careful monitoring=           of your system. You may need to adjust the settings @           several times before you achieve a reasonable balance.  A                                                              3-15                     Mailing Lists.          :           In addition, you may need to alter the values on9           a regular basis if your mailing list traffic ist=           "bursty;" i.e., the number of mailing list messagest+           is not relatively even over time.R  L           __________________________________________________________________      3.10   Mailing List Headers  =           The MCP commands DEFINE LIST and MODIFY LIST accept ?           three qualifiers that allow you to control the header >           content of mailing list posts. These qualifiers are:             o  /STRIP_HEADERSa             o  /LIST_HEADERS             o  /XHEADERS  9           /STRIP_HEADERS=RECEIVED lets you strip multiplee7           "Received:" headers from posts. Stripping outl8           the "Received:" headers can make it impossible:           to accurately track the source of a message, but<           for posts coming through multiple gateways, it can?           significantly cut down on the total number of headers            per post.h  >           /STRIP_HEADERS=OTHERS lets you strip out all "other"?           headers from the incoming message before it is mailed =           out. "Other" headers are any headers not documented <           in the Message Exchange Management Guide under SET@           LOCAL/TOP_HEADERS. You can use this qualifier to strip@           posts from return-receipt headers, X.400 headers, etc.  8           /LIST_HEADERS can be used to enable or disable<           the following headers, currently proposed as a new           Internet standard:  A           o  X-List-Subscribe (/LIST_HEADERS=(SUBSCRIBE[=string])c             3-16 l  -    A                                                     Mailing Lists           =              Provides a URL for subscribing to a list. If ther>              string is omitted, MX MLF supplies the proper URL)              when each post is processed.              o  X-List-Unsubscribe 2              (/LIST_HEADERS=(UNSUBSCRIBE[=string])  A              Provides a URL for unsubscribing from a list. If theb>              string is omitted, MX MLF supplies the proper URL)              when each post is processed.b  5           o  X-List-Help (/LIST_HEADERS=(HELP=string)_  <              Provides a URL for obtaining information on the?              list. This URL may point to a Web page documenting 8              the list, or it may include a "mailto:" for(              obtaining help on the list.  ;           As of this writing, the headers are not an actual =           standard, hence the use of the "X-" prefix on each.A8           If and when the standard is passed, the prefix8           will be removed. However, clients that support:           these headers are supposed to handle both forms.6           For more information about the proposal, see.           "http://arpp.carleton.ca/listspec/".  =           Finally, the /XHEADERS qualifier can be used to add =           site-specified headers to mailing list posts. Therew;           are a number of non-standard headers that you mayc@           wish to implement, including "Precedence: Bulk", which=           instructs some versions of sendmail not to generatem*           non-delivery warnings for posts.  ;           Note: Any string can be supplied as the /XHEADERSa@           value, but care must be taken to ensure that the site-<           specific headers are valid RFC822 headers and that1           they don't conflict with other headers.       A                                                              3-17  s                   A           _______________________________________________________t      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,d>           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 servers=           to a mailing list, so that only those users who arem<           subscribed to the list can gain access to the file           server.e  >           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.   L           __________________________________________________________________      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 theS@           package is requested must have file names that are the#           same as the package name.f  8           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 a8           user requests a listing of available packages.  ,           The description file must be named9           package.DESCRIPTION, where package is again the            package name.   A                                                               4-1e s  e               File Servers          ?           This structure works best when you use a program suchi?           as VMS_SHARE to put together your packages. VMS_SHAREt>           is readily available around the Internet and BITNET.;           It is used to collect together text files, formatp:           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 chunksf@           are put together on the receiving end, they form a DCL?           command procedure that re-creates the original files.              Examples  ?           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:  C                            $ CREATE/DIRECTORY disk:[FILESERV.STUFF]n  <           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:  B                            $ EDIT disk:[FILESERV]STUFF.DESCRIPTION  7           If you prefer, the .DESCRIPTION files for all @           packages under [FILESERV] can be placed in the package@           directories with the other files. However, description1           files cannot be located in both places.o  >           Finally, you would need to set up the file server in           MCP:  Q                            MCP> DEFINE FILE_SERVER FILESERV/ROOT=disk:[FILESERV.]l  @           The file server FILESERV will now automatically handle,           distribution of the STUFF package.  
           4-2r i  t    A                                                      File Serverso        L           __________________________________________________________________      4.2    Help Filet  5           The file FILESERV_HELP.TXT, provided by thes<           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 a8           user sends a HELP command to your file server.  L           __________________________________________________________________      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 backn=           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 logy?           mailed out. This transaction header can be useful forp?           letting users know of scheduled downtimes or a change /           in package availability, for example.h          A                                                               4-3                     File Servers        L           __________________________________________________________________      4.4    File Server Commands  ;           The five commands accepted by the file server areT?           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 onea           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 thee=           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 remainingt=           lines in the mail message. Because many people haved>           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 thee=           ADDRESS command to provide a valid alternate to theh           "From:" address.  >           Note: When an ADDRESS command is processed, the file>           server transaction log includes the original "From:"  
           4-4.         A                                                      File Servers           ?           address. Any user receiving unasked-for files can use_5           it to determine from whom the request came.e                                                                            A                                                               4-5t s  T                A           _______________________________________________________   &    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.o  ;           Debug log files created by MLF are called MX_MLF_t           DIR:MX_MLF_LOG.LOG.o  L           __________________________________________________________________      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 ands>           removing users from these lists that the case of the@           username part of the address exactly matches what will0           be in the From: header of the address.  ;           Remember that MX automatically converts usernamest<           to lower case, by default, when creating the From:=           header, so messages originating on the local systems)           will have lower case usernames.   A                                                               A-1                      A           _______________________________________________________o  3    B      Example: Mailing List with Archive Servern      @           This example creates a mailing list whose archives are/           made available through a file server.a  K                            $ CREATE/DIRECTORY SOME_DISK:[ARCHIVES.MAILLIST]                              $ MCP8                            MCP> DEFINE LIST "MailList" -F                            _MCP>     /OWNER="me@myhost.mycompany.ORG"-N                            _MCP>     /PROTECTION=(S:RWED,O:RWED,G:RWED,W:RWE)-K                            _MCP>     /ARCHIVE=SOME_DISK:[ARCHIVES.MAILLIST]y  @           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, sincea;           no /ERRORS_TO was specified). The archive will bed>           created in directory SOME_DISK:[ARCHIVES.MAILLIST] a?           file name of MAILLIST (defaulting from the list name)s:           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" - H                            _MCP>     /MANAGER="me@myhost.mycompany.ORG"-A                            _MCP>     /ROOT=SOME_DISK:[ARCHIVES.]-n;                            _MCP>     /MAILING_LIST=MailListg  9           This file server could then respond to requestsc=           for sending some or all of the monthly archives fora?           mailing list MailList. The mailing list link preventsg=           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.TXTy<           and MAILLIST.DESCRIPTION to be placed in directory?           SOME_DISK:[ARCHIVES], to describe the file server andt)           the MailList archive "package".   A                                                               B-1a