![]() |
Live LISTSERV® 1.8d Web Interface Demonstration This demonstration allows you to try out most of the functions available in LISTSERV's web interface. However, to prevent abuse, you will not be able to make any changes to the demonstration environment (create lists, add/delete users, post messages, etc.) |
||||||
DEMO Home | About L-Soft | Contact us | Feedback--Q&A | ||||
Server Administration Interface |
|||||||
Description of the changes for release 1.8d of LISTSERVÒ
Copyright 1998,1999 L-Soft international, Inc.
LISTSERV List Owner's Notes
The release notes for version 1.8d of LISTSERV have been split into two documents: list owner's notes and LISTSERV maintainer's notes. The present list owner's notes describe all the changes that list owners need to be aware of, although in some cases list owners may be impacted by changes described in the LISTSERV maintainer's section. For instance, the availability of a new systemwide option may prompt the LISTSERV maintainer to make a change affecting all the lists on the LISTSERV host. Thus, list owners are advised to read the maintainer's notes as well.
Summary of changes and enhancements
[non-VM] Enhanced WWW archive interface (support for non-public lists) Under version 1.8d the WWW archive interface introduced in version 1.8c has been expanded to include authenticated web archive access to non-public mailing lists. Non-public lists' archives are password-protected (with LISTSERV personal passwords, which can be obtained via the login screen) and are accessible only to those users who are covered by the Notebook= keyword's access setting. For instance on a list with Private notebooks, only subscribers may view the archives, and on a list with notebooks restricted to Owners, only list owners may view the archives.
[non-VM] Enhanced WWW archive interface (support for unlisted lists) Under version 1.8d, a link has been added to the main archive index page (the page constructed by the WWW_ARCHIVE_INDEX template form) to an "unlisted archive" form, where a user can type the name of a known list, click the "Submit" button, and be transferred to the list's index page. Such lists could be accessed under 1.8c but the URL had to be entered manually.
[non-VM] Enhanced WWW archive interface (clickable attachment links) Under version 1.8d, the WWW archive interface has also been enhanced to provide point-and-click links for e-mail attachments sent to lists. Assuming that a user's browser has a given MIME-type attributed to a helper application, he or she will be able to open attachments of that type which have been sent to the list in the appropriate application.
[non-VM] New WWW list and server administration interface In addition to the web archive interface enhancements, version 1.8d introduces a fully-featured list and server administration interface. List owners and site managers can perform almost any list-related maintenance task via the (again, password-protected) list owner interface, and in addition, site managers can create lists and manage the overall "look and feel" of the web interface.
[non-VM] New WWW subscriber interface The addition of the web administration interface and login authentication to LISTSERV 1.8d made it possible to allow general users to subscribe, change personal options, and signoff from a web form. This web form can be accessed from any of the web archive interface pages for a given list by simply clicking on the "Join or leave the list" link. All subscriber operations require a LISTSERV password for login authentication, which can be obtained via a link from the login page in the same manner as with list owner and LISTSERV maintainer logins.
Passive probing Active address probing (via the Renewal= list header keyword) introduced in version 1.8c has been supplemented in version 1.8d by the introduction of "passive" probing. In effect passive probing is very similar to active probing, but it is not tied to subscription renewal. Passive probing is enabled by default for small lists (e.g., <1K subscribers) but not for large ones due to the fact that passive probing does cost additional resources and large lists are often used for one-shot mailings where it is simply not effective to use those resources to probe addresses that will not be used a second time.
Since probes do not work with sendmail (unless it is modified), the default under unix is to disable passive probing altogether.
Passive probing operates by turning a certain percentage of your regular list messages into transparent probes that look like a normal message but also double as a probe, rather than sending out the explicit * Auto-Delete= Yes,Full-Auto,Probe(30)
where "30" is the number of days to wait between probes for any given user. Subscribers with working mail systems will not see any difference, subscribers with flaky mail systems will occasionally receive a message showing that their mail bounced and saying that they should report the problem to their ISP, and of course plain bad addresses will go away.
In order to disable passive probing you set the probe parameter to 0, i.e.,
* Auto-Delete= Yes,Full-Auto,Probe(0)
If you have users who for whatever reason should not be probed, you can deactivate passive probing (and any other renewal you have set for the list) with the If a given list only has activity once in a while (e.g., a large weekly newsletter), passive probing works like this: If you have You can set site-wide defaults for passive probing with the new DEFAULT_PROBE=21
tells LISTSERV to use a passive probing cycle of 21 days instead of the default of 30.
Because passive probing is very resource-intensive, above a certain list size it is disabled by default. The second (and optional) parameter to this variable is the list size beyond which passive probing is disabled unless you explicitly enable it in the Auto-Delete= list header keyword. For instance,
DEFAULT_PROBE=10 500
tells LISTSERV to use a passive probing cycle of 10 days and to enable passive probing by default only for lists of 500 users or less. Note that the two parameters are space-separated.
New .HH list header formatting directive Starting with LISTSERV 1.8d, it is possible to hide part or all of a list header (except for the list title) from users who send the REVIEW command or who try to view the list's configuration via the CataList. The following syntax is used:
* My very own list
The sequence can be repeated as many times as required. New "change-log" feature Starting with version 1.8d, this feature is available to track changes to lists with "Change-Log= Yes" coded into their headers. Setting the keyword to "Yes" for a given list causes LISTSERV to write a file called The operations monitored are Sample changelog entries are:
19980324100330 ADD xxxxxxx@JPS.NET Lxxxx Pxxxxxxxx
As you see, the New Bulk DELETE The ability to delete subscribers "in bulk", similar to the existing ability to "bulk add" (available since version 1.8b), has been added to version 1.8d. However please note that there is no " There is, however, a Once again you construct a LISTSERV JOB framework as follows and then send it to LISTSERV (tokens in square brackets are optional; do not type the square brackets when sending the command!):
[QUIET] DELete listname DD=ddname [BRIEF] [PW=yourpassword]
You will probably want to use the QUIET modifier when doing a bulk delete, in order to suppress the notification message to the users being deleted.
Bulk operations via the web Bulk operations can also be accomplished via the list management interface. Bulk operations are not enabled by default. The LISTSERV maintainer must create a directory called "upload" under the directory specified in the Please note carefully that your browser MUST support the RFC1867 file upload extension or you will not be able to use the bulk operations page. Most current browsers do support this extension, including but not limited to Netscape 3.x and later, and Internet Explorer 4.x and later.
New SUBSCRIBE ... WITH ... enhancement Version 1.8d introduces the following enhancement to the SUBSCRIBE command:
SUBSCRIBE listname full_name WITH option1 option2 ...
This syntax allows a subscriber to "preset" subscription options at subscribe time. For instance, a subscriber might want to subscribe to MYLIST-L in order to be able to search its archives, but doesn't want to receive any postings. The subscriber would use the command
SUBSCRIBE MYLIST-L Joe User WITH NOMAIL
Or a subscriber might want to receive individual postings with the SUBSCRIBE MYLIST-L Joe User WITH SUBJecthdr REPRO NOACK
This is particularly useful when the list requires an "OK" confirmation before the subscription is accepted (since it eliminates the need for a SET command after the user is added).
Note: The ADD command (as opposed to SUBSCRIBE) does not support "WITH" syntax.
"OK" confirmation mechanism enhancements Starting with version 1.8d, an "OK" confirmation can be sent from any userid, which helps when the address field of your mail gets changed somewhere along the line. For instance if you are logged into the web administration interface as joe@example.com and issue a command that requires mail confirmation, LISTSERV will send the request to joe@example.com (as expected). If your mail system expands joe@example.com to Joe_Doakes@mail.example.com, responding to the request under 1.8c would result in a failure because the cookie and the address in your From: line wouldn't correspond to what LISTSERV has on file. Under 1.8d the "OK" will succeed and Joe_Doakes@mail.example.com will get a message that says
> ok
while as a protection against "spoofed" commands the actual command response will be sent to joe@example.com like this:
jane@EXAMPLE.COM has been removed from the TEST list. No notification has been sent.
Global deletion process complete, one entry removed.
Three further enhancements were added to the "OK" confirmation mechanism in 1.8d:
OK BEGIN
Language= enhancements Starting with version 1.8d, the Language= list header keyword was expanded to cover the following functionality:
Language= HTML: This setting allows you to specify that LISTSERV's administrative messages (i.e., those specified in the MAILTPL and/or WELCOME and FAREWELL files) be sent out in HTML format. You specify either Language= NOHTML: This setting allows you to specify that LISTSERV strip any HTML attachments from postings (while retaining HTML tags sent in the
body of plain text messages). You specify either 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 Eudora Pro 3.x (since Eudora Pro 3.x does not send the HTML message as a MIME attachment with a plain text alternative). The setting also does not suppress HTML in messages sent from current versions of Netscape Messenger if the sender chooses the "Send in HTML mail only" option when sending the message (because there is no alternate plain text attachment for LISTSERV to use in that case).
Language= EXCHANGE: This setting allows you to specify that LISTSERV keep Microsoft Exchange attachments in postings (the default is to remove them). You specify either These three formatting options are not mutually exclusive and may be defined in any grouping (in other words, GIVE implemented on non-VM systems Beginning with version 1.8d, the GIVE command has been ported from VM and is available on all ports of the software.
File packages implemented on non-VM systems Beginning with version 1.8d, file "packages" functionality has been ported from VM and is available on all ports of the software.
The major difference between VM and non-VM is that under non-VM there are two ways to format entries in your $PACKAGE file:
First, a "compatibility" mode that works on all platforms, and which is identical to the original method used on VM (and which VM servers still must use). In the compatibility mode the basic format for the entries is
filename filetype filelist <optional_comments>
for example,
MYLIST $PACKAGE MYLIST The packing list
In the second (new) mode for non-VM servers only, the entries are formatted like this:
filename.extension <optional_comments>
for example,
MYLIST.$PACKAGE The packing list
For more information please see chapter 8 of the List Owner's or Site Manager's manuals.
New PUTALL command LISTSERV 1.8d introduces a new New BY DATE sorting option for REVIEW A new BY DATE sorting option has been added to the REVIEW command for version 1.8d. "REVIEW listname BY DATE" formats subscriber lines as follows, newest subscribers first:
jane@UNIX.EXAMPLE.COM [1998-08-05] Jane Doe
For lists running under 1.8d with pre-1.8c subscribers in the list (i.e., who predate the software upgrade that saves the subscription date), such subscribers are listed at the end of the REVIEW output, sorted by hostname/userid, as follows:
mary_smith@EXAMPLE.EDU [Unknown] Mary Smith New TOPICS option for REVIEW A new TOPICS option has been added to the REVIEW command for version 1.8d. "REVIEW listname TOPICS" appends a list of topics and the number of subscribers who are set to them at the end of the REVIEW listing. If you are only interested in the topics breakdown you can use the syntax "REVIEW listname TOPICS SHORT".
The topics breakdown looks like this:
Maximum number of Topics per list has been increased Under version 1.8d, a maximum of 23 topics (defined with the Topics= keyword) may be defined per list (increased from 11 in earlier versions).
More enhancements to the anti-spamming and anti-spoofing filters L-Soft acknowledges that these features have been continually upgraded and enhanced throughout the 1.8d development process, but in keeping with previously-announced policy, specifics are proprietary and will not be documented.
Support for listname-subscribe-request, etc., mailboxes Version 1.8d now supports the following generic -request mailboxes for lists:
listname (where "listname" is the name of the list in question). Mail sent to these addresses will be interpreted as explicit SUBSCRIBE, SIGNOFF, or UNSUBSCRIBE commands, respectively, for the list in question, regardless of the text contained in the body of the mail message (which will simply be discarded).
Unix and VMS hosts will need to add appropriate aliases (as usual) to sendmail and PMDF, respectively, in order to activate this functionality. Windows installations using either the SMTPL.EXE "listener" or LSMTP have this functionality activated automatically.
New CHANGE command to update subscriber addresses A new CHANGE command is available in version 1.8d. There are two syntaxes: A general user syntax and a list owner/LISTSERV maintainer syntax.
General user syntax:
CHANGE listname|* newaddr
List owner/LISTSERV maintainer syntax:
[QUIET] CHANGE oldaddr|pattern newaddr|*@newhost
The first form can be used by any subscriber and results in a cookie being sent to the new address. This cookie MUST be confirmed by the new address, exactly as it was entered, or the command will fail. This is the only case where a 1.8d cookie must be confirmed by a specific address. Note that this assumes that the user still has login access to both addresses, or at least the ability to send mail from the old address.
The list owner form does not use cookies but simply applies the standard "Validate=" rules (as for a DELETE command). You can specify a wildcard pattern for the old address and *@newhost for the new address to rename certain addresses to a new hostname. The CHANGE1 template is sent unless you specify QUIET.
Change log entries are made (CHANGE oldaddr newaddr) and there is a new CHG_REQ exit point which allows you to reject the operation. The CHG_REQ exit point is called as follows:
Name: CHG_REQ
Description: This exit point is called for the CHANGE command, and allows you to accept or reject the operation. If you return the value 1, LISTSERV rejects the operation.
Some default options (e.g., REVIEW, NOPOST) now apply to non-subscribers Starting with version 1.8d, certain default options coded in the Default-Options= list header keyword will be applied "on the fly" to non-subscribers who post to the list. Specifically the options applied are REVIEW, NOPOST, and NOEDITOR. For instance it is possible to code a "Subscription= By Owner" list with "Default-Options= NOPOST". When the list owner adds a user, he can simply send a "SET listname POST for userid@host" command to allow the new subscriber to post. Postings by any non-subscriber (for instance, a spammer) are rejected out of hand with a message informing him that he is not allowed to post to the list. In the same manner, using "Default-Options= REVIEW" allows the list owner to review any postings from non-subscribers while letting him allow known subscribers to post without moderation.
Enhanced "Filter=" list header keyword Version 1.8d adds the ability to "exempt" certain addresses (or wildcards) from the default filters. You can combine " Filter= Also,userid@host1.com,*@host2.edu
The first example stops everyone from host2.edu from posting to the list, but since we've determined that niceguy@host2.edu is a considerate human being and should be allowed to post, we've defined him as an exception to the general rule by defining him in the "Allow" part of the filter.
Filter= Safe,Allow,root@host1.edu
The second example would invoke the "safe" filter, but would allow root@host1.edu to subscribe to and post to the list, instead of bouncing his mail because it matches one of the entries in the "safe" filter. All other "root" users' mail will be caught by the "safe" filter and transferred to the list owner as an error.
8-bit administrative messages are encoded "on the fly" Starting with Version 1.8d, 8-bit characters (e.g., accented or national language characters) included in mail template forms will cause LISTSERV to encode the templates on-the-fly automatically, using MIME quoted-printable encoding. While there is no guarantee that every mail program will be able to properly display 8-bit characters, those mail programs that do understand MIME quoted-printable encoding should have no trouble doing so.
New character set formatting directives for mail templates Starting with version 1.8d, it is possible to direct LISTSERV to add a "Content-Type:" header to mail templates and WELCOME and FAREWELL files that contain 8-bit characters from a specified character set. In non-linear mail template forms one may code (for example)
.CS ISO-8559-7
and, assuming that the template in question contains 8-bit characters, LISTSERV will generate
Content-Type: text/plain; charset=ISO-8859-7
headers in the message when it is sent out. If the template contains all 7-bit characters the headers are not generated even if the .CS directive exists. Note that LISTSERV will not check to see whether or not the 8-bit characters match the character set defined.
For WELCOME and FAREWELL files, the same headers may be generated by adding (for instance)
Character-Set: ISO-8859-7
at the top of the file in question. Again, the file must contain 8-bit characters in order for these headers to be generated.
Please note carefully that the ISO-8559-7 character set is used here strictly as an example.
New =* and ^=* mail template operators Starting with LISTSERV 1.8d, the mail template operators [non-VM] File indexes now show byte sizes instead of LRECL and NRECS Starting with LISTSERV 1.8d, the output of the INDEX command issued to non-VM servers shows file sizes in bytes instead of the traditional (but VM-specific) LRECL and NRECS fields.
New serial numbering for digests and indexes Beginning with version 1.8d, LISTSERV digests and indexes now are numbered serially with the year and issue number for that year in the Subject: line. For instance,
Subject: MYLIST-L Digest - 20 Aug 1998 to 21 Aug 1998 (#1998-132)
Subject: TEST Index - 23 Jul 1998 to 21 Aug 1998 - Special issue (#1998-28) Miscellaneous changes and fixes --------------------------------------------------------------------------------------------------------------------------------
|
|||||||
© 1998 L-Soft international, Inc. |