Setting Subscription Options for Subscribers Using Email

The syntax is similar to the subscriber's method of reviewing his options, except that the list owner must specify for whom the options are being checked.

It is possible to use wildcards in the subscriber address. For instance,

will return option listings for subscribers such as JIMJ@UBVM, JOHN@UBVMS.CC.BUFFALO.EDU, etc. This can be handy if you are searching the list for someone whose subscription address differs from the address you are given in an error report (see the examples, above, in "Dealing with bounced mail").

Using the WITH qualifier, you can also query a list for users who have a specific option set. For instance, you might want to know which users are set to NOMAIL. Send the command

and LISTSERV will return a list of those users. It is also possible to query a list for multiple options:

will return a list of those subscribers who have set their subscription to DIGEST and also to CONCEAL.

You can also query users by the list topics they are subscribed to. For instance:

shows all members subscribed to both the ADMIN and FORUM topics.

shows all members who are not subscribed to the ADMIN topic.

shows all members who are subscribed to the ADMIN topic but not to the TEST topic.

Again, the syntax is similar to the subscriber's method.

Setting this option to Mail indicates that the subscriber will receive mail from the list. NOMail is the complementary command that stops mail but leaves the user subscribed to the list. (NOMail is often a good compromise for users who are leaving the office for vacation or on extended business trips, and who don't want a full mailbox on their return.) The format of the messages received is controlled by the DIGEST/INDEX/NODIGEST/NOINDEX options (see the following sections).

Causes the subscriber to receive one posting per digest cycle (typically daily) rather than individual messages as they are processed by LISTSERV.

The MAIL/NOMAIL option is isolated from DIGEST/INDEX. The MAIL/NOMAIL option controls whether messages should be delivered, and the DIGEST/INDEX/NODIGEST/NOINDEX option controls the format in which messages should be delivered. Thus, switching to NOMAIL and back to MAIL now preserves the digest/index/normal delivery setting. To provide as much compatibility with the old syntax as possible, the four options operate as follows:

•	MAIL – Restore mail delivery. Note that If mail delivery was already enabled, the MAIL option negates INDEX/DIGEST. Thus, a user going from NOMAIL to MAIL will keep his previous delivery options, whereas a user going from DIGEST or INDEX to MAIL will in fact deactivate index/digest mode.

To revert from digest/index subscription mode to normal delivery, you can use either the MAIL option as before, or the NODIGEST/NOINDEX option.

The command SET listname MAIL sent by a user who is set to DIGEST but not also set to NOMAIL will cause the user to be set to NODIGEST (the behavior is identical for users set to INDEX but not to NOMAIL). SET listname MAIL sent by users set to DIGEST/NOMAIL or INDEX/NOMAIL will simply remove the NOMAIL setting and leave the user set to DIGEST or INDEX as the case may be.

Note: In extreme cases, subscribers using the DIGEST option may receive more than one digest per cycle if the digest limit is reached before the end of the cycle.

Toggles MIME functions on and off. Currently this is only useful if the user has a mail client that supports MIME digests. Users who send their SUBSCRIBE command using a MIME-compliant agent will have this option set automatically unless "Default-Options= NOMIME" is specified for the list.

In future versions, this toggle may control other MIME functions.

Causes the subscriber to receive one posting per digest cycle containing only an index of subject topics for all messages during that cycle. See the section on DIGEST (above) for further information.

These three command words control the level of acknowledgment the subscriber receives when posting to the list. ACK causes LISTSERV to send a short confirmation message to the subscriber when the post has been received and distributed. NOACK disables the confirmation feature for the subscriber (although BITNET subscribers will receive a short interactive message on their terminal). For BITNET subscribers, MSGack provides the same information as ACK via interactive messages.

By specifying one of the following command words, the subscriber can control the amount of mail header information prepended to list mail. The syntax is SET listname headertype, where headertype is one of the following:

•	SUBJecthdr – "Full" RFC822 mail headers (like the default), except that LISTSERV adds the list's default subject tag to the subject line of mail coming from the list. To turn this off, simply set another mail header option.

Note: Do not use FULL822 or SHORT822 unless debugging specific problems or unless directed by L-Soft. Use of these options can seriously slow performance as they force LISTSERV to generate a separate "envelope" for each user so set. FULL822 and SHORT822 are obsolete but remain available for compatibility with certain older BITNET mailers still in use.

Quite a few non-technical users are relying on non-RFC822 user interfaces for reading their mail. Quite often these user interfaces are user-friendly, quality implementations of a proprietary mail protocol which the users are proficient with, but which happens not to lend itself to bidirectional mapping to RFC822. The users may have a good reason for using this particular program, and they complain that it is not always clear what list the postings come from, or who posted them. Other users have very primitive mail programs which do not preserve the original RFC822 header and may not even have a "message subject" concept. The user knows which list the message came from, but not who posted it, making private replies impossible.

The DUALHDR (minimum abbreviation: DUAL) header option is provided to help solve this problem. Dual headers are regular short (SHORThdr) headers followed by a second header inside the message body. This second header shows what list the message is coming from ('Sender:'), the name and address of the person who posted it ('Poster:'), the poster's organization, if present, and the message subject. The date is not shown because even the most primitive mail programs appear to supply a usable message date.

The SUBJECTHDR (minimum abbreviation: SUBJ) header option is provided for users who want to see a "tag" in the subject line of their incoming list mail that indicates where the mail is coming from (e.g., to activate a filter in their mail program to drop the message into a specified notebook). If you have SHORT headers (or any other header option) set, setting your option to SUBJecthdr will automatically change you to FULLHdr, as subject tags require full headers. Also, subject tags are not generated for messages sent without a RFC822 "Subject:" header.

Generally, users will be well-served by the FULL header option, which is the default.

Documented Restriction: The use of the SHORTHDR or DUALHDR options will break messages that depend on MIME encoding, because these options strip the RFC822 headers that identify the message as a MIME message. SHORTHDR and DUALHDR were designed for the non-MIME mail clients which prevailed in LISTSERV's early history. As most mail clients today support MIME, the use of these options is now deprecated.

To do this, use the SUBJecthdr personal option as explained in the previous section. To set this option by default for new subscribers, include it in the Default-Options= keyword setting for your list (see Section 14.4 Setting Original Default Options with the Default-Options= Keyword). To set it for existing subscribers, use the SET command.

Occasionally, a subscriber may not want his presence to be known to someone else making a casual REView of the list. Subscribers may choose to "hide" their subscription from the REView command by using the CONCEAL command. Conversely, a subscriber may choose to remove this restriction by issuing the NOCONCEAL command.

Note: The list owner can always obtain a list of all subscribers, both concealed and unconcealed, by issuing the GET listname (NOLock) command, or by issuing a QUERY listname WITH CONCEAL FOR *@* command.

This option controls whether or not the subscriber will get a copy of his or her own posts back from the list after they are processed. Generally, if a subscriber's mail program is configured to file copies of the subscriber's outgoing mail, or if the subscriber has one of the acknowledgment options (ACK/MSGack) enabled, this option should be set to NOREPro. If, on the other hand, the subscriber is set to NOACK and doesn't keep a copy of outgoing mail, this option should probably be set to REPro.

Topics are not available in LISTSERV Lite.

If list topics are enabled, this option allows the subscriber to specify which topics he or she will receive. The syntax of a SET TOPICS statement is significantly different from that of the other options. See Section 15.7 Using List Topics for more information on this syntax.

This option may be set only by list owners or the LISTSERV maintainer. It is not available in LISTSERV Lite.

A subscriber set to NOPOST may not post to the list. NOPOST gives the individual list owner the ability to serve out abusive or obnoxious posters without having to add such users to the list's "Filter=" setting. Subscribers set to NOPOST will still receive list mail – they just won't be able to post mail to the list.

The list owner or LISTSERV maintainer may issue the

command to reverse a previously-set NOPOST.

Note: For peered lists, NOPOST must be set globally or a user can bypass the setting by simply posting to another peer. Thus, you must add the user manually to the other peers and then set the user to NOMAIL as well as NOPOST on the peers.

Setting NOPOST for a user cancels any previous EDITOR or REVIEW setting for that user.

Note: List editors who are set to NOPOST will be able to approve messages but will then be told they cannot post to the list. The NOPOST subscriber option does override any Editor= or Moderator= definition in the list header, so be sure that your editors and moderators are set to POST.

This option may be set only by list owners or the LISTSERV maintainer, and is effective only on moderated lists. It is not available in LISTSERV Lite.

A subscriber set to EDITOR on an edited/moderated list may post directly to the list without a moderator's intervention. It is virtually identical to adding the subscriber's address to the "Editor=" keyword, but easier to manage. The only difference between the EDITOR option and the "Editor=" keyword, other than not being visible in the list header, is that the "Editor=" keyword also defines a (seldom used) access level class that can then be used in keywords such as "Review=". Thus, one could have a list with "Review= Editor", indicating that only the users listed in the "Editor=" keyword are allowed to review the list. The EDITOR option does not confer this privilege.

The list owner or LISTSERV maintainer may issue the

command to reverse a previously-set EDITOR.

Setting EDITOR for a user cancels any previous NOPOST or REVIEW setting for that user.

This option may be set only by list owners or the LISTSERV maintainer. It is not available in LISTSERV Lite.

When a subscriber is set to REVIEW, all postings from that subscriber are forwarded to the list editor or list owner for approval. Approval for these postings is always via the OK mechanism – there is no need to forward the posting to the list, simply reply to the approval confirmation with "OK".

Note that if a list is unmoderated, it is still possible to direct REVIEW postings to a specific person by adding an "Editor=" or "Moderator=" keyword to the list header.

The list owner or LISTSERV maintainer may issue the

command to reverse a previously-set REVIEW.

Setting REVIEW for a user cancels any previous NOPOST or EDITOR setting for that user.

This option may be set only by list owners or the LISTSERV maintainer.

Enables or disables subscription renewal confirmation on an individual subscriber basis. Setting a subscription to NORENEW is particularly useful for exempting list owners, redistribution lists, and other subscriptions which should not or must not receive the confirmation request message from the renewal process.

The list owner or LISTSERV maintainer may issue the

command to reverse a previously-set NORENEW.

The list owner may specify original defaults for many subscriber options by using the "Default-Options=" keyword. This keyword takes regular SET options as its parameters. Examples include:

You may have more than one "Default-Options=" line in your header, as needed.

Notes: Any default topics are set with the "Default-Topics=" keyword. See the List Keyword Reference document for details on this keyword.

Your existing subscribers are not affected by any change to the Default-Options= keyword. This keyword sets initial options only for people who subscribe after it is defined. If you want to update your existing subscribers to the Default-Options settings, you must use the SET command with a wildcard (i.e., FOR *@*) to do so.

The Misc-Options= keyword is a catch-all for certain behavior-modifying options that are not otherwise covered by other, more specific keyword settings. Currently the only options available are as follows:

Replaces "Language= NoHTML", which is deprecated starting with LISTSERV 15.5.

Tells LISTSERV to strip any HTML attachments from postings (while retaining HTML tags sent in the body of plain text messages).

The actual function of this setting is to remove the attachment that contains the HTML mail from the message. It does not remove HTML tags from plain text messages. This means that setting this option will not suppress HTML in messages sent from (for instance) Eudora Pro 3.x (since Eudora Pro 3.x does not send the HTML message as a MIME attachment with a plain text alternative).

If an HTML message does not contain a plain text alternative, and this option is set, the message will be rejected. LISTSERV 1.8d and earlier would allow such messages through.

Add subject tags to IETF headers (that is, for users who are set to the IETFHDR personal option). However, as this can be considered a violation of the standard for IETF-style headers, it can be prevented site-wide by the site administrator if desired.

Adding “Misc-Options= IETFHDR_SUBJECT_TAG“ to the list header causes the IETFHDR option to always include subject tags. This is a per-list setting; in other words, either all subscribers to a list who are set to the IETFHDR option get the subject-tag, or no. The design consideration is that, at present, it is prohibitively expensive to switch the existing header types into flags as the number of combinations grows significantly.

These options are mutually-exclusive; only one can be defined at a time per list.

When set in a list header, "Misc-Options= IGNORE_EMAIL_CASE" causes the ADD command to ignore the case of the "local part" of list subscriber entries (that is, the part of the address that is to the left of the "@" sign). Although most modern mail clients are configured to ignore the case of the local-part, this behavior technically violates RFC821 which states that local-parts are considered case-sensitive.

If an entry whose "local part" differs only in case is found in the list during an ADD operation (for instance, JOE@EXAMPLE.COM vs. joe@EXAMPLE.COM), that entry will be assumed to be the entry that was sought, and the address field will be updated to the new case (that is, "JOE@" will be changed to "joe@"). No other change will be made to the entry unless there is a change in the name field, in which case the name field will also be updated.

If there is no change in the address field associated with the entry, no change will be made to the entry (again, unless the name field changes, in which case the entry will be updated).

In either case, when this option is set, a new entry with a different case will NOT be added.

Note the following caveats:

Other than this, existing duplicate entries work exactly as they did before the option was enabled. Commands that do not add new entries ignore the option.

And finally, it should be carefully noted that the PUT command also ignores the option.

When a list is set to "Misc-Options= RESPECT_EMAIL_CASE", this tells LISTSERV to operate per RFC821 and treat address fields with differently-cased local parts as different addresses. The option is provided as an override to the site-level IGNORE_EMAIL_CASE configuration variable and does not need to be set to preserve the default unless the site setting has been changed to make IGNORE_EMAIL_CASE the default.

Incoming DomainKeys signatures in messages submitted to a mailing list will be suppressed unless "Misc-Options= KEEP_DKIM_SIGNATURE" is set in the list configuration.

The KEEP_DKIM_SIGNATURE option is experimental and not meant for general use. As DomainKeys is specified today, signatures DO NOT survive posting to mailing lists (LISTSERV or otherwise), so LISTSERV removes them by default to avoid triggering alerts for subscribers on systems that have implemented the client side of DomainKeys.

Replaces "Language= Exchange", which is deprecated starting with LISTSERV 15.5.

Tells LISTSERV to keep Microsoft Exchange attachments in postings (the default is to remove them). Note that this affects "application/ms-tnef" attachments only-- LISTSERV does not currently strip WINMAIL.DAT attachments.

"Misc-Options= NO_DKIM_SIGNATURE" is available at the list level to override LISTSERV's default DomainKeys message signing if desired.

RFC2369 support is activated by default and supplies all of the headers specified in the standard except "List-Post:", which L-Soft considers to be redundant.

In compliance with RFC2369, LISTSERV discards any pre-existing List-xxx tags.

RFC2369 compliance can be disabled using:

* Misc-Options= NO_RFC2369

and this can also be specified in the site-wide DEFAULT_MISC_OPTIONS variable. When RFC2369 support is disabled, you get the old behavior; that is, the tags are neither added nor removed.

Use this option to disable spam scans for a particular list and its associated xxx-request address. (This is only useful if the LISTSERV maintainer has enabled spam-scanning via the SPAM_EXIT feature.)

See above at IGNORE_EMAIL_CASE | RESPECT_EMAIL_CASE.

It is possible for each list posting to have a sequence number attributed to it, which can be seen by subscribers who are set to the SUBJECTHDR personal option. This new feature is enabled by adding "Misc-Options= SUBJECTHDR_SEQUENCE" to the list header. Site administrators can enable it server-wide by adding the value SUBJECTHDR_SEQUENCE to DEFAULT_MISC_OPTIONS in the site configuration. The format of the new subject tag is

Subject: [TEST - 256] Test of SUBJECTHDR_SEQUENCE

where 'number' is a sequence number, starting from 1 and increasing indefinitely for all practical purposes (the counter will accommodate over 2 billion postings per list).

"Subject-Tag=" is still used to change the first item. In order to allow server administrators to set a server-wide default for the new feature, it was not possible to implement the sequence number feature as an extension to "Subject-Tag=".

Note: Both the new [listname - number] and the traditional [listname] tags are removed from the subject on incoming messages. This happens whether or not the option is set, because people might be replying to old messages before the option was changed.

LISTSERV tries very hard never to skip a sequence number. The only plausible scenario in which this could ever happen would be when the MTA (not LISTSERV) fails to deliver the message. However, there are several cases where a sequence number will be reused:

•	If the site administrator deletes or temporarily renames PERMVARS.FILE in an attempt to solve an unrelated problem. Deleting PERMVARS.FILE is not supported as a troubleshooting method.