PMDF User's Guide
UNIX Edition

pmdf db allows you to control a variety of aspects of messages posted to a mailing list alias, including associating 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"

The named-parameters item is described in Section 6.4.3.1; the remaining items, called "positional parameters", are described in Section 6.4.3.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 some specified address.

6.4.3.1 Named Parameters

[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:

BLOCKLIMIT

LINELIMIT

The BLOCKLIMIT and LINELIMIT parameters may be used to limit the size of messages that may 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 may 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. The value specification is currently ignored and should always be NONE .

HEADER_ADDITION

HEADER_ADDITION may 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 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@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; the value specification is inserted on the respective header line.

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. 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, normally pmdfuser . To create the file seq-file-spec for use as a sequence number file, issue the command:

% touch seq-file-spec

or

% cat >seq-file-spec

You will then need to have your system manager allow the pmdfuser account access to the file by setting the userid and groupid for the file to the values for the pmdfuser account.

TAG

The TAG named parameter may 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 may 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.

6.4.3.2 Positional Parameters

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 sample-list "</usr/users/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.

6.4.3.3 Examples

Two positional parameters, error-return-address and comments , are specified. The error-return-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 6-1 Sample Mailing List: The Mailing List File

bob@example.com judy@example.com ralph@example.com sue@example.com

Example 6-2 Sample Mailing List: Declaring the Alias

% pmdf db db> add foo-list "</usr/users/sue/sample.dis,sue@example.com,*,*,*,Sue's sample list" db> exit

6.4.3.4 Length Restriction on List Definitions

For instance, to define a list friends-list that has HEADER_ADDITION , NODELAY_NOTIFICATIONS , SEQUENCE_PREFIX , 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 "</usr/users/alan/friends-list-stage2.dis,[HEADER_ADDITION] /usr/users/alan/friends-list-headers.txt,[NODELAY_NOTIFICATIONS] NONE,[SEQUENCE_PREFIX] /usr/users/alan/friends.seq,[USERNAME] alan" db> add friends-list-stage2 "</usr/users/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"

where the /usr/users/alan/friends-list-stage2.dis file contains just the line:

friends-list

and the /usr/users/alan/friends-list.dis contains all the actual recipient addresses.