Alias file named parameters

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  appearing in an alias file mailing list  definition such as  alias: &#x3c;file-spec, named-parameters, error-return-address, \ reply-to-address, errors-to-address, \ warnings-to-address, comments or alias: &#x3c;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.,  ,   , etc.). The general syntax of a named parameter is: &#x5b;name&#x5d; value Here   is the name of the parameter and   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., &#x5b;AUTH_LIST&#x5d;, &#x5b;AUTH_MAPPING&#x5d;, etc.) are ANDed or ORed. The default is controlled by the   MTA option---and is AND  (for backwards compatibility) by default. For groups and lists defined in LDAP, see also the   and   values for  the   attribute (or more precisely,  the attribute named by the    MTA option). For a more detailed discussion, see   Mailing list multiple access control interpretation.

In Unified Configuration, see the  and   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  and   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   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&#x27;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 $&#x2a;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  , the alias file entry would be: test-list: &#x3c;IMTA_TABLE:test-list.dis, \ &#x5b;auth_list&#x5d; IMTA_TABLE:test-list.dis For groups and lists defined in LDAP, the closest analogues are the   and    attributes (more precisely, the  attributes named by the    and    MTA options); and if  wishing to compare  against authenticated submission addresses, see also the    value for the    attribute (or whatever attribute is  named by the    MTA option).

In Unified Configuration, see the,  ,  , and   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  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: &#x3c;pmdf_table:gripes-list.dis, &#x5b;auth_mapping&#x5d; x-gripes The corresponding mapping file entries would be: X-GRIPES &#x2a;@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   and   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&#x27;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: &#x5b;AUTH_USERNAME&#x5d; $&#x2a;JDOE Without the dollar sign, specifying just  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   and    attributes (or more precisely,  the attributes named by the    and    MTA  options).

In Unified Configuration, see the  and   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   item must be an integer number of blocks  for &#x5b;BLOCKLIMIT&#x5d;, or an integer number of lines for &#x5b;LINELIMIT&#x5d;. The number of bytes in a block is specified via the    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   attribute (or  more precisely, the attribute named by the    MTA option).

In Unified Configuration, see also the  and   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   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   MTA option  on a group or mailing list defined via an  LDAP entry.

In Unified Configuration, see also the  and   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   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   MTA option  on a group or mailing list defined via an  LDAP entry, when the LDAP attribute&#x27;s value is tagged   or.

In Unified Configuration, see also the  and   alias options.

CONVERSION_TAG
The CONVERSION_TAG named parameter may be used to set a tag which  conversion file entries can match upon. The   item should be the string to use as the tag. For instance, if a list is defined listname: &#x3c;/pmdf/table/listname.dis, &#x5b;CONVERSION_TAG&#x5d; listtag then conversion file entries could include a  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   and had set up the  conversion channel and a    mapping table to apply to list postings, then a conversion file entry could be  in-chan=&#x2a;; out-chan=&#x2a;; in-type=text; in-subtype=html; tag=listtag; out-type=text; out-subtype=plain; parameter-copy-0=&#x2a;; command="IMTA_PROGRAM:htmltotextconvert $INPUT_FILE $OUTPUT_FILE" For users, groups, and lists defined in LDAP, see the   attribute (or more precisely, the  attribute named by the     MTA option).

In Unified Configuration, see also the  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  and (if used)   are not case sensitive. For instance:

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

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

DEFERRED, DEFERRED_LIST, DEFERRED_MAPPING
In Unified Configuration, see the,  , and   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   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&#x5b;&#x7c;probe-prefix&#x5d; 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  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   MTA option  will cause additional information to be included in the DEFERRED_MAPPING input probe. Thus if a   has also been specified, then the probe will take the form: transport-info&#x7c;application-info&#x7c;probe-prefix&#x7c;originator-address Note that by default the MTA does not honor Deferred-delivery: headers; see the   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   specification is currently ignored and  should always be.

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

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&#x27;s original envelope From address. This sets only the envelope From address, unlike the    positional parameter which  also sets an Errors-to: address.

Setting the value to an address of the form   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&#x27;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 option. Or for groups and lists defined in LDAP, see the   attribute (or more precisely, the attribute named by the    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   attribute or   attribute (or more  precisely, whatever attribute(s) are named by the    MTA option).

In Unified Configuration, see also the  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   specification is currently ignored and  should always be. The NONEXPANDABLE named parameter specifies that the associated list may not be expanded. Again, the   specified is currently ignored and should always be. EXPANDABLE is the default, unless the   MTA option   has been set, in  which case the default is NONEXPANDABLE.

NONEXPANDABLE is useful in blocking the expansion of mailing lists via SMTP&#x27;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&#x27;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  and   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&#x27;s periodic return job will  return messages whose Expiry-date: has passed.

For groups or lists defined in LDAP,  see the   MTA option. In Unified Configuration, see also the  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   URLs or simply file  specifications without the leading , LDAP URLs, and    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 option. Or for users defined in LDAP, the analogous setting is controlled by whatever attribute is named by the  MTA option, by default.

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: &#x3c;ftp://ftp.domain.com/pub/listname-help.txt&#x3e; (FTP), &#x3c;mailto:mailserv@domain.com?body=send%20/pub/listname-help.txt&#x3e;, &#x3c;mailto:mailserv@domain.com?body=help&#x3e; (MAILSERV Instructions), &#x3c;mailto:listname-owner@domain.com?subject=help&#x3e; (List Manager) List-Subscribe: &#x3c;mailto:mailserv@domain.com?body=subscribe%20listname&#x3e; List-Unsubscribe: &#x3c;mailto:mailserv@domain.com?body=unsubscribe%20listname&#x3e; List-Post: &#x3c;mailto:listname@domain.com&#x3e; List-Owner: &#x3c;mailto:listname-owner@domain.com?Subject=listname&#x3e; List-Archive: &#x3c;ftp://ftp.domain.com/pub/listname/archive/&#x3e;, &#x3c;mailto:mailserv@domain.com?body=send%20/pub/listname/archive/&#x2a;&#x3e; In Unified Configuration, see the  and   MTA options. Or for mailing lists defined in LDAP, see the LDAP attributes  and , or more precisely, the LDAP attributes named by the   and   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  specification  is currently ignored and should always be. 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  and   alias options.

HEADER_CHECK
(New in 7.0.5) Used in conjunction with a   channel keyword. Valid arguments are  or. In Unified Configuration, see the  alias option. This named parameter is also analogous to the LDAP attribute named by the    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   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  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   should be the name of an MTA mapping table.

In Unified Configuration, see the  and   alias options.

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

Note that the more general HEADER_ADDITION -- in Unified Configuration, the  alias option -- provides an alternate way to add these and other header lines. Or for aliases defined in LDAP, see the  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   specification is currently ignored and should always be. 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  and   alias options.

LIST_NAME
New in Messaging Server 7.4-0.01; RESTRICTED.

MODERATOR_ADDRESS, MODERATOR_LIST, MODERATOR_MAPPING, USERNAME_MODERATOR_LIST
The MODERATOR_&#x2a; 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&#x27;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&#x27;s address. For example, test-list: &#x3c;IMTA_TABLE:test.dis, \ &#x5b;MODERATOR_ADDRESS&#x5d; 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&#x27;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 $&#x2a;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 ,  ,  , and. Or for lists defined in LDAP, see the  and   attributes, or more precisely whatever LDAP attributes are named by the   and   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 option. Or for lists defined in LDAP, see the  MTA option.

OPTIN, OPTIN1, OPTIN2, OPTIN3, OPTIN4, OPTIN5, OPTIN6, OPTIN7, OPTIN8
Set optin values for spam filtering.

In Unified Configuration, see the  alias options.

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

ORIGINATOR_REPLY, NOORIGINATOR_REPLY
ORIGINATOR_REPLY is used to control whether or not the originator&#x27;s address is added to any generated Reply-to: header. The   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&#x27;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   item is ignored. NOORIGINATOR_REPLY is the default.

In Unified Configuration, see the  and   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 option.

For aliases/lists defined in LDAP, see the  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  and   alias options. Or for lists defined in LDAP, see the  and    attributes, or more precisely whatever attributes are named by the   and   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   specification is currently ignored and  should always be. The PRIVATE named parameter specifies that the alias is private and should appear as an empty group  construct in message headers. The   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   and   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  ,  ,   , or   channel option settings. The  specification is currently ignored and  should always be.

In Unified Configuration, see the,  ,  , and   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   specification is currently ignored and should always be.

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: &#x3c;/pmdf/table/listname.dis, &#x5b;REPROCESS&#x5d; 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&#x27;t even expanded until the  reprocess channel runs) such as: listname:       listname-expand@reprocess listname-expand: &#x3c;/pmdf/table/listname.dis In Unified Configuration, the analogous alias option is. Or for aliases defined in LDAP, see the  attribute, or more precisely whatever LDAP attribute is named by the   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   or   effect).

In Unified Configuration, see the  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  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&#x27;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  item  is currently ignored and should always be.

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_&#x2a; 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,  , and.

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

In Unified Configuration, its analogue is the  alias option.

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

TAG
The TAG named parameter may be used to prefix specified text to the Subject: header of posted messages. The   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: &#x3c;d1:&#x5b;adam&#x5d;schedule-list.dis, &#x5b;TAG&#x5d; Schedule posting --, \ &#x5b;AUTH_LIST&#x5d; d1:&#x5b;adam&#x5d;schedule-list.dis will cause any postings to the list schedule-list to have a Subject: header that begins " " followed by whatever the  original subject of the posting might have been. See the   MTA option  for setting an attribute name to provide  analogous functionality for lists defined in LDAP, and in Unified Configuration, see also the    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 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   utility will allow that username to inspect and bounce messages in the  queue resulting from expansion of this mailing list. The   item should be the username of the account to  "own" the mailing list postings.

In Unified Configuration, see the  alias option.

See also:
 * Alias options
 * Alias file
 * Alias file format
 * Mailing list multiple access control interpretation
 * Alias header addition modifiers
 * MTA URL types
 * or_clauses MTA Option
 * ldap_auth_policy MTA Option
 * alias_and Option
 * alias_or Option
 * alias_auth_channel Option
 * alias_cant_channel Option
 * ldap_auth_url MTA Option
 * ldap_cant_url MTA Option
 * alias_auth_list Option
 * alias_cant_list Option
 * alias_username_auth_list Option
 * alias_username_cant_list Option
 * alias_auth_mapping Option
 * alias_cant_mapping Option
 * alias_auth_username Option
 * alias_cant_username Option
 * block_size MTA Option
 * ldap_blocklimit MTA Option
 * alias_blocklimit Option
 * alias_linelimit Option
 * ldap_capture MTA Option
 * alias_capture Option
 * alias_journal Option
 * CONVERSIONS mapping table
 * ldap_conversion_tag MTA Option
 * alias_conversion_tag Option
 * ISO 8601 format
 * alias_creation_date Option
 * ldap_creation_date MTA Option
 * ldap_domain_attr_creation_date MTA Option
 * deferred Option
 * alias_deferred Option
 * alias_deferred_list Option
 * alias_deferred_mapping Option
 * include_connectioninfo MTA Option
 * deferreddestination Option
 * ldap_delay_notifications MTA Option
 * alias_delay_notifications Option
 * ldap_errors_to MTA Option
 * alias_envelope_from Option
 * ldap_reject_text MTA Option
 * alias_error_text Option
 * expandable_default MTA Option
 * alias_expandable Option
 * alias_nonexpandable Option
 * ldap_add_header MTA Option
 * alias_expiry Option
 * ldap_filter MTA Option
 * alias_filter Option
 * Header option files
 * ldap_add_header MTA Option
 * ldap_remove_header MTA Option
 * alias_header_addition Option
 * alias_header_trim Option
 * alias_header_alias Option
 * alias_header_expansion Option
 * addrtypescan Option
 * ldap_check_header MTA Option
 * alias_header_check Option
 * alias_hold_list Option
 * alias_nohold_list Option
 * alias_importance Option
 * alias_precedence Option
 * alias_priority Option
 * alias_sensitivity Option
 * alias_keep_delivery Option
 * alias_keep_read Option
 * Moderated mailing lists
 * alias_moderator_address Option
 * alias_moderator_list Option
 * alias_moderator_mapping Option
 * alias_username_moderator_list Option
 * ldap_reject_action MTA Option
 * ldap_moderator_url MTA Option
 * alias_nosolicit Option
 * ldap_nosolicit MTA Option
 * alias_optin1 Option
 * alias_optout1 Option
 * ldap_optin1 MTA Option
 * ldap_optout1 MTA Option
 * alias_nooriginator_reply Option
 * Password-protected mailing lists
 * alias_password Option
 * ldap_auth_password MTA Option
 * ldap_prefix_text MTA Option
 * ldap_suffix_text MTA Option
 * alias_prefix_text Option
 * alias_suffix_text Option
 * Sieve addprefix and addsuffix extensions
 * prefix_text_attr MTA Option
 * suffix_text_attr MTA Option
 * alias_private Option
 * alias_public Option
 * receivedfor Option
 * noreceivedfor Option
 * receivedfrom Option
 * noreceivedfrom Option
 * alias_receivedfor Option
 * alias_noreceivedfor Option
 * alias_receivedfrom Option
 * alias_noreceivedfrom Option
 * ldap_reprocess MTA Option
 * alias_reprocess Option
 * authrewrite Option
 * FROM_ACCESS mapping table
 * alias_sasl_auth_list Option
 * alias_sasl_auth_mapping Option
 * alias_sasl_cant_list Option
 * alias_sasl_cant_mapping Option
 * alias_sasl_moderator_list Option
 * alias_sasl_moderator_mapping Option
 * alias_sequence_prefix Option
 * alias_sequence_suffix Option
 * alias_sequence_strip Option
 * single Option
 * alias_single Option
 * alias_spare1 Option
 * ldap_spare_1 MTA Option
 * ldap_add_tag MTA Option
 * alias_tag Option
 * alias_to Option
 * alias_username Option
 * use_auth_return MTA Option
 * use_canonical_return MTA Option
 * use_orig_return MTA Option
 * ldap_use_async MTA Option
 * qm utility
 * ISO 8601 P format
 * ISO 8601 format