Use this option to force the list archive pages to be rendered with the (pre-17.0) legacy web templates.

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

Use this option to suppress RFC822 "Approved-By" headers that would normally be generated by LISTSERV in messages posted through moderated lists.

Use this option 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 "MIME part" that contains the HTML mail from the message. If the message consists only of an HTML part, the sender will receive a rejection notice.

Use this option to specify that LISTSERV keep Microsoft Exchange attachments in postings (the default is to remove them).

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:

• Pre-existing duplicates are not automatically removed from lists when this option is set.
• Because ADD updates the case of entries, it is possible to end up with multiple entries that have exactly the same case.
• The only real way to de-dupe a given address is to delete and then re-add it.

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.

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.

It's 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 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

The number is a sequence number, starting from 1 and increasing indefinitely.

The "Subject-Tag=" keyword 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.
• If the list is migrated to a new host.
• If there is a crash, disk full error, etc., when updating the counter.

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 none.

This option is available at the list level to override the default DKIM message signing of LISTSERV if desired.

Incoming DKIM 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 DKIM 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 DKIM.

RFC2369 calls for the use of message headers such as "List-Help", "List-Subscribe", and "List-Unsubscribe". A list posting using these headers will look like this:

List-Help: <https://listserv.example.com/scripts/wa.exe?LIST=TEST>,
<mailto:LISTSERV.EXAMPLE.COM?body=INFO+TEST>
List-Unsubscribe: <mailto:TEST-unsubscribe-request@LISTSERV.EXAMPLE.COM>
List-Subscribe: <mailto:TEST-subscribe-request@LISTSERV.EXAMPLE.COM>
List-Owner: <mailto:TEST-request@LISTSERV.EXAMPLE.COM>
List-Archive: <https://listserv.example.com/scripts/wa.exe?LIST=TEST>

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". 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.