This document is a sub-set of the Site Maintainer's Release Notes, which has been prepared for List Owners who are not involved in LISTSERV site maintenance.
Copyright © 2002 L-Soft international, Inc.
23 May 2002
· Usability: (Non-VM) Automatic change-log rotation
· Usability: New change-logs start with a SUBCOUNT entry
· Usability: Moderation OK requests and MIME message display
· Usability: GETPOST and MIME message display
· Usability: Commands: LISTS OWNED BY, LISTS MODERATED BY
· Usability: Revamped web administration interface
· Usability: Content filtering
· Usability: Sizelim= may be specified in kilobytes or megabytes
· Usability: Top and bottom banners now visible in MIME postings
· Usability, Anti-Spoof: "Subscription= By_Owner,Confirm" available
· Security, Anti-Spam: "Received:" header added for incoming -REQUEST mail
· Security: Attachments= changes to block inline UUENCODEd files
· Security: Explicit canceling of "OK" confirmation codes supported
Please note that this feature is not available under LISTSERV Lite.
1.8d introduces "periodic" change-logs, with the ability to automatically rotate them in a manner similar to that used for list archive notebooks. There are several new keyword settings and configuration variables.
·
The existing
Change-Log= list header keyword syntax is changed to
* Change-Log= Yes[,Yearly|Monthly|Weekly|Daily|Single]
The change to the keyword parser for this new feature necessitated a change to
LISTKWD FILE, which means that unix sites upgrading to LISTSERV Classic 1.8e
must be particularly careful to download BOTH the `uname`.tar.Z for their unix
platform AND common.tar.Z when obtaining the installation kit. (LISTSERV Lite sites upgrading to LISTSERV
Lite 1.8e do not have this problem as everything is shipped in one archive.)
· The new site configuration file variable DEFAULT_CHANGELOG_PERIOD defines the default for above. This in turn will default to SINGLE if unspecified, for compatibility.
· (Classic and Classic HPO only) The existing site configuration file variable SYSTEM_CHANGELOG definition was expanded from Boolean (0 or 1) to allow a period to be specified, e.g. SYSTEM_CHANGELOG=MONTHLY. 0 turns it off as before and 1 maps to SINGLE for compatibility.
· NOLIST-xxx change logs are always SINGLE.
· Rotated logs are renamed to CHANGELOG-yyyy[mm[dd|w]]. GET was changed to recognize these as change logs.
· When the feature is introduced (i.e. when upgrading to 1.8e), old logs will be renamed based on the date in the last entry. If the last entry is compatible with the newly introduced period (e.g. logs are YEARLY and the last entry is 2001), the log will continue, even if there were also entries for 2000. The definition of the 2001 log is that it contains all the entries for 2001, not that it is the first log started in 2001. Logs are not split as the feature is introduced.
· If the rename fails (e.g. because you keep changing the period back and forth), the current log continues.
· While LISTSERV on VM will accept all of the above settings without complaint, everything will behave as if you had specified SINGLE. This is because filetypes are limited to 8 characters on VM and it would be difficult to support a different naming convention just for VM.
Please note that this feature is not available under LISTSERV Lite.
List-level change-logs on all platforms now start with a SUBCOUNT entry showing the subscriber count at the time the change-log was started. Note carefully that this change does not affect NOLIST or SYSTEM change-logs, or change-logs already started before 1.8e was applied.
An example to show the format is
20011201111349 SUBCOUNT 115
In previous versions, an OK confirmation request for a message coming to a moderated list displayed the message to be approved in its "raw" format, i.e., there was no attempt made to display/decode MIME attachments that might be present in the message to be approved. LISTSERV 1.8e addresses the problem by including a copy of the first text/plain part (if one exists in the message) for the purpose of quick screening. The following restrictions apply:
1. This is only done for MIME messages (even simple single-part ones, but they must have MIME headers).
2. The text part in question is sent pretty much 'as is', that is, as an extra text/plain part in the message, with all the options and encoding and what not supplied in the original message. The reason is quite simply that it would be a lot of work and, in some extreme cases (incompatible code page, etc), completely impossible, to embed it into the first text/plain part with the LISTSERV message. The drawback is that some mail agents might conceivably only show the first part until you take some kind of clicking action.
It is important to understand that only the first text/plain part is extracted in this fashion. The goal was to make it easier to approve or reject simple text messages, not to build a factory around a simple problem. The ENTIRE message is available at an extra click.
Where security is a concern, it is important to review the ENTIRE original message and not just the plain text part. There could be an obscene GIF or another text part or a text/html part not matching the contents of the text/plain part or whatever. This is why, again, you are given the ENTIRE original message.
List owners using certain email clients (specifically Pine, which handles attachments in a secondary viewing area) may find the new format difficult to use. If preferred, the pre-1.8e behavior may be reverted to by specifying "NOMIME" in the Send= list header keyword; for instance,
* Send= Editor,Hold,NoMIME
In previous versions, the GETPOST command returned messages that contained MIME attachments in their "raw" form, which could not be extracted automatically by MIME-aware mail clients. Customers who wished to use list notebooks to archive word-processing documents (for instance) found this to be a problem. In LISTSERV 1.8e, attachments returned in messages by way of the GETPOST command will now display as inline clickable links in the individual messages.
Users of certain email clients (specifically Pine, which handles attachments in a secondary viewing area) may find the new format difficult to use. If preferred, the pre-1.8e behavior may be reverted to by specifying "NOMIME" as the last parameter of the GETPOST command, for instance,
GETPOST MYLIST-L 2893-2910 2912 NOMIME
LISTSERV 1.8d was released with an undocumented feature for the LISTS command: LISTS OWNED, which returned a list of local lists owned by the invoker (the feature was originally added as part of the web administration interface and was not intended to be used otherwise). LISTSERV 1.8e adds functionality to this now-documented feature for site maintainers, who can now use it to determine which lists are owned by a given e-mail address. The syntax is
LISTs OWNed [[BY] [internet-address]]
A similar command structure to return a list of local lists that are moderated has also been added in 1.8e:
LISTs MODerated [[BY] [internet-address]]
In both commands:
· The BY token is optional.
· Wildcards are accepted.
· If the address is different from your own, you must be postmaster.
· Postmaster privileges of 'internet-address' are ignored. Thus, LISTS OWNED BY self from a postmaster only shows the lists actually owned by that postmaster, as opposed to showing all the lists on the server (which was the behavior under 1.8d, since postmasters are considered list owners of all lists on the server, even if they do not appear explicitly in an Owner= keyword setting). There is little point in doing LISTS OWNED BY another_postmaster if postmaster privileges are honored. To issue this command you need to be postmaster yourself, and you would then get the same results as with the old LISTS OWNED.
· Execution time will be long if you have lists with "Owner= (biglist)". The only way to avoid this would be to disallow wildcards. HPO could have a dual-path implementation in a future version if this turns out to be a problem.
At release time LISTSERV 1.8e will have a completely rewritten and revamped web administration interface. Two significant additions are a new web-based moderation interface and new extensible LISTSERV "wizards".
Documentation: A supplemental guide to the new web interface will be produced after product launch, with a target date of 3Q2002.
Please note that this feature is not available under LISTSERV Lite.
This feature is primarily intended to filter out-of-office messages and the like. It is not intended as a profanity filter. Attempts to configure it to filter profanity will most likely prove to be futile in the long run and are not recommended by L-Soft.
The new CONTENT_FILTER mail template form, if present, contains filtering rules, one rule per line, empty lines ignored. Each rule has the following format:
[prefix:] pattern
The prefix, if present, can be a mail header tag (e.g. "Subject:"); "Header:" to check the whole header; or "Text:" to search the message text. The latter is the default if no prefix is supplied, it is provided in case the pattern contains a colon in the first word. If there are multiple mail header tags with the specified name (e.g. "Received:"), each such tag is searched and it is enough for one of them to match the pattern. If the requested tag is not present in the header, there is (surprise!) no match. A text search will search every line of the first text/plain part in the message. If there is no text/plain part, there is no match. Again, this is designed to filter read receipts, loops, chain letters, spam, you name it. This is NOT a profanity filter and future versions will not be "enhanced" to make futile attempts at decoding Word documents to look for obscene words.
Regular comparisons such as those described above are not case sensitive. Patterns are standard LISTSERV patterns, ie the asterisk is the wildcard character. If there is no asterisk in the pattern, it is replaced with "*pattern*" much like the SCAN command.
The content filter also supports "exact match" comparisons, which are triggered by a double colon. For instance:
Subject::
There are two significant differences between exact and regular match:
a. You must supply your own wildcard characters in an exact match (if you want to use wildcards, that is). A regular match will insert leading and trailing wildcards if none are found. Thus, an exact match is the only way to make a comparison without wildcards.
b. You can make an exact match for the empty string. Empty regular matches are ignored since they map to a wildcard comparison for **, which would be always true. This also makes it possible to apply an exact match to a message that does not contain a specified header. For instance, if you want all messages to contain a (mythical) KABOOM: RFC822 header, with an exact match you can tell LISTSERV to perform one of the content-filtering actions if the the header is not present. This is not possible with a regular match.
Note however that you cannot differentiate a header with an empty KABOOM field from a header with no KABOOM field.
One of the most handy uses for the exact match syntax is to be able to write a rule to reject messages with blank subject lines. For instance:
Subject::
Action: REJECT Please resubmit your message with a non-blank subject.
Every rule can, optionally, be followed by an action rule. This has the following format:
Action: ALLOW
Action: REJECT reason
Action: DISCARD comment
Action: MODERATE
(The available actions are the same for both regular and exact comparisons.) For instance,
>>> CONTENT_FILTER
Subject: Out of office
Action: REJECT OOO messages are not allowed on this list.
Subject: Auto-Generated:
Action: REJECT
Text: Click here to be removed
Action: REJECT Buzz off, spammer.
Subject::
Action: REJECT Please resubmit with a non-blank subject.
Subject: copyright
Action: MODERATE
To: friend@public.com
Action: DISCARD This guy is a spammer
The default is "Action: REJECT" with no specified reason. REJECT means that the message is rejected. MODERATE means that the message is to be forwarded to the list editor to be manually approved or rejected. DISCARD means that the message is to be dropped on the floor without further processing; any text following DISCARD is echoed to the LISTSERV console (and is thus logged).
ALLOW means that the message is allowed and all remaining rules are ignored. This could be used in moderated lists to allow the list moderator to bypass certain filters, for instance:
>>> CONTENT_FILTER
Subject: Out of office
Action: REJECT OOO messages are not allowed on this list.
Approved-By: JOE@EXAMPLE.COM
Action: ALLOW
Text: Click here to be removed
Action: REJECT Buzz off, spammer.
In the example above, messages with Subject: lines containing "Out of office" are rejected. Messages containing the text "Click here to be removed" are also rejected UNLESS they come from joe@example.com .
The text of the rejection is fetched from the BAD_CONTENT mail template form, with the reason supplied as a variable called &COMMENT.
The Sizelim= list header keyword has been enhanced in 1.8e to allow list owners to specify a maximum message size in either kilobytes or megabytes, rather than in lines, which was the only way to do this in earlier versions. For instance:
Sizelim= 100K Reject messages over 100Kbytes
Sizelim= 1M Reject messages over 1Mbyte
As before, the limit operates against the entire message file, including all Internet header lines.
In LISTSERV 1.8d and earlier, the automatic banners placed on messages via the TOP_BANNER and BOTTOM_BANNER mail template forms fell outside of the MIME wrapper on MIME messages, and thus were not displayed in MIME-aware clients (the banner was physically present in the message but could not be seen unless the "raw" message was viewed). When the banner template forms were introduced in version 1.8b, most people were still using text-based mail clients and the banners displayed correctly for the majority of users. As time has gone by, more and more people have started using MIME-aware mail clients and the old behavior is no longer acceptable.
In LISTSERV 1.8e, banners are now displayed correctly in MIME messages.
In LISTSERV 1.8e the ",Confirm" option may now be specified with "Subscription= By_Owner" to force a confirmation from the would-be subscriber before the subscription request is forwarded on to the list owner, i.e.,
* Subscription= By_Owner,Confirm
Be careful to note that the underscore in "By_Owner" is REQUIRED in order for LISTSERV to see and parse the ",Confirm" parameter.
While the existing "Subscription= By Owner" syntax continues to work and be supported, it should be noted that this syntax is deprecated, and that attempts to code "Subscription= By Owner,Confirm" in a list header categorically will be evaluated as "Subscription= By Owner". This is because the LISTSERV parser understands a space not followed by a comma to be the end of the keyword setting, and LISTSERV actually parses "Subscription= By Owner" as "Subscription= By".
Please note that this feature is not available under LISTSERV Lite.
Please note that the anti-virus scanning software is available only for Windows NT/2000/XP and Linux, and that this feature is only available for LISTSERV Classic or LISTSERV Classic HPO sites running those operating systems. An L-Soft maintenance contract is also required.
LISTSERV Version 1.8e supports on-the-fly anti-virus scanning of all messages sent to mailing lists that run under LISTSERV Classic or LISTSERV Classic HPO on Windows NT/2000/XP and Linux servers, including inline uuencoded binaries and MIME attachments in those messages.
If installed (ask your site maintainer), list owners may not turn off AV checking (design decision - security). List postings containing viruses are always returned to the sender (design decision - the sender ought to be warned) even if filtering is otherwise enabled. However, attachments which have been filtered are not scanned for viruses.
When a virus is detected and the message returned to the sender, LISTSERV uses the BAD_ATTACHMENT mail template form to inform the sender. Note that this mail template form has been modified from the original which shipped with late versions of LISTSERV 1.8d. If list owners have modified BAD_ATTACHMENT, they should be notified to update the copy in their list-level template files.
LISTSERV also scans messages sent to the *-request and owner-* pseudo-mailbox addresses (including listserv-request and owner-listserv) and simply discards such messages if they contain viruses.
For more information, see the Site Maintainers' Release Notes.
The Received: header generated by LISTSERV for mail it receives on listname-REQUEST pseudo-mailboxes now includes the address of the listname-REQUEST mailbox to which it was delivered. This was done to avoid the impression that LISTSERV allows 3rd party relaying when the listname-REQUEST address is BCC’ed.
The Subscription=By_Owner message to the list owner (ADDREQ1) and Subscription=Open,Confirm confirmation message to the subscriber (CONFIRM1) now include the full headers or the original request or the IP address of web-originated requests. This change extends also to the ADD2 template form sent to the list owner when someone subscribes to the list and Notify= Yes, and to the SIGNOFF1 template form sent to the list owner when someone unsubscribes and Notify= Yes.
The ability to filter UUENCODEd "attachments" on a very basic level has been provided in LISTSERV 1.8e. This function is activated in 2 cases:
1. When a message containing one or more UUENCODEd "attachments" is sent to LISTSERV, which generally does not want to see any attachments in what it processes. In this case the encoded file is simply discarded.
2. When "Attachments= No[,Filter]" or "Attachments= "Yes[,…]" has been specified for a given list and a message containing a UUENCODEd file is posted to that list. In this case the encoded file(s) is/are stripped from the body of the message and the remainder of the message is passed through to the list.
If it is desired to allow UUENCODEd attachments, set "Attachments= All[,...]", where you can optionally specify specific types of attachments to allow as before; e.g., you can say just "Attachments= All" or "Attachments= All,image/jpeg,..."
One important restriction: UUENCODE filtering is strictly on/off. There is no attempt to guess file types. This would be hazardous to begin with as support for these attachments is usually provided on a legacy basis in mail clients, i.e. client A and client B could have a very different opinion on the type of the attachment.
In LISTSERV 1.8e and following, it is possible to explicitly cancel an OK confirmation code if so desired. The command is simply
OK CANCEL xxxxxxxx
(for instance, "OK CANCEL 8F2E8F4B"), and if the code is valid, LISTSERV will respond "Confirmation code 8F2E8F4B cancelled." If the code is not valid (e.g. has expired, has already been cancelled, or is simply incorrect), LISTSERV will send its standard message telling you in part that "The confirmation code 8F2E8F4B does not correspond to any pending command."
-------------------------------------------------------------------------
LISTSERV is a registered trademark licensed to L-Soft international, Inc.
L-SOFT and LMail are trademarks of L-Soft international.
LSMTP is a trademark of L-Soft international, Inc.
EASE and CataList are service marks of L-Soft international, Inc.
All other trademarks, both marked and not marked, are the property of their respective owners.
-------------------------------------------------------------------------
<end of file>