This 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.3
The information in this document is subject to change 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.
No part of this publication may be reproduced, 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 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 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.
Compaq, DECnet, OpenVMS, VAX, and VMS are registered trademarks of Compaq Information Technologies Group, L.P. in the United States and other countries. All other product names may be trademarks of their respective companies.
MultiNet and TCPware are registered trademarks of Process Software Corporation.
LISTSERV is a registered trademark of L-Soft International.
WIN/TCP and Pathway are registered trademarks of Attachmate, Inc.
Portions of the software were adapted from the NetBSD Project. Refer to the Release Notes for copyright information.
| Contents |
This guide describes the management and operation of the Message Exchange Mailing List/File Server (MX MLF).
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.
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. |
You can find additional information in the following documents:
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, on a wide variety of technical and non-technical topics.
Unfortunately, there are no widely-enforced 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 most Internet mailing lists, 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@MadGoat.Com. Subscription requests, removals, or comments about the list are sent to MX-List-request@MadGoat.Com.
MLF provides support for both the typical Internet -request interface and a subset of the interface used by L-Soft's ListServ for its automatic command handling. The special addresses MXSERVER and MXSERV are recognized by MX Router as the MLF ListServ-style interface. If you also want LISTSERV to be recognized, then you must define it as an alias using the MCP command DEFINE ALIAS. For example:
MCP> DEFINE ALIAS LISTSERV "MXserver@hostname" |
There are no standards for file servers. There are several file server implementations in existence: LISTSERV, VMSSERV, MAILSERV, and several others. 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.
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.
Unless the list is defined with /NOCASE_SENSITIVE, the mailing list processor is case sensitive when matching the username portion of addresses. Be sure to enter the list manager addresses using the correct case. MX, by default, converts all usernames to lower case for local users, so you should generally use lower case when specifying local list managers' addresses. |
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.
Unless the list is defined with /NOCASE_SENSITIVE, the mailing list processor is case sensitive when matching the username portion of addresses. Be sure to enter the owner addresses using the correct case. MX, by default, converts all usernames to lower case for local users, so you should generally use lower case when specifying local owner addresses. |
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 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.
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.
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 a 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.
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.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.
| 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 |
| 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 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.
| (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. |
Since electronic mail can readily be forged, you should not depend on this protection scheme for absolute security of your mailing lists. The mailing list processor attempts no authentication of addresses when it receives messages. |
By default, information about all defined mailing lists is returned to
a user in response to a DIRECTORY command sent to MXSERVER or a
-Request address. The /PRIVATE qualifier can be given on the DEFINE
LIST command to prevent information about a list from being included in
MXSERVER directories. The list information will only include those
lists that are not marked /PRIVATE.
3.3 Automatic Request Handling
MLF will answer requests automatically at both a list's -Request address and through the MXSERVER interface. The commands it recognizes through the -Request interface are listed in Table 3-4. MXSERVER commands are listed in Table 3-5.
| Command | Description |
|---|---|
| ADD address[,...] | Control command: allows list owner to add other users to the list. |
| HELP | Sends file MX_MLIST_DIR:MLIST_HELP.TXT. |
| LIST | Lists all available non-private mailing lists. |
| MODIFY address | Control command: allows list owner to modify a subscriber's settings. |
| QUERY | Returns the subscriber's status on the list. |
| QUIT | Causes all remaining lines in the message to be ignored. |
| REMOVE address[,...] | Control command: allows list owner to remove other users from the list. |
| REVIEW | Returns information about the list, and the list of subscribers. |
| REVIEW/BRIEF | Returns only the list of subscribers. |
| SET [NO]MAIL | Enables/disables receipt of list messages. |
| SET [NO]CONCEAL | Controls whether subscriber is concealed from view in REVIEW listings. |
| SET [NO]REPRO | Controls whether subscriber receives a posting s/he makes to the mailing list. |
| SET [NO]DIGEST | Controls whether subscriber receives all posts or a daily digest of posts to a list. |
| SIGNOFF | Removes the user from the list of subscribers. |
| SUBSCRIBE | Adds the user to the subscriber list. |
| Command | Description |
|---|---|
| ADD list-name address[,...] | Control command: allows list owner to add other users to the list. |
| HELP | Sends file MX_MLIST_DIR:MLIST_HELP.TXT. |
| LIST | Lists all available non-private mailing lists. |
| MODIFY list-name address[,...] | Control command: allows list owner to modify subscriber settings. |
| QUERY list-name | Returns the subscriber's status on the list. |
| QUIT | Causes all remaining lines in the message to be ignored. |
| REMOVE list-name address[,...] | Control command: allows list owner to remove other users from the list. |
| REVIEW list-name | Returns information about the list, and the list of subscribers. |
| REVIEW/BRIEF list-name | Returns only the list of subscribers. |
| 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. |
| SET list-name [NO]DIGEST | Controls whether subscriber receives all posts or a daily digest of posts to a list. |
| SIGNOFF list-name | Removes the user from the list of subscribers. |
| SUBSCRIBE list-name | Adds the user to the subscriber list. |
SUBSCRIBE requests are handled automatically only if the WORLD protection class is granted E (Enroll) access to the list. Otherwise, they are forwarded to the list owners for manual handling. If the list is configured with /REQUEST_CONFIRMATION, subscribers will be asked to confirm their subscription requests before being added to the list; if a reply to the requested confirmation does not arrive within the confirmation interval, the subscription request is ignored.
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.3.1 Control Commands
The mailing list processor supports three control requests: ADD, MODIFY, 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, or change their per-subscriber settings.
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 List Owner Notification Messages
The mailing list processor can notify the list owner(s) of changes to the mailing list. By default, no such notifications are sent. Supported list owner notifications are show in Table 3-6. To enable any or all these notifications, use the /NOTIFY qualifier on the MCP DEFINE LIST command. See the Message Exchange Management Guide for more information.
| Type | Description |
|---|---|
| ADD | Notification sent when a user is successfully added to the list. |
| REMOVE | Notification sent when a user is successfully removed from the list. |
| REQUEST | Notification sent when a confirmation request is sent or timed out. |
| SET | Notification sent when a user's subscription settings are successfully modified. |
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-7 lists the types of messages you can set up and when they are sent.
| 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 | when a user is removed from a mailing list |
| /FORWARD_MESSAGE | MLIST_FORWARD_MESSAGE.TXT | when a user attempts to subscribe to a list with no W:E access |
| /CONFIRMATION_MESSAGE | MLIST_CONFIRM_MESSAGE.TXT | when a subscription confirmation request is issued |
The global default message files are located in MX_MLIST_DIR. You can customize these files to suit your site's needs for all mailing lists, or use them as templates for the per-list files.
Customization Variables
The text of a notification message can contain references to customization "variables" whose values are supplied by the mailing list processor. Available variables are:
| {list-address} | the RFC822 address of the mailing list |
| {request-address} | the RFC822 address of the list's -Request address |
| {list-name} | the name of the mailing list (no @hostname) |
| {list-desc} | the contents of the list description, as specified by the /DESCRIPTION qualifier on the DEFINE LIST command |
| {list-owner} | the address of the owner of the mailing list (if there are multiple owner addresses, only the first is used) |
| {confirmation-deadline} | an RFC822 date/time stamp for displaying the deadline by which a subscription request must be confirmed; meaningful only in confirmation messages. |
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.6 VMS Mail Forwarding
You can make it easier for local users and DECnet-connected users to send messages to a mailing list by creating a forwarding address in VMS Mail for the list name:
$ MAIL MAIL> SET FORWARD/USER=list-name MX%list-name |
This will allow users to use just the list name when addressing the mailing list, without the MX% prefix.
If the list name ever changes or the list is deleted, you should remember to remove the forwarding address from VMS Mail for the list name:
MAIL> REMOVE list-name |
This will prevent a possible mail looping problem from occurring.
3.7 Using the ADD, MODIFY, and REMOVE Commands
The list processor provides commands for use exclusively by list owners
and list server managers: ADD, MODIFY, and REMOVE.
3.7.1 ADD and MODIFY Commands
The ADD command adds one or more users to a mailing list. The MODIFY command modifies the various per-user settings for an existing list subscriber. The syntax for these command for the -Request interface is:
ADD [qualifiers] address [,...] MODIFY [qualifiers] address [,...] |
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-mail message.
For address, you should enter the RFC822-type address for the user to be added. It should generally appear exactly as it does on the From line of a message, since the mailing list processor is case sensitive in the username part of addresses. You may include the personal name, if desired: ADD/NONOTIFY "Joe User"<user@host.site.domain>
Valid qualifiers that can be specified are:
By default, subscriber entries are set to MAIL, CASE, NOCONCEAL, REPRO, NODIGEST, NODENY, NOACCESS, and 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 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. MODIFY commands do not trigger any notification to the affected subscribers.
Use the /[NO]CONFIRM qualifier to override the /[NO]REQUEST_CONFIRMATION setting for the list---with /CONFIRM, a confirmation request is sent to the subscriber before the addition is processed. With /NOCONFIRM, the addition is processed immediately.
The /NOMAIL qualifier is used to add the user to the mailing list as a NOMAIL subscriber. That is, the user is on the list without receiving any mail from the list. NOMAIL subscriptions are used for private mailing lists, where only the subscribers are allowed to post, and for mailing lists that control access to file servers; a subscriber might have multiple addresses and may need access to the list or file server from any of those addresses.
The /NOCASE qualifier is used to add the user to the mailing list while having the list processor disregard the case of the username portion of the address. Normally, the list processor is case-sensitive regarding usernames unless the list was defined with DEFINE LIST/NOCASE_SENSITIVE.
The /CONCEAL qualifier is used to set the CONCEAL flag in the subscriber's entry in the list. CONCEALed users do not appear in REVIEW listings, except for those requested by the list owners.
The /NOREPRO qualifier is used to prevent the subscriber from receiving a copy of postings s/he makes to the list.
The /NOPOST qualifier is used to prevent the subscriber from posting to the list. Note that if the 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 posts made to the "-digest" address for a list. For more information on digests, see Section 3.9.
The /DENY qualifier can be used to add a subscriber 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 to the list, cannot change their subscriber entry, and cannot remove themselves from the list.
The DENY setting was added specifically to provide the list owner with the ability to keep problem 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 that matches an access control entry is granted the corresponding GROUP privileges for the list. For example, if a list is open to posts only from members of the list, an access control address can be specified to allow any user from a particular site to post a message.
In addition, file servers, described in Chapter 4, can be set up so that they are associated with a mailing list. Any user wishing to use such a file server must be subscribed to the associated mailing list, or access to the file server will be denied. The /ACCESS qualifier provides a way to allow unrestricted file server access to certain addresses without having to subscribe every possible address to the mailing list.
For example, suppose you have a file server that is to be used only by users from systems at XYZ.COM and YYZ.COM. Instead of listing each possible user at both sites, ACCESS entries can be made to the list that will match users at those sites:
ADD/ACCESS/NOCASE <*@*.XYZ.COM> ADD/ACCESS/CONCEAL <*@*.YYZ.COM> |
These addresses are automatically marked /NOMAIL and /NOREPRO so that they never receive messages posted to the mailing list. They also never receive any notifications when added to or removed from the list. The /NOCASE and /CONCEAL qualifiers may be given as desired.
Subscriber reviews of lists containing access control entries show
those entries as having the ACCESS attribute.
3.7.2 REMOVE
The REMOVE command removes other users from a mailing list. The syntax for this command for the -Request interface is:
REMOVE [/NONOTIFY] [/NOCASE] address [,...] |
REMOVE [/NONOTIFY] [/NOCASE] 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 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 from the mailing list
while having the list processor disregard the case of the username
portion of the address. Normally, the list processor is case-sensitive
regarding usernames unless the list was defined with DEFINE
LIST/NOCASE_SENSITIVE.
3.8 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.9 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, "List-digest") will be forwarded only to those subscribers. Digest subscribers do not receive posts 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-List" would be mailed to
"MX-List-Digest". Only the 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.10 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 system just to processing mailing list mail.
There are two mechanisms you can use, separately or together, to prevent mailing list traffic from dominating your mailer. One is to set up multiple delivery agents (SMTP agents, in particular, for Internet-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.
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 mailing list with a large number of subscribers, MLF will 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 a single message from tying up any one delivery agent 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. In
addition, you may need to alter the values on a regular basis if your
mailing list traffic is "bursty;" i.e., the number of mailing
list messages is not relatively even over time.
3.11 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:
/STRIP_HEADERS=RECEIVED lets you strip multiple "Received:" headers from posts. Stripping out 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.
/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.
/LIST_HEADERS can be used to enable or disable the following headers, currently proposed as a new Internet standard:
As of this writing, the headers are not an actual standard, hence the use of the "X-" prefix on each. If and when the standard is passed, the prefix will be removed. However, clients that support these headers are supposed to handle both forms. 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. There are a number of non-standard headers that you may wish to implement, including "Precedence: Bulk", which instructs some versions of sendmail not to generate non-delivery warnings for posts.
Any string can be supplied as the /XHEADERS value, but care must be taken to ensure that the site-specific headers are valid RFC822 headers and that they don't conflict with other headers. |
The mailing list processor has built-in filters that can be used to
prevent undesirable messages from being posted to a mailing list. These
filters are configured through qualifiers on the MCP DEFINE LIST
command.
3.12.1 Message Size Filter
You can set a maximum message size for list postings with the /MAXIMUM_MESSAGE_SIZE qualifier. Messages exceeding this size are returned to sender with an error. Note that the size limit is applied only to the contents of the message body; headers are ignored for size calculations.
This feature can be used to prevent users from inadvertantly posting
messages with large attachments, which might be undesirable for mailing
lists with a large number of subscribers.
3.12.2 Content Type Filter
You can configure a list to accept only plain-text messages with the /TEXT_ONLY qualifier. Messages with a Content-Type: header that identifies the message content as other than "text/plain" are returned to sender with an error.
This feature can be used to help reduce junk mail postings to mailing lists, which are often formatted in HTML. It can also be used to prevent users from inadvertantly posting multi-part messages, which are often used when attaching files to e-mail messages.
If you configure a mailing list for text only, you may want to inform
subscibers so they can configure their e-mail client programs to format
list postings as text.
3.12.3 Junk Mail Filter
You can configure a list to filter out messages based on RFC822 headers with the /IGNORE qualifier. Two types of filters are supported: one based on the To:/CC: headers, and one based on the MX-specific X-Junk-Mail-Rating: header. Messages matching a configured filter are silently dropped; the mailing list processor records the drop by writing a message to its log file.
The MISSING_LIST_ADDRESS filter drops messages if the mailing list's address does not appear in either the To: or CC: header of a list posting---this is a frequent occurrence with junk e-mail. Note, though, that when this filter is enabled, users must ensure that they address messages directly to the list, rather than through some other alias.
The JUNK_MAIL filter drops messages in conjunction with the junk-mail detection heuristics provided by MX's SMTP server. The heuristic filters will add an "X-Junk-Mail-Rating:" header to messages that have some probability of being junk mail, along with a keyword indicating LOW, MEDIUM, or HIGH probability. Only those messages with the probability rating you specify, or higher, are dropped.
For more information on heuristic junk e-mail filters, see the Message Exchange Management Guide.
The MCP DEFINE FILE_SERVER command is used to set up a file server. Each file server can automatically service requests for single files or groups of files. Large files can be delayed to non-prime-time hours, on a per-server basis. You can specify a per-server, per-host, and/or per-user byte count limit, to prevent users from overtaxing the mail system with file server requests. In addition, you can link a file server to a mailing list, so that only those users who are subscribed to the list can gain access to the file server.
Access control entries in a mailing list can be used to allow any user
at particular sites to access the file server. See Section 3.7.1 for
more information on access control entries.
4.1 Packages
The file server is designed to handle groups of files, called packages. When you create a package, you create a directory with the name of that package; all files in that directory that are to be shipped when the package is requested must have file names that are the same as the package name.
In addition, you must place a description file either above the package directory or in the package directory itself. This description file is sent when a user requests a listing of available packages.
The description file must be named package.DESCRIPTION, where package is again the package name.
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. 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.
To demonstrate the structure used by the file server, let us suppose you have created a package called STUFF. You used VMS_SHARE to create the package, which split the package into three parts.
First, you would create a directory for the package:
$ CREATE/DIRECTORY disk:[FILESERV.STUFF] |
Next, you would copy the VMS_SHARE files into that directory. They must have file names the same as the package name:
$ COPY STUFF.* disk:[FILESERV.STUFF] |
Next, you would create a file containing a brief description of the package and place it above the STUFF directory:
$ EDIT disk:[FILESERV]STUFF.DESCRIPTION |
If you prefer, the .DESCRIPTION files for all packages under [FILESERV] can be placed in the package directories with the other files. However, description files cannot be located in both places.
Finally, you would need to set up the file server in MCP:
MCP> DEFINE FILE_SERVER FILESERV/ROOT=disk:[FILESERV.] |
The file server FILESERV will now automatically handle distribution of
the STUFF package.
4.2 Help File
The file FILESERV_HELP.TXT, provided by the installation procedure in
directory MX_ROOT:[MLF], contains a description of the file service
commands. You should update this file to include the address you have
chosen for your file server and any other information specific to the
file server that you wish to include. Place the edited copy in the root
directory of your file server to have it sent when a user sends a HELP
command to your file server.
4.3 Transaction Logs
For each mail message received by the file server, a transaction log is created that contains the results of each command in the message. When all commands have been processed, this transaction log is mailed back to the user. The transaction log lets the user know the status of the files requested, for example, when they'll be mailed, if the file server has been defined to delay files to off-hours times.
If you have important information that you want all users accessing
your file server to see, you can create a file called
FILESERV_TRANSACTION.TXT that contains the text. When this file is
placed in the root directory for the file server, its contents will be
included at the beginning of every transaction log mailed out. This
transaction header can be useful for letting users know of scheduled
downtimes or a change in package availability, for example.
4.4 File Server Commands
The five commands accepted by the file server are SENDME, LIST (or DIRECTORY), HELP, QUIT, and ADDRESS. Each may be abbreviated to the smallest unique string. One command is allowed per line of text in a request message, but several command lines may be sent in one request.
SENDME takes either a package name (to have all parts of a package sent) or a file name (to have just one part sent). Large files are delayed until non-prime-time hours if enabled when file service is set up.
LIST takes a pattern which is used to match against package names. The description file for each matching package is added to a message that is returned to the requesting user. If no pattern is specified, "*" is used.
HELP causes the file FILESERV_HELP.TXT (located in the root directory of the file server) to be sent to the requesting user.
QUIT causes the file server to ignore any remaining lines in the mail message. Because many people have mail signatures automatically included messages, the QUIT command can be used to prevent the unintentional parsing of those signatures as file server commands.
ADDRESS provides the user with the ability to specify a valid RFC822-compliant e-mail address to which any FileServ output is to be sent. Normally, any files requested from FileServ are sent to the address in the "Reply-To:" or "From:" lines in the message headers. However, addresses are sometimes corrupted by gateways through which the message passes, resulting in an invalid return address. File server users can use the ADDRESS command to provide a valid alternate to the "From:" address.
When an ADDRESS command is processed, the file server transaction log includes the original "From:" address. Any user receiving unasked-for files can use it to determine from whom the request came. |
MLF includes a debug mode that displays information about what it is doing when processing mailing list and file server requests. If you are experiencing problems with either a mailing list or a file server, you can enable this debug mode with the command:
$ DEFINE/SYSTEM MX_MLF_DEBUG TRUE |
If you are in a VMScluster, this logical must be defined on the same node as the currently active MX MLF process to have any effect.
Debug log files created by MLF are called MX_MLF_DIR:MX_MLF_LOG.LOG.
A.1 Case Sensitivity
Unless the list was created with DEFINE LIST/NOCASE_SENSITIVE, the mailing list processor uses case-sensitive matching on the username part of addresses when looking up users on the subscriber list (except for subscribers with the NOCASE flag set), owner list, and SYSTEM_USERS list. Be careful when adding and removing users from these lists that the case of the username part of the address exactly matches what will be in the From: header of the address.
Remember that MX automatically converts usernames to lower case, by default, when creating the From: header, so messages originating on the local system will have lower case usernames.
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".
| Contents |