Previous | Contents | Index |
PMDF DB allows you to control who can or cannot post to mailing lists as well as associate error return, reply to, and other special addresses with mailing lists. To use these features, an extended alias specification must be used when declaring the alias for the mailing list:
db> add alias-name "<filename, named-parameters, error-return-address, reply-to-address, errors-to-address, warnings-to-address, comments" |
named-parameters
item is described in Section 9.3.4.1; the remaining items, called
"positional parameters", are described in Section 9.3.4.2.
The two positional parameters error-return-address
and reply-to-address
are two particularly useful items. You are strongly encouraged to use the error-return-address
parameter so as to control where error messages concerning postings to your list are directed. You can use the reply-to-address
parameter to make the preferred reply address the list address (or some
other address).
9.3.4.1 Named Parameters
Named-parameters are used to associate options with a mailing list.
There can be zero or more of named parameters, each separated by
commas, and they must appear before any positional parameters. The
general syntax of a named-parameter is:
[name] value |
name
is the name of the parameter and value
is its corresponding value. The square brackets are a mandatory part of
the syntax: they do not indicate an optional field.
The available named parameters are:
AUTH_LIST
CANT_LIST
AUTH_LIST is used to specify a list of addresses that are allowed to post to the mailing list. Thevalue
item must be the full file path specification for a world readable file containing the list of addresses allowed to post to the list. When someone attempts to post a message to the mailing list, PMDF will attempt to match their address against the addresses in the list; if no match occurs, the attempted posting will be sent to the owner of the list. CANT_LIST has the opposite effect as AUTH_LIST: it supplies the full file path specification of a world readable file containing a list of addresses which cannot post to the list. One common use of this facility is to restrict a list so that only list members can post. This can be done by specifying the same file as both the mailing list file and the AUTH_LIST file. For example, assuming that the mailing list is named foo-list and the associated file is D1:[SUE]SAMPLE.DIS, the alias declaration would be
An example of using AUTH_LIST can be found in Section 9.3.4.3.
db> add foo-list "<d1:[sue]sample.dis, [auth_list] d1:[sue]sample.dis"BLOCKLIMIT
LINELIMIT
The BLOCKLIMIT and LINELIMIT parameters can be used to limit the size of messages that can be posted to the list. Thevalue
item must be an integer number of PMDF blocks, for [BLOCKLIMIT], or an integer number of lines, for [LINELIMIT]. The size of a PMDF block is normally 1024 bytes. The default value for these parameters is 0, meaning that no limit is imposed on the size of message that can be posted to the list (apart, that is, from any system wide limits).DELAY_NOTIFICATIONS
NODELAY_NOTIFICATIONS
The DELAY_NOTIFICATIONS named parameter requests that NOTARY delay notifications be sent for mailing list postings; the NODELAY_NOTIFICATIONS named parameter requests that NOTARY delay notifications not be sent for mailing list postings. Thevalue
specification is currently ignored and should always beNONE
.HEADER_ADDITION
HEADER_ADDITION can be used to specify a file of headers to be added to posted messages. The argument must be a full file specification for the file containing headers to be added. In particular this facility can be used to add the standard mailing list headers defined in RFC 2369. For instance, a user amy@example.com that has set up a public list named listname might use a header addition file along the lines of the following:
List-Help: <mailto:amy@example.com?subject=help%20on%20listname> List-Subscribe: <mailto:amy@example.com?subject=subscribe%20listname> List-Unsubscribe: <mailto:amy@example.com?subject=unsubscribe%20listname> List-Post: <mailto:amy+listname@example.com> List-Owner: <mailto:amy@example.com?Subject=listname> List-Archive: <mailto:amy@example.com?subject=request%20listname%20archive>IMPORTANCE
PRECEDENCE
PRIORITY
SENSITIVITY
The IMPORTANCE, PRECEDENCE, PRIORITY, and SENSITIVITY named parameters are used to generate respective headers on messages posted to the list; thevalue
specification is inserted on the respective header line.MODERATOR_ADDRESS
MODERATOR_LIST
The MODERATOR_ named parameters are used to establish a moderated mailing list. All postings to the list not originating from a moderator are sent to the list's moderator. The address of the moderator must be specified with the MODERATOR_ADDRESS named parameter. The moderator address determines where moderator mail is sent when someone other than the moderator posts. The value of that named parameter is the moderator's address. For example,
When there can be multiple moderator addresses (for instance, both robert@a1.example.com and bob@example.com) use MODERATOR_LIST to specify all addresses from which postings should be passed directly to the list and not sent to the list's moderator. MODERATOR_LIST specifies the name of a file containing a list of moderator addresses. If a MODERATOR_LIST parameter is used, thereby specifying who can post directly to the list, then a MODERATOR_ADDRESS parameter should also be present to specify the address to which to send postings not from any moderator. The use of the MODERATOR_ADDRESS parameter alone, without the MODERATOR_LIST parameter, is equivalent to using MODERATOR_ADDRESS and a MODERATOR_LIST consisting of just the one moderator address. Note that one use of MODERATOR_ADDRESS and MODERATOR_LIST is to set up a list wherein anyone on the list can post directly, but attempts to post by addresses not subscribed to the list will be referred to a moderator. For instance,
db> add test-list "<d1:[bob]test.dis, [MODERATOR_ADDRESS] bob@example.com"
db> add mem-list "<d1:[bob]mem-list.dis, [MODERATOR_ADDRESS]bob@example.com, [MODERATOR_LIST] d1:[bob]mem-list.dis"SEQUENCE_PREFIX
SEQUENCE_SUFFIX
SEQUENCE_STRIP
The SEQUENCE_PREFIX and SEQUENCE_SUFFIX named parameters request that a sequence number be prepended or appended to the Subject: lines of messages posted to the list. Thevalue
item gives the full file path specification of a sequence number file. This file is read, incremented, and updated each time a message is posted to the list. The number read from the file is prepended, in the case of SEQUENCE_PREFIX, or appended, in the case of SEQUENCE_SUFFIX, to the message's Subject: header line. This mechanism provides a way of uniquely sequencing each message posted to a list so that recipients can more easily track postings and determine whether or not they have missed any. By default, a response to a previously posted message (with a previous sequence number) retains the previous sequence number as well as adding a new sequence number to the subject line; the build up of sequence numbers shows the entire thread of the message in question. However, the SEQUENCE_STRIP named parameter can be used to request that only the highest numbered, i.e., most recent, sequence number be retained on the subject line. Thevalue
item is currently ignored and should always beNONE
.
Sequence number files are binary files and must have the proper file attributes and access permissions in order to function correctly. In particular, sequence number files must be writeable from the perspective of the PMDF user account. A PMDF user account must exist for sequence number files in personal alias databases to work properly. If your system administrators have not created a PMDF user account, then you will not be able to use this sequence numbering facility. To create the file
Important note
To ensure that sequence numbers are only incremented for successful postings, a SEQUENCE_PREFIX or SEQUENCE_SUFFIX named parameter should always appear as the last named parameter; that is, if other named parameters are also being used, the SEQUENCE_ named parameter should appear at the end of the list of named parameters.seq-file-spec
with the proper attributes and access permissions for use as a sequence number file, issue the command:
$ CREATE/FDL=PMDF_COM:sequence_number.fdl seq-file-specTAG
The TAG named parameter can be used to prefix specified text to the Subject: header of posted messages. Thevalue
item should be the string to be added.USERNAME
The USERNAME named parameter can be used to set the "username" that PMDF will consider to "own" these mailing list messages. For instance, the PMDF QM utility will allow that username to inspect and bounce messages in the queue resulting from expansion of this mailing list. Thevalue
item should be the username of the account to "own" the mailing list postings. Note that the username specified will be forced to uppercase.
9.3.4.2 Positional Parameters
With one exception, the positional parameters in a mailing list
specification provide alternate addresses to which certain sorts of
list related activity should be directed (e.g., an address to
which errors should be sent to rather than back to the list itself).
The positional parameters are so named for a reason: their position in the comma separated list distinguishes which parameter is being specified. When more than one parameter (positional or otherwise) is specified, they must be separated by commas. If you want to specify a positional parameter but omit some which come first, then specify asterisks, *, for the positional parameters which you want to omit. For example,
db> add foo-list "<d1:[sue]sample.dis, *, *, sue@example.com" |
Without further ado, the positional parameters are:
error-return-address
error-return-address
specifies an address to replace the message's regular envelope From: address as well as an address to be inserted into the header as an Errors-to: address. This header line is not generated if this address is not specified.reply-to-address
Thereply-to-address
parameter specifies an address to be used as a Reply-to: address.errors-to-address
Theerrors-to-address
parameter specifies an address to be placed on the Errors-to: header, if this address should be different from theerror-return-address
that is used as the envelope From: address.warnings-to-address
Thewarnings-to-address
parameter specifies an address to be placed on the Warnings-to: header line. This header line is not generated if this address is not specified.comments
Thecomments
parameter specifies a string to be placed in a Comments: header line. This header line will add to any Comments: header lines already present in the message being posted to the list.
9.3.4.3 Examples
In this example, the user sue@example.com sets up a mailing list named
sample-list. The mailing list file is the file D1:[SUE]SAMPLE.DIS and
its contents are shown in Example 9-1. The commands used to set up
the list are shown in Example 9-2. In that example, the add command
must be entered as one line; it is shown broken into two lines for
typographical reasons only. Mail is posted to the list by sending
messages to the address sue+sample-list@example.com.
The use of the AUTH_LIST named parameter in the alias declaration restricts the list such that only members of the list can post to it. Two positional parameters, errors-to-address
and comments
,
are also specified. The errors-to-address
parameter specifies that error messages associated with the list should be sent to sue@example.com; the comments
parameter generates a Comments: header line reading "Sue's sample
list". which will appear in each posting to the list.
Example 9-1 Sample Mailing list: the Mailing List File |
---|
bob@example.com judy@example.com ralph@example.com sue@example.com |
Example 9-2 Sample Mailing List: Declaring the Alias |
---|
$ SET PROTECTION=(W:R) D1:[SUE]SAMPLE.DIS $ PMDF DB db> add sample-list "<d1:[sue]sample.dis,[auth_list]d1:[sue]sample.dis, sue@example.com,*,*,*,Sue's sample list" db> set foo-list public db> exit |
9.3.4.4 Length Restriction on List Definitions
Keep in mind the length limit of alias expansion values of 252
characters when defining a more sophisticated mailing list with
multiple parameters. Most lists can be suitably defined with just a few
of the possible mailing list parameters discussed above. But if you
have a list for which you really want to use a lot of parameters, then
you might need to define the list in stages.
For instance, to define a list friends-list that has MODERATOR_ADDRESS, MODERATOR_LIST, CANT_LIST, USERNAME, and IMPORTANCE named parameters, as well as error-return-address and comments positional parameters, the list can be defined in two stages, using a subsidiary friends-list-stage2 definition, e.g.,
db> add friends-list "<d1:[alan]friends-list-stage2.dis, [MODERATOR_ADDRESS] alan@example.com, [MODERATOR_LIST] d1:[alan]friends-list.dis, [CANT_LIST] d1:[alan]bozos.dis, [USERNAME] ALAN" db> add friends-list-stage2 "<d1:[alan]friends-list.dis, [IMPORTANCE] High, alan@example.com, *, *, *, A chatty message list for Alan's friends -- contact Alan at 555-1212 for more information" db> set friends-list public |
d1:[alan]friends-list-stage2.dis
file contains just the line:
friends-list |
d1:[alan]friends-list.dis
contains all the actual recipient addresses.
Previous | Next | Contents | Index |