V'0):>Message Exchange Mailing List/File Server GuideG

Message Exchange Mailing List/File Server Guide





+

February, 2001



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

.Revision/Update Information: This is a revised manual.

.Operating System and Version:VMS V5.5 or later

OpenVMS Alpha V6.2 or later

"Software Version:Message Exchange V5.2


25 February 2001

EThe information in this document is subject to change without notice Aand should not be construed as a commitment by MadGoat Software. CMadGoat Software assumes no responsibility for any errors that may appear in this document.

<No part of this publication may be reproduced, transmitted, Btranscribed, stored in a retrieval system, or translated into any Glanguage or computer language, in any form or by any means electronic, Hmechanical, magnetic, optical, chemical, or otherwise without the prior 'written permission of MadGoat Software.

CUse of this software and documentation is subject to the terms and .conditions set forth in the License Agreement.

AThe Licensed Materials are provided with RESTRICTED RIGHTS. Use, Hduplication, or disclosure by the Government is subject to restrictions Has set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data <and Computer Software clause at DFARS §252.227-7013 or 8subparagraphs (c)(1) and (2) of the Commercial Computer FSoftware---Restricted Rights at 48 CFR §52.227-19, as applicable.

EMadGoat, Message Exchange, and MX are trademarks of MadGoat Software.

>The following are trademarks of Digital Equipment Corporation:               
DEC DECnet P.S.I.
ULTRIX VAX  VAXcluster
VMS AXP  VMScluster


CMultiNet and TCPware are registered trademarks of Process Software Corporation.

;LISTSERV is a registered trademark of L-Soft International.

AWIN/TCP and Pathway are registered trademarks of Attachmate, Inc.

Copyright ©2001



 ,  
FContents
 


$

Preface



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

Intended Audience



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

Document Structure



This guide consists of                
 Chapter 1 , Contains a general description of MLF.
 Chapter 2 4 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.
4

Related Documents



?You can find additional information in the following documents:

 


J

Chapter 1
The Mailing List/File Server




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

1.1 Mailing Lists



HWhen talking about electronic mail, the term mailing list is Ggenerally used to describe an E-mail address that forwards messages to @one or more subscribers. Mailing lists abound on the BInternet, on a wide variety of technical and non-technical topics.

=Unfortunately, there are no widely-enforced standards on the Eimplementation of mailing lists, so their use will vary depending on 2the systems on which the mailing lists are set up.

HFor most Internet mailing lists, there are generally two addresses: one Cfor the mailing list itself, and one for "administrivia" E(subscription requests, etc.). The administrative address is usually Hthe mailing list name with "-request" added. For example, the 0mailing list for discussing Message Exchange is GMX-List@MadGoat.Com. Subscription requests, removals, 'or comments about the list are sent to -MX-List-request@MadGoat.Com.

FMLF provides support for both the typical Internet -request interface @and a subset of the interface used by L-Soft's ListServ for its Fautomatic command handling. The special addresses MXSERVER and MXSERV Hare recognized by MX Router as the MLF ListServ-style interface. If you Calso want LISTSERV to be recognized, then you must define it as an 6alias using the MCP command DEFINE ALIAS. For example:

 

"
1MCP> DEFINE ALIAS LISTSERV "MXserver@hostname"


M

1.2 File Servers



GThere are no standards for file servers. There are several file server Gimplementations in existence: LISTSERV, VMSSERV, MAILSERV, and several Fothers. Some take commands on the subject line of a message, and some Fin the body of a message. The way files are distributed can also vary from server to server.

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

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


B

Chapter 2
Using MLF_CONFIG.COM




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

2.1 List Server Managers



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

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



/  
Note

DUnless the list is defined with /NOCASE_SENSITIVE, the mailing list Bprocessor is case sensitive when matching the username portion of Aaddresses. Be sure to enter the list manager addresses using the Gcorrect case. MX, by default, converts all usernames to lower case for Dlocal users, so you should generally use lower case when specifying 'local list managers' addresses.


,Primary List Server Manager


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

2.2 Mailing Lists



AOnce you have defined your list server managers, or if they were Falready defined before you ran MLF_CONFIG, you can then set up one or Cmore mailing lists. MLF_CONFIG will prompt you for the name of the Amailing list and the address of the owner of the list, which are Grequired. It will then prompt you for the optional information related to the list.

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



/  
Note

DUnless the list is defined with /NOCASE_SENSITIVE, the mailing list Bprocessor is case sensitive when matching the username portion of Haddresses. Be sure to enter the owner addresses using the correct case. FMX, by default, converts all usernames to lower case for local users, Cso you should generally use lower case when specifying local owner addresses.
M

2.3 File Servers



BAfter the mailing lists phase, MLF_CONFIG will ask you about file Gservers. To create a file server, you must specify the name, manager's Eaddress, and the device and directory that will serve as the root of Fthe file server. MLF_CONFIG will prompt you for this information, and Bwill create the root directory for you, if you wish. It will then :prompt for optional information regarding the file server.R

2.4 Using the Results



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

 

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




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


;

Chapter 3
Mailing Lists




BThe MCP DEFINE LIST command is used to create a mailing list. The Hmailing list processor supports the automatic archiving of mailing list Hmessages, automatic subscription processing, and limited remote control Cof mailing lists. In addition, mailing lists can be protected in a Hvariety 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: oneHfor the list itself, a request address (list-name-REQUEST), an ?owner address (owner-list-name), and a digest address D(list-name-digest) for those lists supporting digests. The Gmailing list processor accepts subscription requests and other control %messages on a list's request address.

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

3.1 Archives



GA mailing list is archived automatically by the mailing list processor Dwhen the /ARCHIVE qualifier is used on the DEFINE LIST command. You Gmust specify at least a device and directory for the archive. The file Gname for the archive defaults to the name of the mailing list, and the Dfile type for the archive defaults to yyyy-mm, the current Hyear and month. By keeping with the default, a new archive file will be created every month.Q

3.2 Protection Codes



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

O  &                  
Table 3-1 Mailing list protection classes
Class Description
SYSTEM M any address matching one of the addresses on the system user list (see  DEFINE SYSTEM_USERS)
OWNER N any address matching one of the owner addresses specified on the /OWNER  qualifier
GROUP L any address matching one the addresses on the subscriber list for the  mailing list
WORLD  any other address


M   &                  
Table 3-2 Mailing list protection codes
Code Description
 R (Read) * allows the use of the REVIEW command
 W (Write) 2 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


ENote that Enroll access is only meaningful to WORLD-class users, and HDelete access is only meaningful to GROUP-class users. For most, if not Dall, mailing lists, you should grant RWED access to both SYSTEM and EOWNER classes. SYSTEM and OWNER also implicitly have Control access, Hallowing them to add and remove other users from the mailing list. Some @typical protection codes for GROUP and WORLD users are given in 3Table 3-3.

H                 
Table 3-3 Typical protection codes
 (G:RWED,W:RWE) H Public list. Anyone can subscribe, sign off, and review the list; " anyone can post to the list.
 (G:RWED,W:E) M Semi-public list. Anyone can subscribe and sign off the list, but only 1 subscribers can review or post to the list.
(G:W,W) C Private list. Only subscribers can post to the list, and all K subscription requests are screened by the owners of the mailing list.
(G,W) H One-way list. Only the owners can post to the list, and they also + screen all the subscription requests.




/  
Note

FSince electronic mail can readily be forged, you should not depend on Hthis protection scheme for absolute security of your mailing lists. The Gmailing list processor attempts no authentication of addresses when it receives messages.


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

3.3 Automatic Request Handling



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

E  " &                                                          
Table 3-4 MLF -Request commands
Command Description
 ADD address[,...] H Control command: allows list owner to add other users to the list.
HELP - Sends file MX_MLIST_DIR:MLIST_HELP.TXT.
LIST 4 Lists all available non-private mailing lists.
 MODIFY address K Control command: allows list owner to modify a subscriber's settings.
QUERY 2 Returns the subscriber's status on the list.
QUIT > Causes all remaining lines in the message to be ignored.
 REMOVE address[,...] M Control command: allows list owner to remove other users from the list.
REVIEW & Returns the list of subscribers.
 SET [NO]MAIL 0 Enables/disables receipt of list messages.
 SET [NO]CONCEAL L Controls whether subscriber is concealed from view in REVIEW listings.
 SET [NO]REPRO G Controls whether subscriber receives a posting s/he makes to the  mailing list.
 SET [NO]DIGEST J Controls whether subscriber receives all posts or a daily digest of  posts to a list.
SIGNOFF 4 Removes the user from the list of subscribers.
 SUBSCRIBE + Adds the user to the subscriber list.


E  " &                                                          
Table 3-5 MLF MXSERVER commands
Command Description
! ADD list-name address[,...] H Control command: allows list owner to add other users to the list.
HELP - Sends file MX_MLIST_DIR:MLIST_HELP.TXT.
LIST 4 Lists all available non-private mailing lists.
$ MODIFY list-name address[,...] G Control command: allows list owner to modify subscriber settings.
 QUERY list-name 2 Returns the subscriber's status on the list.
QUIT > Causes all remaining lines in the message to be ignored.
$ REMOVE list-name address[,...] M Control command: allows list owner to remove other users from the list.
 REVIEW list-name & Returns the list of subscribers.
 SET list-name [NO]MAIL 0 Enables/disables receipt of list messages.
 SET list-name [NO]CONCEAL L Controls whether subscriber is concealed from view in REVIEW listings.
 SET list-name [NO]REPRO K Controls whether the subscriber receives a posting s/he makes to the  mailing list.
 SET list-name [NO]DIGEST J Controls whether subscriber receives all posts or a daily digest of  posts to a list.
 SIGNOFF list-name 4 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 Fprotection class is granted E (Enroll) access to the list. Otherwise, :they are forwarded to the list owners for manual handling.

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

FREVIEW requests are handled automatically only if the requesting user His granted R (Read) access to the list. Read access may be granted only Gto 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.3.1 Control Commands



1The mailing list processor supports three controlGrequests: ADD, MODIFY, and REMOVE. They may be used by the owners of a Cmailing list to add and remove other users to and from the list of 5subscribers, or change their per-subscriber settings.

GThe owners of a mailing list also receive the full list of subscribers Gwhen they REVIEW their list, regardless of the CONCEAL setting of each Dsubscriber. Non-owners receive a list consisting of subscribers who Ahave not set the CONCEAL flag for their subscription to the list.[

3.4 User Notification Messages



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

J  - ) $                 
Table 3-6 User notification messages
Per-list qualifier Global default When sent
 /ADD_MESSAGE  MLIST_ADD_MESSAGE.TXT , when a user is added to a mailing list
 /REMOVE_MESSAGE  MLIST_REMOVE_MESSAGE.TXT 0 when a user is removed from a mailing list
 /FORWARD_MESSAGE  MLIST_FORWARD_MESSAGE.TXT D when a user attempts to subscribe to a list with no W:E access


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

(Customization Variables


=The text of a notification message can contain references to Ecustomization "variables" whose values are supplied by the 0mailing list processor. Available variables are:                    
 {list-address} , the RFC822 address of the mailing list
 {request-address} 7 the RFC822 address of the list's -Request address
 {list-name} 1 the name of the mailing list (no @hostname)
 {list-desc} M the contents of the list description, as specified by the /DESCRIPTION * qualifier on the DEFINE LIST command
 {list-owner} J the address of the owner of the mailing list (if there are multiple . owner addresses, only the first is used)


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

3.5 VMS Mail Forwarding



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

 

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




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

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

 

"
MAIL> REMOVE list-name




AThis will prevent a possible mail looping problem from occurring.k

3.6 Using the ADD, MODIFY, and REMOVE Commands



HThe list processor provides commands for use exclusively by list owners 2and list server managers: ADD, MODIFY, and REMOVE.B

3.6.1 ADD and MODIFY Commands



EThe ADD command adds one or more users to a mailing list. The MODIFY Dcommand modifies the various per-user settings for an existing list Gsubscriber. The syntax for these command for the -Request interface is:

   

"
"  ADD [qualifiers] address [,...] %  MODIFY [qualifiers] address [,...] 

)The syntax for the MXSERVER interface is:

   

"
.  ADD [qualifiers]  list-name  address [,...] 



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

GFor address, you should enter the RFC822-type address Ffor the user to be added. It should generally appear exactly Aas it does on the From line of a message, since the mailing list Gprocessor 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>

+Valid qualifiers that can be specified are:





HBy default, subscriber entries are set to MAIL, CASE, NOCONCEAL, REPRO, FNODIGEST, NODENY, NOACCESS, and POST. The default settings for a list Dcan be set using the /SETTINGS qualifier on the MCP commands DEFINE ^LIST and MODIFY LIST. See the Message Exchange Management Guide for more information.

HUse the /NONOTIFY qualifier when you do not want the new subscribers to Dreceive the "you have been added" message for the mailing Flist. MODIFY commands do not trigger any notification to the affected subscribers.

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

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

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

HThe /NOREPRO qualifier is used to prevent the subscriber from receiving *a copy of postings s/he makes to the list.

HThe /NOPOST qualifier is used to prevent the subscriber from posting to Fthe list. Note that if the list protection allows WORLD=WRITE access, /NOPOST has no effect.

FThe /DIGEST qualifier is used to mark the subscriber entry so that it Ewill receive mailing lists posts made to the "-digest" address for a _list. For more information on digests, see Section 3.8.

HThe /DENY qualifier can be used to add a subscriber to a closed mailing Dlist (one which does not allow WORLD writes) and still prevent that Hsubscriber from posting to the list, thus denying the subscriber access Cto the list. Subscribers with the DENY flag set cannot post to the >list, will not receive posts to the list, cannot change their =subscriber entry, and cannot remove themselves from the list.

GThe DENY setting was added specifically to provide the list owner with @the ability to keep problem subscribers from accessing the list.

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

qIn addition, file servers, described in Chapter 4, can be set up so Fthat they are associated with a mailing list. Any user wishing to use Fsuch a file server must be subscribed to the associated mailing list, Cor access to the file server will be denied. The /ACCESS qualifier Cprovides a way to allow unrestricted file server access to certain Daddresses without having to subscribe every possible address to the mailing list.

GFor example, suppose you have a file server that is to be used only by Cusers from systems at XYZ.COM and YYZ.COM. Instead of listing each Dpossible 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> 




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

CSubscriber reviews of lists containing access control entries show -those entries as having the ACCESS attribute.1

3.6.2 REMOVE



GThe REMOVE command removes other users from a mailing list. The syntax /for this command for the -Request interface is:

   

"
.  REMOVE [/NONOTIFY] [/NOCASE] address [,...] 

)The syntax for the MXSERVER interface is:

   

"
:  REMOVE [/NONOTIFY]  [/NOCASE] list-name  address [,...] 



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

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

DUse the /NONOTIFY qualifier when you do not want the subscribers to Freceive the "you have been removed" message for the mailing list.

GThe /NOCASE qualifier is used to remove the user from the mailing list Cwhile having the list processor disregard the case of the username Gportion of the address. Normally, the list processor is case-sensitive <regarding usernames unless the list was defined with DEFINE LIST/NOCASE_SENSITIVE.X

3.7 Deleting a Mailing List



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

 

"
.$ DELETE MX_MLIST_DIR:list-name.MAILING_LIST;*




GYou should also remember to delete any add, remove, or forward message 7files you set up for the mailing list at creation time.\

3.8 Mailing List Digest Support



FThe MX MLF processor supports mailing list digests in that subscriber Aentries can be marked "DIGEST" and mail sent to a "-digest" list Eaddress (for example, "List-digest") will be forwarded only to those Asubscribers. Digest subscribers do not receive posts made to the standard mailing list address.

BMX MLF does not provide any support for creating the mailing list Adigests. However, the MX_ROOT:[CONTRIB] directory does contain a Cpackage, MX_DIGEST, for creating digests. You can use MX_DIGEST to Gimplement mailing list digests, or you can supply your own software to do so.

CAll digest posts should be mailed to the "-digest" address for the <list. For example, digests for "MX-List" would be mailed to H"MX-List-Digest". Only the list owner(s) and system user(s) can post to Ethe "-digest" address; messages from other users are diverted to the 4mailing list address and treated as normal postings.d

3.9 Controlling Mailing List Processing



FLarge and busy mailing lists can put a significant burden on a single GMX installation, especially if they have many remote subscribers. This Ecan cause large backlogs to develop in the MX message queue, and may Hprevent non-mailing list mail from being processed in a timely fashion. CIf you intend to host several large mailing lists, you may want to ?dedicate an entire system just to processing mailing list mail.

AThere are two mechanisms you can use, separately or together, to Hprevent mailing list traffic from dominating your mailer. One is to set =up multiple delivery agents (SMTP agents, in particular, for GInternet-connected systems). The number of delivery agents your system >can reasonably support will vary based on your CPU and memory ?configuration, as well as the speed of your network connection.

FThe second mechanism is to limit the number of recipients per message Fgenerated by the mailing list processor, using the /RECIPIENT_MAXIMUM Fqualifier on either the DEFINE LIST command or the SET MLF command in GMCP. When a message comes in for a mailing list with a large number of Esubscribers, MLF will create several copies of the outgoing message, Deach with no more than the maximum number of recipients you set. By Ebreaking up the messages into smaller numbers of recipients, you can Henhance the parallelism of having multiple delivery agents, and prevent Fa single message from tying up any one delivery agent for an extended Dperiod of time. However, setting the recipient maximum to too low a Fvalue can increase the storage requirements for your MX message queue (and create a larger backlog of messages.

FFinding the right combination of delivery agents and recipient limits Grequires careful monitoring of your system. You may need to adjust the Csettings several times before you achieve a reasonable balance. In Faddition, you may need to alter the values on a regular basis if your Hmailing list traffic is "bursty;" i.e., the number of mailing /list messages is not relatively even over time.W

3.10 Mailing List Headers



EThe MCP commands DEFINE LIST and MODIFY LIST accept three qualifiers Dthat allow you to control the header content of mailing list posts. These qualifiers are:





F/STRIP_HEADERS=RECEIVED lets you strip multiple "Received:" Hheaders from posts. Stripping out the "Received:" headers can Hmake it impossible to accurately track the source of a message, but for Fposts coming through multiple gateways, it can significantly cut down (on the total number of headers per post.

G/STRIP_HEADERS=OTHERS lets you strip out all "other" headers Efrom the incoming message before it is mailed out. "Other" cheaders are any headers not documented in the Message Exchange Management Guide under SET BLOCAL/TOP_HEADERS. You can use this qualifier to strip posts from +return-receipt headers, X.400 headers, etc.

F/LIST_HEADERS can be used to enable or disable the following headers, .currently proposed as a new Internet standard:





FAs of this writing, the headers are not an actual standard, hence the Fuse of the "X-" prefix on each. If and when the standard is Hpassed, the prefix will be removed. However, clients that support these Fheaders are supposed to handle both forms. For more information about @the proposal, see "http://arpp.carleton.ca/listspec/".

CFinally, the /XHEADERS qualifier can be used to add site-specified Bheaders to mailing list posts. There are a number of non-standard Dheaders that you may wish to implement, including "Precedence: FBulk", which instructs some versions of sendmail not to generate non-delivery warnings for posts.



/  
Note

DAny string can be supplied as the /XHEADERS value, but care must be Htaken to ensure that the site-specific headers are valid RFC822 headers 8and that they don't conflict with other headers.
 


:

Chapter 4
File Servers




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

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

4.1 Packages



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

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

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

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

Example


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

4First, you would create a directory for the package:

 

"
($ CREATE/DIRECTORY disk:[FILESERV.STUFF]




HNext, 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]




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

 

"
'$ EDIT disk:[FILESERV]STUFF.DESCRIPTION




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

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

 

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




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

4.2 Help File



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

4.3 Transaction Logs



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

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

4.4 File Server Commands



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

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

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

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

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

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



/  
Note

FWhen an ADDRESS command is processed, the file server transaction log Dincludes the original "From:" address. Any user receiving Funasked-for files can use it to determine from whom the request came. 



L

Appendix A
Troubleshooting MLF Problems




EMLF includes a debug mode that displays information about what it is Hdoing when processing mailing list and file server requests. If you are Gexperiencing 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




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

DDebug log files created by MLF are called MX_MLF_DIR:MX_MLF_LOG.LOG.Q

A.1 Case Sensitivity



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

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


Y

Appendix B
Example: Mailing List with Archive Server




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

 

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




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

4You could then create a file server called Archives:

 

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




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

 .
] Contents