Misc-Options=
Misc-Options= option1,option2...optionn
This keyword is not available in LISTSERV Lite.
This keyword is a catch-all for certain behavior-modifying options that are not otherwise covered by other, more specific keyword settings. The current options available are as follows:
Replaces "Language= NoHTML", which is deprecated.
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.
Please see also IETFHDR Considerations.
IGNORE_EMAIL_CASE | RESPECT_EMAIL_CASE
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.
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.
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.
Controls whether the 16.5 legacy interface (or "compatibility mode") is used for an individual list. This would be used in a case where the site administrators have enabled the 17.0 web interface sitewide, but a particular list, either for user-friendliness or because of significant list-level customizations (or both), prefers to remain at the 16.5 legacy interface for a while. This would be set in the list header with:
* Misc-Options= LEGACY_INTERFACE
Note that in order to use Misc-Options for this purpose, the site-level variable WWW_ALLOW_LEGACY_INTERFACE cannot be set to 0. If it is set to 0, "Misc-Options= LEGACY_INTERFACE" is ignored. If you are unsure whether or not you can use this setting, please contact your LISTSERV administrators.
Conversely, the LISTSERV administrator may set the legacy interface as the default for all lists. If this is the case, it may be possible to override that setting at the list level and use the 17.0 responsive interface instead; to do that, simply set a Misc-Options= keyword setting that doesn't include LEGACY_INTERFACE. However, if the LISTSERV administrator has configured the site default to force all lists to use the legacy interface, it will not be possible to override this at the list level. Again, if there is any question, please contact your LISTSERV administrators for guidance.
The option NEW_MESSAGE_ID has been available for the Misc-Options= list header keyword since the LISTSERV 16.0-2017a level-set release (builds dated 28 Feb 2017 and following). When specified, this causes LISTSERV to generate a new RFC822 Message-ID: field for outbound messages. This solves a problem with email providers that bounce messages with duplicate Message-ID: fields. Specifically, it solves the problem experienced by Gmail subscribers who are set to the REPRO option, and currently do not receive the copy of their own mail sent to them by the server after it is processed.
|
|
WARNING: Setting this option may cause idiosyncratic issues with the way Gmail presents the mail in its indexes. The REPRO copy of the mail will show up in both the Sent folder and the Inbox folder, as part of a single thread. This is cosmetic only; the links are to the same message, and if one is marked as read, the other will also be marked as read. Additionally, if the Gmail user's subscription is set to SUBJECTHDR, the Gmail interface will not display "[LISTNAME]" as part of the subject of the REPRO copy. This could lead to the erroneous conclusion that the original message and the REPRO copy are duplicates, except for small differences in the timestamp. The only useful way to show the difference is to use Gmail's "Show original" feature to inspect the headers thus revealed. |
|
|
WARNING: It should be noted that systematically changing message IDs does not follow relevant Internet standards for mail, and could promote mailing loops. Consider carefully whether or not the benefits of viewing REPRO mail in Gmail outweigh the potential problems engendered by changing message IDs before adding this setting to your list(s). |
"Misc-Options= NO_DKIM_SIGNATURE" is available at the list level to override LISTSERV's default DomainKeys message signing if desired.
LISTSERV supports RFC2369, which 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:
Date: Fri, 21 Oct 2005 14:21:03 -0500
Reply-To: Test list <TEST@LISTSERV.EXAMPLE.COM>
Sender: Test list <TEST@LISTSERV.EXAMPLE.COM>
From: Some User <someuser@EXAMPLE.COM>
Subject: What's all this RFC2369 stuff?
To: TEST@LISTSERV.EXAMPLE.COM
Precedence: list
List-Help: <http://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: <http://listserv.example.com/scripts/wa.exe?LIST=TEST>
I was curious about these new headers, can someone enlighten me?
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.)
Use the option to disable the UTF-8-aware "plaintext" digests which are generated by default beginning with LISTSERV 16.0, and revert to the old 7-bit plaintext digest format. For more information on the UTF-8 digest format, please see the Digest= keyword documentation, above.
A list header keyword used when Feedback Report Processing is enabled. NOTE: This value should be set ONLY for the list especially designated to receive such reports. It should NEVER be set by a list owner.
For more information on the SPAM_FEEDBACK_PROBE site configuration variable, see the Advanced Topics Manual.
RESPECT_EMAIL_CASE
See above at IGNORE_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. The 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 sequential subject tag is
[listname - number]
For example:
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 newer [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.
Use this option to suppress RFC822 "Approved-By:" headers that would normally be generated by LISTSERV in messages posted through moderated lists.
Please use this option with caution. If you have multiple moderators and there is a question regarding which moderator approved a given message, this is the easiest way to debug that problem. Otherwise your only recourse is to look through the LISTSERV console logs to pull out this information.
Setting this option tells LISTSERV what character set to use for the list's title line, which allows the use of Unicode characters in the title. Examples:
Misc-Options= TITLE_CHARSET:KOI8-R
Misc-Options= TITLE_CHARSET:ISO-8859-8
etc.
Setting this option tells LISTSERV that the list header may contain UTF-8 characters in keyword values. Starting with LISTSERV 16.0, this option is set by default when creating lists via the web interface list creation wizards.