Alias file named parameters

From Messaging Server Technical Reference Wiki
Jump to: navigation, search

This discussion describes alias file named parameters as set in legacy configuration in the aliases file. In Unified Configuration, the equivalent settings are alias options.

The named-parameters appearing in an alias file mailing list definition such as

alias: <file-spec, named-parameters, error-return-address, \
       reply-to-address, errors-to-address, \
       warnings-to-address, comments

or

alias: <ldap-url, named-parameters, error-return-address, \
       reply-to-address, errors-to-address, \
       warnings-to-address, comments

or in an individual alias definition (see Alias file format) such as

alias: named-parameters,address-1,...,address-n

are used to specify optional modifiers to the list expansion process. There can be zero or more named parameters, separated by commas, and they must appear before any positional parameters (e.g., error-return-address, reply-to-address, etc.). 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.

See Alias header addition modifiers for a description of controls on the effect of named parameters relating to the addition of headers, such as specifying whether a header is to be added only if not originally present, or added unconditionally, and whether the header supplements or substitutes for an originally present header.

The available named parameters are:

AND, OR

AND and OR control whether subsequent access control clauses (e.g., [AUTH_LIST], [AUTH_MAPPING], etc.) are ANDed or ORed. The default is controlled by the or_clauses MTA option---and is AND (for backwards compatibility) by default. For groups and lists defined in LDAP, see also the AND and OR values for the mgrpBroadcasterPolicy attribute (or more precisely, the attribute named by the ldap_auth_policy MTA option). For a more detailed discussion, see Mailing list multiple access control interpretation.

In Unified Configuration, see the alias_and and alias_or alias options.

AUTH_CHANNEL, CANT_CHANNEL

AUTH_CHANNEL is used to specify a source channel or channels that may submit messages to the mailing list. CANT_CHANNEL is used to specify a source channel or channels that may not submit messages to the mailing list. The argument should be a (possibly wildcarded) channel name, or a space-separated list of (possibly wildcarded) channel names.

In Unified Configuration, see the alias_auth_channel and alias_cant_channel alias options.

AUTH_LIST, CANT_LIST, USERNAME_AUTH_LIST, USERNAME_CANT_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 either the full file path specification for a world readable file containing the list of addresses allowed to post to the list, or an LDAP URL that returns the list of addresses allowed to post to the list. The MTA will match the envelope From address against the addresses in the list; if no match occurs, the attempted posting fails and an error is returned to the would be posting's originator. USERNAME_AUTH_LIST is analogous to AUTH_LIST, but for (possibly wildcarded) usernames rather than addresses; note that usernames are generally only useful for messages submitted from the L channel or submitted with SASL authentication via SMTP (SMTP AUTH) since for messages submitted from other sources the username will simply be that of the account under which the submitting MTA process is running. Note that for messages submitted via SMTP with authentication (SMTP AUTH), the username that authenticated will be prefixed with the asterisk, *, character. For instance, to specify that only the user JDOE may submit to a list, whether submitting from the L channel or via SMTP (e.g., from a POP or IMAP client that performs SASL SMTP authentication), the USERNAME_AUTH_LIST file would need to contain the entries:


JDOE 
$*JDOE 

where the first entry would match for messages submitted from the L channel and the second entry would match for messages submitted via SMTP AUTH. Note that as asterisk is normally a wildcard character, matching of only the exact literal asterisk character is specified by using the dollar character to quote the asterisk.

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, or an LDAP URL returning a list of addresses, specifying which addresses may not post to the list. USERNAME_CANT_LIST is analogous to CANT_LIST, but for (possibly wildcarded) usernames rather than addresses; note that usernames are generally only useful for messages submitted from the L channel or submitted with SASL authentication via SMTP (SMTP AUTH) since for messages submitted from other sources the username will simply be that of the account under which the submitting MTA process is running.

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 list file and the AUTH_LIST file. For example, assuming that the list is named test-list and the list file is IMTA_TABLE:test-list.dis, the alias file entry would be:


test-list: <IMTA_TABLE:test-list.dis, \
             [auth_list] IMTA_TABLE:test-list.dis 

For groups and lists defined in LDAP, the closest analogues are the mgrpAllowedBroadcaster and mgrpDisallowedBroadcaster attributes (more precisely, the attributes named by the ldap_auth_url and ldap_cant_url MTA options); and if wishing to compare against authenticated submission addresses, see also the SMTP_AUTH_REQUIRED value for the mgrpBroadcasterPolicy attribute (or whatever attribute is named by the ldap_auth_policy MTA option).

In Unified Configuration, see the alias_auth_list, alias_cant_list, alias_username_auth_list, and alias_username_cant_list alias options.

AUTH_MAPPING, CANT_MAPPING

AUTH_MAPPING and CANT_MAPPING are similar to AUTH_LIST and CANT_LIST except that they use mappings rather than explicit files of addresses. The value item associated with these named parameters is the name of a mapping table to use; the mapping is given the envelope From address as input.

If AUTH_MAPPING is used at least one mapping entry must match or the posting is rejected. If an entry does match the resulting string is checked; if it begins with an F, f, N, or n the posting is rejected. The mailing list will expand normally if the resulting string begins with any other character.

If CANT_MAPPING is used, the posting is accepted if no entry matches. If an entry does match the resulting string is checked; if it begins with a T, t, Y, or y the posting is accepted. The posting is rejected if the resulting string begins with any other character.

The most common use of AUTH_MAPPING is to restrict postings to all users of a given (usually local) host. For example, if the local host name is ymir.claremont.edu, the following mailing list definition could be used for the gripes-list:


gripes: <pmdf_table:gripes-list.dis, [auth_mapping] x-gripes 

The corresponding mapping file entries would be:


X-GRIPES 
 
    *@ymir.claremont.edu    Y 

Using a mapping table name beginning X- is recommended, so that this private mapping table name will not collide with a standard Oracle mapping table name.

In Unified Configuration, see the alias_auth_mapping and alias_cant_mapping alias options.

AUTH_USERNAME, CANT_USERNAME

AUTH_USERNAME is used to specify a username or wildcarded username pattern for an account or accounts allowed to post to the list. Note that this is generally only useful for senders submitting from the L channel or for senders who used the SMTP AUTH extension during their message submission; for messages submitted from other sources, the messages are considered to be submitted under the username of the MTA process that received and enqueued the message, e.g., the account under which the MTA's SMTP server is running. Attempted postings from any other sender will be rejected.

CANT_USERNAME may be used to specify a username or wildcarded username pattern for an account or accounts whose postings should be rejected.

Note that for messages submitted via SMTP with authentication (SMTP AUTH), the username that authenticated will be prefixed with the asterisk, *, character. Also note that the asterisk character is normally a wildcard, and must be quoted with the dollar character in order to be interpreted as a literal asterisk character. For instance, to specify that the only sender who may post to a list is user JDOE who will be submitted solely via SMTP with SMTP AUTH, you would use:


[AUTH_USERNAME] $*JDOE 

Without the dollar sign, specifying just *JDOE would allow postings not only from user JDOE but also from any users AJDOE, BOBJDOE, etc.

For specifying more than one username (or wildcarded username pattern), see the USERNAME_AUTH_LIST and USERNAME_CANT_LIST parameters described above. For groups and lists defined in LDAP, the closest analogues are the mgrpAllowedBroadcaster and mgrpDisallowedBroadcaster attributes (or more precisely, the attributes named by the ldap_auth_url and ldap_cant_url MTA options).

In Unified Configuration, see the alias_auth_username and alias_cant_username alias options.

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 blocks for [BLOCKLIMIT], or an integer number of lines for [LINELIMIT]. The number of bytes in a block is specified via the block_size MTA option. The default value 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 channel or system wide limits). For user, groups, and lists defined in LDAP, see mailMsgMaxBlocks attribute (or more precisely, the attribute named by the ldap_blocklimit MTA option).

In Unified Configuration, see also the alias_blocklimit and alias_linelimit alias options.

CAPTURE, JOURNAL

(CAPTURE is new in MS 6.2; JOURNAL is new in Messaging Server 7.2-0.01.) The CAPTURE named parameter may be used to set an address to which to direct an encapsulated, "captured" copy of each message posted to the list. The JOURNAL named parameter works similarly, but generates an envelope "journal" format message. The value item should be the address to which to send the "captured" message copies. These parameters are exactly analogous to use of the LDAP attribute named by the ldap_capture MTA option on a group or mailing list defined via an LDAP entry.

In Unified Configuration, see also the alias_capture and alias_journal alias options.

New in MS 8.0.1, see also the CAPTURE_HEADER and JOURNAL_HEADER named parameters.

CAPTURE_HEADER, JOURNAL_HEADER

(CAPTURE_HEADER and JOURNAL_HEADER are new in MS 8.0.1.) The CAPTURE_HEADER named parameter may be used to set an address to which to direct an encapsulated, "captured" copy of the message header of each message posted to the list. The JOURNAL_HEADER named parameter works similarly, but generates an envelope "journal" format message. The value item should be the address to which to send the "captured" message copies. These parameters are exactly analogous to use of the LDAP attribute named by the ldap_capture MTA option on a group or mailing list defined via an LDAP entry, when the LDAP attribute's value is tagged ;format-report-header or ;format-journal-header.

In Unified Configuration, see also the alias_capture_header and alias_journal_header alias options.

CONVERSION_TAG

The CONVERSION_TAG named parameter may be used to set a tag which conversion file entries can match upon. The value item should be the string to use as the tag. For instance, if a list is defined


listname: </pmdf/table/listname.dis, [CONVERSION_TAG] listtag 

then conversion file entries could include a tag=listtag; clause to match. For instance, if for some mailing list it was desired to convert any text/html parts in posted messages to text/plain, and if a site had an HTML to TEXT converter called htmltotextconvert and had set up the conversion channel and a CONVERSIONS mapping table to apply to list postings, then a conversion file entry could be


in-chan=*; out-chan=*; in-type=text; in-subtype=html; tag=listtag; 
 out-type=text; out-subtype=plain; parameter-copy-0=*; 
 command="IMTA_PROGRAM:htmltotextconvert $INPUT_FILE $OUTPUT_FILE" 

For users, groups, and lists defined in LDAP, see the mailConversionTag attribute (or more precisely, the attribute named by the ldap_conversion_tag MTA option).

In Unified Configuration, see also the alias_conversion_tag alias option.

CREATION_DATE

New in the 8.0 release.

The CREATION_DATE named parameter may be used to set a creation date for the alias (intended to be used for RRVS purposes). The creation date value must be in RFC 3339 (Date and Time on the Internet: Timestamps) format (a profile of ISO 8601 format), along the lines of:

YYYY-MM-DDTHH:MM:SS.ssZ

or

YYYY-MM-DDTHH:MM:SS.ss'plus-or-minus'HH:MM

where the hundredths of seconds portion is optional, and T and (if used) Z are not case sensitive. For instance:

2014-02-28T12:13:14.30-07:00

In Unified Configuration, see the alias_creation_date alias option. Or for users defined in LDAP, the analogous setting is controlled by whatever attribute is named by the ldap_creation_date MTA option, or at a domain level by whatever attribute is named by the ldap_domain_attr_creation_date MTA option.

DEFERRED, DEFERRED_LIST, DEFERRED_MAPPING

In Unified Configuration, see the alias_deferred, alias_deferred_list, and alias_deferred_mapping alias options.

The DEFERRED named parameter may be used to add a Deferred-delivery: header line. The value should be a date and time, in ISO 8601 P format. Note that by default the MTA does not honor Deferred-delivery: headers; see the deferred channel option for a discussion.

The DEFERRED_LIST named parameter takes two (space-separated) values, a file specification for a list of originator addresses (or alternatively, a URL returning a list of addresses) to whose postings to add a Deferred-delivery: header, and the deferral date/time in ISO 8601 format.

As of the 8.0 release (in prior versions, this feature "existed" but was not working), the DEFERRED_MAPPING named parameter may be used to run originator addresses through the specified mapping. DEFERRED_MAPPING takes one or two arguments, with a space between if the optional second argument is included. The first argument is required and must contain at a minimum the name of an MTA mapping table; the first argument may also, optionally, include a vertical bar character followed by a string to use as a prefix in the mapping table probe, prior to the originator address. The second argument is optional, consisting of a deferral date/time in ISO 8601 format.

mapping-name[|probe-prefix] ISO-8601-deferral-time

Originator addresses will be run through the specified mapping. If the mapping template does not begin with an N, n, F, or f, and if it contains a valid date/time specification in ISO 8601 format, then that date/time will be used as a deferral time. The default, if no mapping entry matches, or if an entry that begins with an N, n, F, or f, is not to add a Deferred-delivery: header. Note that the intended purpose of a probe-prefix is for convenience in using a single MTA mapping table for multiple mailing list deferral settings, e.g., by using a probe prefix consisting of the list name, so that entries in the mapping table may be list specific. Similarly, a deferral time specified as the second argument permits a default deferral time, that may then be overridden in the case of specific originators in the mapping table result.

Setting bit 3/value 8 of the include_connectioninfo MTA option will cause additional information to be included in the DEFERRED_MAPPING input probe. Thus if a probe-prefix has also been specified, then the probe will take the form:

transport-info|application-info|probe-prefix|originator-address

Note that by default the MTA does not honor Deferred-delivery: headers; see the deferreddestination channel option for a discussion. As a functionally preferable alternative to the Deferred-delivery: header line approach for retaining/deferring messages, see also the SMTP SUBMIT FUTURERELEASE extension.

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.

In Unified Configuration, see the alias_delay_notifications alias option. Or for users defined in LDAP, the analogous settings are controlled by whatever attribute is named by the ldap_delay_notifications MTA option, by default mgrpDelayNotifications.

DIGEST_RECURRENCE

RESTRICTED: Not yet fully implemented.

The DIGEST_RECURRENCE parameter takes an ISO 8601 argument.

DIRECT_LIST, DIRECT_MAPPING

RESTRICTED: Not yet fully implemented.

ENVELOPE_FROM

This ENVELOPE_FROM parameter takes a required value specifying an address to replace the message's original envelope From address. This sets only the envelope From address, unlike the error-return-address positional parameter which also sets an Errors-to: address.

Setting the value to an address of the form user+*@domain has a special meaning. The asterisk character will be expanded into a representation of the recipient address; thus a separate copy of the list message is generated for each recipient, with each copy including the intended recipient address as a subaddress within the return address. If delivery errors subsequently occur, the subaddress will indicate which was the failing address. In some cases, when dealing with remote MTAs that generate nonstandard, uninformative delivery error messages, this can in theory be useful as a way of determining which recipient address(es) failed, even when the bounce message's inner content is relatively uninformative. And it may make processing of such bounce messages by an automated program more convenient. However, the tradeoff is that such per-user-specific return address values require that a separate message copy be generated and sent for each recipient; for a "large" list, with many recipients in the same destination domains, this can be a large increase in overhead (a large decrease in efficiency). And with more prevalent use nowadays of standard format notification messages, the "need" for this sort of approach, with its extra (potentially large) overhead, is much less (since the intended recipient information can instead be extracted from the standard field in the contents of a standard format notification message).

(New in MS 6.3.) Setting the value to the forward slash character, /, has a special meaning. It tells the MTA to revert to using the original envelope From address that had been present on the incoming message, yet in all other respects use mailing list semantics. This can be useful for setting up mailing lists that report all forms of list errors to the original sender.

In Unified Configuration, see the alias_envelope_from alias option. Or for groups and lists defined in LDAP, see the mgrpErrorsTo attribute (or more precisely, the attribute named by the ldap_errors_to MTA option).

ERROR_TEXT (string)

Specify a string to use as the "reason" which will be returned to the attempted sender if and when an attempted posting fails. For groups defined in LDAP, see the mgrpRejectText attribute or mgrpMsgRejectText attribute (or more precisely, whatever attribute(s) are named by the ldap_reject_text MTA option).

In Unified Configuration, see also the alias_error_text alias option.

EXPANDABLE, NONEXPANDABLE

The EXPANDABLE named parameter is used to specify that the associated list can be expanded (and hence its contents seen) by various protocols which may attempt such an operation. It does not mean, or imply, that the contents of the list will be expanded into message headers. The value specification is currently ignored and should always be NONE. The NONEXPANDABLE named parameter specifies that the associated list may not be expanded. Again, the value specified is currently ignored and should always be NONE. EXPANDABLE is the default, unless the expandable_default MTA option has been set, in which case the default is NONEXPANDABLE.

NONEXPANDABLE is useful in blocking the expansion of mailing lists via SMTP's EXPN command. Note that mailing list access controls, e.g., AUTH_LIST, AUTH_MAPPING, etc., also affect the expansion of mailing lists via SMTP's EXPN command; the SMTP server will only permit the EXPN if the SMTP client passes the access control (e.g., has issued a prior MAIL FROM: command that passes the access control).

In Unified Configuration, see also the alias_expandable and alias_nonexpandable alias options.

EXPIRY

The EXPIRY named parameter is used to add an Expiry-date: header line. The value should be a date and time, in ISO 8601 P format (as described for the DEFERRED parameter above). (The MTA will convert the specified value into the appropriate corresponding RFC 2822 date value needed for the header line.) The MTA's periodic return job will return messages whose Expiry-date: has passed.

For groups or lists defined in LDAP, see the ldap_add_header MTA option. In Unified Configuration, see also the alias_expiry alias option.

FILTER

The FILTER parameter takes a URL argument specifying the location of a Sieve filter to apply on attempted message postings. The argument may be any supported form of URL that makes sense; in particular, besides supporting file:file-spec URLs or simply file specifications without the leading file:, LDAP URLs, and data:sieve-commands are also supported. Note that when specifying a file, it must be the full file specification for the filter file to apply.

In Unified Configuration, see the alias_filter alias option. Or for users defined in LDAP, the analogous setting is controlled by whatever attribute is named by the ldap_filter MTA option, by default mailSieveRuleSource.

HEADER_ADDITION, HEADER_TRIM

HEADER_TRIM may be used to add headers to or remove headers from posted messages. The argument must be a full file specification for a header trimming option file; see Header option files for information on the format of these files. HEADER_ADDITION is more specialized than HEADER_TRIM, being used when there are merely headers to be added. 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 site domain.com that has set up a list named listname, using the MAILSERV channel to manage subscription and unsubscription requests, and with certain list information and archives available at an FTP site, might use a header addition file along the lines of the following:


List-Help: <ftp://ftp.domain.com/pub/listname-help.txt&#x3e; (FTP), 
     <mailto:mailserv@domain.com?body=send%20/pub/listname-help.txt&#x3e;, 
     <mailto:mailserv@domain.com?body=help&#x3e; (MAILSERV Instructions), 
     <mailto:listname-owner@domain.com?subject=help&#x3e; (List Manager) 
List-Subscribe: 
     <mailto:mailserv@domain.com?body=subscribe%20listname&#x3e; 
List-Unsubscribe: 
     <mailto:mailserv@domain.com?body=unsubscribe%20listname&#x3e; 
List-Post: <mailto:listname@domain.com&#x3e; 
List-Owner: <mailto:listname-owner@domain.com?Subject=listname&#x3e; 
List-Archive: <ftp://ftp.domain.com/pub/listname/archive/&#x3e;, 
    <mailto:mailserv@domain.com?body=send%20/pub/listname/archive/*&#x3e; 

In Unified Configuration, see the alias_header_addition and alias_header_trim MTA options. Or for mailing lists defined in LDAP, see the LDAP attributes mgrpAddHeader and mgrpRemoveHeader, or more precisely, the LDAP attributes named by the ldap_add_header and ldap_remove_header MTA options.

HEADER_ALIAS, HEADER_EXPANSION

The HEADER_ALIAS named parameter forces the use of the original alias in any original headers constructed using this alias. HEADER_EXPANSION forces the alias to expand into its component addresses in any constructed header lines. The value specification is currently ignored and should always be NONE. These named parameters correspond to the expand and no-expand options for entries in personal alias databases. HEADER_ALIAS is the default for entries in the system alias file and database. Note that these parameters are only valid when headers are originally being constructed, as for instance for messages submitted via the L channel. These parameters are not relevant for incoming messages (such as incoming SMTP messages) for which the headers are already present in one form or another.

In Unified Configuration, see the alias_header_alias and alias_header_expansion alias options.

HEADER_CHECK

(New in 7.0.5) Used in conjunction with a addrtypescan* channel keyword. Valid arguments are jettison or discard. In Unified Configuration, see the alias_header_check alias option. This named parameter is also analogous to the LDAP attribute named by the ldap_check_header MTA option.

HOLD_LIST, NOHOLD_LIST, HOLD_MAPPING, NOHOLD_MAPPING

The HOLD_LIST named parameter may be used to specify a list of originator addresses whose attempts to post to the list should be sidelined as .HELD messages. The NOHOLD_LIST named parameter may be used to specify the list of originator addresses whose postings should not be so sidelined, while all other postings will be sidelined. The value must be a full file specification for a file of addresses, or an LDAP URL returning a list of addresses. The HOLD_MAPPING and NOHOLD_MAPPING named parameters are used analogously, but via mapping tables rather than via lists. The value should be the name of an MTA mapping table.

In Unified Configuration, see the alias_hold_list and alias_nohold_list alias options.

IMPORTANCE, PRECEDENCE, PRIORITY, SENSITIVITY

The IMPORTANCE, PRECEDENCE, PRIORITY, and SENSITIVITY named parameters are used to generate respective headers; the value specification is inserted on the respective header line. In Unified Configuration, see the alias_importance, alias_precedence, alias_priority, and alias_sensitivity alias options.

Note that the more general HEADER_ADDITION -- in Unified Configuration, the alias_header_addition alias option -- provides an alternate way to add these and other header lines. Or for aliases defined in LDAP, see the ldap_add_header MTA option.

KEEP_DELIVERY, KEEP_READ

By default, the MTA strips delivery receipt and read receipt requests from messages posted to mailing lists. The KEEP_DELIVERY and KEEP_READ named parameters may be used to override this behavior, causing the MTA to retain any delivery receipt or read receipt requests, respectively, on messages posted to the list. The value specification is currently ignored and should always be NONE. Note that passing receipt requests through to mailing lists is quite dangerous; the default behavior of stripping such requests is strongly recommended.

In Unified Configuration, see the alias_keep_delivery and alias_keep_read alias options.

LIST_NAME

New in Messaging Server 7.4-0.01; RESTRICTED.

MODERATOR_ADDRESS, MODERATOR_LIST, MODERATOR_MAPPING, USERNAME_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,


test-list: <IMTA_TABLE:test.dis, \
           [MODERATOR_ADDRESS] bob@domain.com 

When there may be multiple moderator addresses (for instance, both robert@mail1.domain.com and bob@domain.com), use MODERATOR_LIST, USERNAME_MODERATOR_LIST, or MODERATOR_MAPPING 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 either the name of a file containing a list of moderator addresses, or an LDAP URL returning a list of moderator addresses. USERNAME_MODERATOR_LIST specifies either the name of a file containing a list of (possibly wildcarded) moderator usernames, or an LDAP URL returning a list of (possibly wildcarded) moderator usernames; note that usernames are generally only useful for messages submitted from the L channel or submitted with SASL authentication via SMTP (SMTP AUTH) since for messages submitted from other sources the username will simply be that of the account under which the submitting MTA process is running. Note that for messages submitted via SMTP with authentication (SMTP AUTH), the username that authenticated will be prefixed with the asterisk, *, character. For instance, to specify that only the user JDOE is the list moderator, whether submitting from the L channel or via SMTP (e.g., from a POP or IMAP client that performs SASL SMTP authentication), the USERNAME_MODERATOR_LIST file would need to contain the entries:


JDOE 
$*JDOE 

where the first entry would match for messages submitted from the L channel and the second entry would match for messages submitted via SMTP AUTH. Note that as asterisk is normally a wildcard character, matching of only the exact literal asterisk character is specified by using the dollar character to quote the asterisk.

MODERATOR_MAPPING specifies the name of a mapping table used to verify whether or not an address is a moderator address.

If a MODERATOR_LIST or MODERATOR_MAPPING parameter is used, thereby specifying who may 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.

Unified Configuration has analogous alias options alias_moderator_address, alias_moderator_list, alias_moderator_mapping, and alias_username_moderator_list. Or for lists defined in LDAP, see the mgrpMsgRejectAction and mgrpModerator attributes, or more precisely whatever LDAP attributes are named by the ldap_reject_action and ldap_moderator_url MTA options.

NOSOLICIT (comma-separated list of strings)

New in MS 6.2. Set a solicitation keyword, or a list of solicitation keywords, that will not be allowed on postings to the list. Attempted postings that have such a keyword set will be rejected with "Solicitation check failure on SOLICIT=keyword" error text.

In Unified Configuration, see the alias_nosolicit alias option. Or for lists defined in LDAP, see the ldap_nosolicit MTA option.

OPTIN, OPTIN1, OPTIN2, OPTIN3, OPTIN4, OPTIN5, OPTIN6, OPTIN7, OPTIN8

Set optin values for spam filtering.

In Unified Configuration, see the alias_optin* alias options.

For aliases/lists defined in LDAP, see the ldap_optinN and ldap_optoutN MTA options.

ORIGINATOR_REPLY, NOORIGINATOR_REPLY

ORIGINATOR_REPLY is used to control whether or not the originator's address is added to any generated Reply-to: header. The value item should be the full file path specification for a world readable file, or a resolvable URL, containing the list of addresses that should never be added. (This is usually the mailing list itself.) The MTA will match the envelope From address against the addresses in the list; if no match occurs, the originator's address will be added to any generated Reply-to: header.

NOORIGINATOR_REPLY specifies that any generated Reply-to: header should contain only explicitly specified addresses. The value item is ignored. NOORIGINATOR_REPLY is the default.

In Unified Configuration, see the alias_originator_reply and alias_nooriginator_reply alias options.

PASSWORD

Specify a password, or a comma-separated list of passwords, that allow posting to the list. An attempted posting to the list must contain one of these values on an Approved: header line in order for the posting to be allowed. During mailing list expansion, the password value will be removed from the Approved: header line; indeed, if that is the only value on the Approved: header line, then the entire header line will be removed. See Password-protected mailing lists.

In Unified Configuration, see the alias_password alias option.

For aliases/lists defined in LDAP, see the ldap_auth_password MTA option.

PREFIX_TEXT, SUFFIX_TEXT

(New in MS 6.0.) Insert prefix or suffix text into messages as they undergo list expansion. Prior to Messaging Server 7.0 update 3, text could only be inserted into initial, TEXT/PLAIN parts; new in Messaging Server 7.0 update 3, text can be inserted into the first text part within a nested multipart (excluding multipart/alternative). The attribute values are given in UTF-8; this is then converted to match the charset of the part into which the text is being inserted.

In Unified Configuration, see the alias_prefix_text and alias_suffix_text alias options. Or for lists defined in LDAP, see the mgrpMsgPrefixText and mgrpMsgSuffixText attributes, or more precisely whatever attributes are named by the ldap_prefix_text and ldap_suffix_text MTA options. More generally, for adding prefix or suffix text to any message, not just postings to groups or lists, see the Sieve addprefix and addsuffix extensions.

PUBLIC, PRIVATE

The PUBLIC named parameter specifies that the associated alias is public and hence can appear in any constructed header lines. The value specification is currently ignored and should always be NONE. The PRIVATE named parameter specifies that the alias is private and should appear as an empty group construct in message headers. The value specification is used as the name for the group. Neither PUBLIC nor PRIVATE have any effect if the HEADER_EXPANSION named parameter is also specified. These named parameters correspond to the public and private options for entries in personal alias databases. PUBLIC is the default for entries in the system alias file and database.

Note that these parameters are only valid when headers are originally being constructed, as for instance for messages submitted via the L channel. These parameters are not relevant for incoming messages (such as incoming SMTP messages) for which the headers are already present in one form or another.

In Unified Configuration, see the alias_private and alias_public alias options.

RECEIVEDFOR, NORECEIVEDFOR, RECEIVEDFROM, NORECEIVEDFROM

These named parameters control features of what appears in the Received: header constructed when expanding the alias, and override normal channel receivedfor, noreceivedfor, receivedfrom, or noreceivedfrom channel option settings. The value specification is currently ignored and should always be NONE.

In Unified Configuration, see the alias_receivedfor, alias_noreceivedfor, alias_receivedfrom, and alias_noreceivedfrom alias options.

REPROCESS

The REPROCESS named parameter is used to request deferred expansion of the mailing list, where rather than expanding the mailing list "on line", the message should instead be enqueued to the reprocess channel; the reprocess channel can then perform the mailing list processing in a separate step. The value specification is currently ignored and should always be reprocess.

Use of this parameter defers much of the processing overhead of handling the message to the later step when the reprocess channel runs, rather than doing the processing as the message is initially accepted. This deferred processing can be especially helpful in cases such as incoming SMTP messages addressed to large mailing lists, where "on line" delays could lead to connection time outs.

Use of this parameter as in:


listname: </pmdf/table/listname.dis, [REPROCESS] reprocess  

thus provides essentially identical functionality as defining a mailing list in two stages through the reprocess channel to obtain deferred expansion (the mailing list addresses aren't even expanded until the reprocess channel runs) such as:


listname:        listname-expand@reprocess 
listname-expand: </pmdf/table/listname.dis 

In Unified Configuration, the analogous alias option is alias_reprocess. Or for aliases defined in LDAP, see the mailDeferProcessing attribute, or more precisely whatever LDAP attribute is named by the ldap_reprocess MTA option.

SASL_AUTH_LIST, SASL_AUTH_MAPPING, SASL_CANT_LIST, SASL_CANT_MAPPING, SASL_MODERATOR_LIST, SASL_MODERATOR_MAPPING

These named parameters are analogues of the non-SASL named parameters, but with the additional requirement that an authenticated address be present in the message (whether that be a address literally authenticated via SMTP AUTH, or forced via, e.g., an authrewrite or FROM_ACCESS effect).

In Unified Configuration, see the alias_sasl_* alias options.

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 Unified Configuration the analogous alias options are alias_sequence_prefix, alias_sequence_suffix, and alias_sequence_strip.

SINGLE

Force a separate message copy per recipient (per list member). Thus it can be considered a per-list analogue of the single channel option.

In Unified Configuration, its analogue is the alias_single alias option.

SPARE1,...,SPARE18

(New in Messaging Server 7.0 update 2) Analogous to the attributes named by the ldap_spare_N MTA options. In Unified Configuration, the analogous alias options are alias_spare*.

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. The string should not contain the vertical bar, |, character; prior to MS 6.3, the string should not have contained the space character. For instance,


schedule-list: <d1:[adam]schedule-list.dis, [TAG] Schedule posting -- , \
               [AUTH_LIST] d1:[adam]schedule-list.dis 

will cause any postings to the list schedule-list to have a Subject: header that begins "Schedule posting -- " followed by whatever the original subject of the posting might have been. See the ldap_add_tag MTA option for setting an attribute name to provide analogous functionality for lists defined in LDAP, and in Unified Configuration, see also the alias_tag alias option.

TO

The TO named parameter specifies what to put on the To: header line of postings to the mailing list.

In Unified Configuration, see the alias_to alias option.

USERNAME

The USERNAME named parameter may be used to set the "username" that the MTA will consider to "own" these mailing list messages. The imsimta 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.

In Unified Configuration, see the alias_username alias option.


See also: