NetNews Usenet Archive 1992 #16

home *** CD-ROM | disk | FTP | other *** search

/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / vmsnet / mail / mx / 758 < prev next >

Wrap

Internet Message Format | 1992-07-26 | 46.2 KB

Path: sparky!uunet!usc!noiro.acs.uci.edu!unogate!mvb.saic.com!mx-list From: Helmut Springer <helmut@bonnie.physik.uni-stuttgart.de> Newsgroups: vmsnet.mail.mx Subject: RE: help!! need information on lists on MX V3.1c Message-ID: <0095E317.D1807F20.9814@bonnie.physik.uni-stuttgart.de> Date: Mon, 27 Jul 1992 09:31:36 +0200 Organization: Mx-List<==>Vmsnet.Mail.Mx Gateway X-Gateway-Source-Info: Mailing List Lines: 1492 Hi Matt, >I need to get a copy of the MX manual via FTP how can I do so??? ftp to ftp.spc.edu and get the file mx031.k_z (and eventually the unpacker lzdcmp.exe), contaons the whole docu... >How do I set up a list(s) it's easy, MLF-guide appended 8-) enjoy helmut _____________________________________cut here_____________________________ Message Exchange Mailing List/File Server Guide March, 1992 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 Software Version: Message Exchange V3.1 Engineering Computing Services Rensselaer Polytechnic Institute Troy, New York ________________________ 10 March 1992 Permission is granted to copy and redistribute this document for no commercial gain. This document is still under construction. Comments and suggestions for improvements may be forwarded to MX-List@vms.ecs.rpi.edu. The information in this document is subject to change without notice and should not be construed as a commitment by Rensselaer Polytechnic Institute. Rensselaer assumes no responsibility for any errors that may appear in this document. DISCLAIMER: The software described in this document is provided "as is". No guarantee is made by the author or the author's employer as to the suitability, reliability, security, usefulness, or performance of this software. The following are trademarks of Digital Equipment Corporation: DEC DECnet ULTRIX VAX VAXcluster VMS Jnet is a trademark of Joiner Associates, Inc. MultiNet is a trademark of SRI International and TGV, Inc. TCPware is a trademark of Process Software Corporation. __________ Copyright )1992 Rensselaer Polytechnic Institute _______________________________________________________ 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-10 3.6.1 ADD ___________________________ 3-10 3.6.2 REMOVE ________________________ 3-11 _________________________________________________ 3.7 DELETING A MAILING LIST 3-12 _______________________________________________________ CHAPTER 4 FILE SERVERS 4-1 _________________________________________________ 4.1 PACKAGES 4-1 _________________________________________________ 4.2 HELP FILE 4-2 _________________________________________________ 4.3 FILE SERVER COMMANDS 4-3 iv Contents _______________________________________________________ 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 LISTSERV 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 1 Contains a general description of MLF. Chapter 2 Describes how to use the MLF_CONFIG procedure. Chapter 3 Describes how to manage a mailing list. Chapter 4 Describes how to manage a file server. __________________________________________________________________ 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@vms.ecs.rpi.edu. Subscription requests, removals, or comments about the list are sent to MX-List-request@vms.ecs.rpi.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. __________________________________________________________________ 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. 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: 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: 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 information, and will create the root directory for 2-2 Using MLF_CONFIG.COM 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 the list. Two local addresses are set up for each mailing list: one for the list itself and a request address (list- name-REQUEST). 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 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 keeping with the default, a new archive file will be created every month. 3-1 Mailing Lists __________________________________________________________________ 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 (Write) allows the user to post messages to the list E (Enroll) allows the automatic handling of the SUBSCRIBE command D (Delete) allows the automatic handling of the ____________SIGNOFF_command____________________________ Note that Enroll access is only meaningful to WORLD- class users, and Delete access is only meaningful 3-2 Mailing Lists to GROUP-class users. For most, if not all, mailing lists, you should grant RWED access to both SYSTEM 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. 3-3 Mailing Lists __________________________________________________________________ 3.3 Automatic Request Handling MLF will answer requests automatically at both a list's -Request address and through the LISTSERV interface. The commands it recognizes through the - Request interface are listed in Table 3-4. LISTSERV 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 mailing lists. QUERY Returns the subscriber's status on the list. 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. 3-4 Mailing Lists | Table_3-4_(Cont.)__MLF_-Request_commands_______________ | | Command____________________Description_________________ | | SET [NO]REPRO Controls whether subscriber | receives a posting s/he | makes to the mailing list. SIGNOFF Removes the user from the list of subscribers. SUBSCRIBE Adds the user to the ___________________________subscriber_list.____________ Table_3-5__MLF_LISTSERV_commands_______________________ Command____________________Description_________________ ADD list-name Control command: allows address[,...] list owner to add other users to the list. HELP Sends file MX_MLIST_ DIR:MLIST_HELP.TXT. LIST Lists all available mailing lists. QUERY list-name Returns the subscriber's status on the list. REMOVE list-name Control command: allows address[,...] list owner to remove other users from the list. | | REVIEW list-name Returns the list of | subscribers. 3-5 Mailing Lists Table_3-5_(Cont.)__MLF_LISTSERV_commands_______________ Command____________________Description_________________ SET list-name [NO]MAIL Enables/disables receipt of list messages. | | SET list-name [NO]CONCEAL Controls whether subscriber | is concealed from view in | REVIEW listings. | | SET list-name [NO]REPRO Controls whether the | subscriber receives a | posting s/he makes to the | mailing 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__________________ When Per-list_qualifier____Global_default_____________sent__ /ADD_MESSAGE MLIST_ADD_MESSAGE.TXT when a user is added to a mail- ing list 3-7 Mailing Lists Table_3-6_(Cont.)__User_notification_messages__________ When Per-list_qualifier____Global_default_____________sent__ /REMOVE_MESSAGE MLIST_REMOVE_MESSAGE.TXT when a user is re- moved from a mail- ing list /FORWARD_MESSAGE MLIST_FORWARD_MESSAGE.TXT when a user at- tempts to sub- scribe to a list with no W:E ac- _________________________________________________cess__ 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. 3-8 Mailing Lists 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) 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 3-9 Mailing Lists 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 | is: | | ADD [/NONOTIFY] [/NOMAIL] [/NOCASE] [/CONCEAL] [/NOREPRO] address [,...] The syntax for the LISTSERV interface is: 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. 3-10 Mailing Lists 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. | | 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. | | The /NOREPRO qualifier is used to prevent the | subscriber from receiving a copy of postings s/he | makes to the list. | | Note that the LISTSERV 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: REMOVE [/NONOTIFY] address [,...] The syntax for the LISTSERV interface is: REMOVE [/NONOTIFY] list-name address [,...] 3-11 Mailing Lists 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 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 new subscribers to receive the "you have been removed" message for the mailing list. __________________________________________________________________ 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 at creation time. 3-12 _______________________________________________________ 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. __________________________________________________________________ 4.1 Packages The file server is designed to handle groups of files, called packages. When you create a package, you create a directory with the name of that package, and all files in that directory must have file names the same as the package name. In addition, you must place a description file above the package directory which is sent when a user requests a listing of available packages. This structure works best when you use a program such as VMS_SHARE to put together your packages. VMS_SHARE is readily available around the Internet and BITNET. It is used to collect together text files, format them so as to improve the chances of their being transferable through most mail systems, and split them up into easily mailable chunks. When all the chunks are put together on the receiving end, they form a DCL command procedure that re-creates the original files. 4-1 File Servers 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 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 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-2 File Servers __________________________________________________________________ 4.3 File Server Commands The three commands accepted by the file server are SENDME, LIST (or DIRECTORY), and HELP. Each may be abbreviated to the smallest unique string. One command is allowed per line of text in a request message, but several command lines may be sent in one request. SENDME takes either a package name (to have all parts of a package sent) or a file name (to have just one part sent). Large files are delayed until non-prime- time hours if enabled when file service is set up. LIST takes a pattern which is used to match against package names. The description file for each matching package is added to a message that is returned to the requesting user. If no pattern is specified, "*" is used. HELP causes the file FILESERV_HELP.TXT (located in the root directory of the file server) to be sent to the requesting user. 4-3 _______________________________________________________ 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 VAXcluster, 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 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 __________________________cut here______________________________________ -- Helmut Springer University of Stuttgart, FRG User HelpDesk Computing Center CipPool Physics Department springer@rus.uni-stuttgart.de helmut@bonnie.physik.uni-stuttgart.de phone: +49 711 685-4828 1291::helmut (BelWue) %SYSTEM-W-MAILONSYS, there is real mail installed on this system