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"
These items are described in the subtopics "Named parameters" and
"Positional parameters".
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).
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
Here 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
AUTH_LIST is used to specify a list of addresses that are allowed
to post to the mailing list. The VALUE 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
db> add foo-list "<d1:[sue]sample.dis, [auth_list] d1:[sue]sample.dis"
BLOCKLIMIT
The BLOCKLIMIT and LINELIMIT parameters can be used to limit
the size of messages that can be posted to the list. The VALUE
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
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. The VALUE
specification is currently ignored and should always be NONE.
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
The IMPORTANCE, PRECEDENCE, PRIORITY, and SENSITIVITY named
parameters are used to generate respective headers on messages
posted to the list; the VALUE specification is inserted on the
respective header line.
MODERATOR_ADDRESS
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,
db> add test-list "<d1:[bob]test.dis, [MODERATOR_ADDRESS]
bob@example.com"
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 mem-list "<d1:[bob]mem-list.dis,
[MODERATOR_ADDRESS]bob@example.com,
[MODERATOR_LIST] d1:[bob]mem-list.dis"
SEQUENCE_PREFIX
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. The VALUE 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. The
VALUE item is currently ignored and should always be NONE.
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.
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 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-spec
TAG
The TAG named parameter can be used to prefix specified text to
the Subject: header of posted messages. The VALUE 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. The VALUE item should be the username of
the account to "own" the mailing list postings. Note that the
username specified will be forced to uppercase.
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"
Finally, to make the use of a positional parameter conditional,
end the parameter value with an asterisk. In this case the
value associated with the parameter will only be used if the
corresponding message header line is not present in the message
being posted to the list. (The asterisk will not appear in the
message header should the parameter take effect.)
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
The REPLY-TO-ADDRESS parameter specifies an address to be used as
a Reply-to: address.
errors-to-address
The ERRORS-TO-ADDRESS parameter specifies an address to be placed
on the Errors-to: header, if this address should be different
from the ERROR-RETURN-ADDRESS that is used as the envelope From:
address.
warnings-to-address
The WARNINGS-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
The COMMENTS 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.
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 below. The
commands used to set up the list are also shown below. 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 2 Sample Mailing list: the Mailing List File
bob@example.com
judy@example.com
ralph@example.com
sue@example.com
Example 3 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
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
where the D1:[ALAN]FRIENDS-LIST-STAGE2.DIS file contains just the
line:
friends-list
and the D1:[ALAN]FRIENDS-LIST.DIS contains all the actual
recipient addresses.