All of K-State's LISTSERV mailing lists were moved from KSUVM to the central Unix system on June 30, 1997. At that time, an upgrade was made from LISTSERV 1.8a to to version 1.8c, and a number of changes were made to the lists for improved security, efficiency, and communication.
Changes that were made
Other effects of the upgrade
Notebooks, the log/archive files of past correspondence, are now stored in 1 of 4 subdirectories (a,b,c,d) on the central Unix system. This is reflected in the "Notebook=" option, which now may look something like this in the list header:
This does not affect how copies of log files are retrieved. List owners should continue to use the same log-retrieval process, by sending a "GET listname LOGyymm" command to listserv@ksu.edu.
When making list-setup changes, a list owner must not change the location of the notebook archives. Owners may change the notebook interval (weekly, monthly, etc.) as well as the access levels (who can get the notebooks). Owners may also choose to discontinue notebook storage, but cannot enable notebook archives once disabled (contact listhelp@ksu.edu if notebooks are to be enabled again).
A command-confirmation feature was added to verify owners' commands. This effectively prevents hackers from forging (spoofing) e-mail addresses of list owners and making changes to someone else's list. Thus, the previous "Validate= Store only" option was changed to
This requires list owners to confirm most changes to lists with a second piece of mail. In other words, the new process is:
(Note that the previous "Store only" option is obsolete under LISTSERV version 1.8c, and storing a list header with this value results in a non-fatal warning from LISTSERV.)
A subscription-confirmation feature was added to all open-subscription lists and those requiring owner-approval of subscription requests. This prevents miscreants from subscribing others to unwanted lists as a prank or as harassment. (The victim just gets confirmation requests which can be ignored.) It also helps deter multiple bogus subscriptions intended as harassment of selected lists. It impacted the "Subscription= Open" and "Subscription= By_owner" options which were changed to, respectively:
The net result is that people who send a subscription command to an open list or one requiring owner-approval of a subscription request will be asked to confirm their subscription request by replying to the LISTSERV message.
Public access to membership rosters of lists was discontinued. This prevents spammers from easily reviewing lists and compiling unauthorized mailing lists. Thus, any "Review= Public" option that was in place on any K-State list was changed to
The net effect is that people must, at a minimum, be subscribed to a K-State mailing list in order to see the membership addresses on that list. Lists with the "Review= Owner" option remain unchanged -- only the owner can see the membership list.
A STAFF-L user ID was added to all K-State lists, with this text:
Owner= quiet:
Added by CNS on 30 June 1997: Please do not edit or remove
the next line without contacting listhelp@ksu.edu first.
Owner= (STAFF-L)
This authorizes a small group of CNS technical staff to access a list's setups upon request by the list owner, for the sole purpose of solving technical problems. If the STAFF-L access is removed from a list, CNS will not be able to provide support to that list.
The "Files= Yes" option remains on all lists, but is obsolete since it doesn't work in the Unix environment. It will be removed from all lists at a later date.
This option doesn't affect file storage; it just allowed files to be sent in the form of e-mail to a list via the Bitnet network. Therefore, WELCOME, FAREWELL, and MAILTPL system files may still be stored in conjunction with lists. Special information files may also be stored when a list owner provides sufficient justification for this need. However, list owners are encouraged to put most information files on the web for easy access by list members and others.
The statistics option ("Stats= None,Owner") has been removed from all lists. This feature was not utilized in the past.
Any "list passwords" in effect were removed. (See the related command-confirmation feature in this document.) Owners may choose one of two methods for ensuring the security of their list's setups:
This section will continue to be updated as effects are identified.
List names can be up to 15 characters long. The list name or list ID, which becomes part of the listname@ksu.edu address, was restricted to 8 characters on K-State's IBM server. The Unix system allows much longer names, so 15 characters has been established as a practical limit. This should be good news for owners who want to create more descriptive list names for their mailing lists.
The GIVE command (which worked in 1.8a) doesn't work in LISTSERV version 1.8c. It is reported to work in L-Soft's upcoming version 1.8d, which is expected to be installed at K-State later this year. This command enables list owners to send a list-associated file via e-mail to a user's address, instead of requiring a user to get the file on their own.
A new format is required when listing quiet owners. The old format for listing quiet owners in K-State list headers must be updated when an owner first changes a list using the GET and PUT commands, else it will cause an error message. (This doesn't affect ADD and DELETE commands done for subscriber changes.) The new format for listing quiet owners is:
Example of new format
* Owner= betsy@ksu.edu
* Owner= quiet:
* Owner= neil@ksu.edu
* Owner= editor@ksu.edu
Example of old format
* Owner= betsy@ksu.edu
* Owner= quiet:,neil@ksu.edu
* Owner= quiet:,editor@ksu.edu
Adding multiple subscribers is more complicated now; it can be done more easily if owners use a batch-job process. With the command-confirmation option now in place, LISTSERV requires separate confirmation for each subscriber added to a list -- regardless of whether the subscriber joins on their own or is added by the list owner. For owners who want to add several people to their list at a time, the resulting confirmation requests from LISTSERV -- each of which requires a reply -- can cause mail increases and time demands on the list owner's part. One way around this is to send a batch-job command that contains all the subscribers' addresses to be added.
The process is:
QUIET ADD listname DD=X IMPORT //X DD * userid1@internet.address Firstname Lastname userid2@internet.address Firstname Lastname userid3@internet.address Firstname Lastname /*
where
Deleting multiple subscribers causes command-confirm requests for each. The old method of deleting several list subscribers at one time was to send one message to listserv@ksu.edu with one DELETE command per line for each user. This is still the same method that list owners should use. However, the command-confirmation process now in place for all the lists makes LISTSERV send e-mail asking for separate confirmation of each DELETE command. In other words, a message sent to listserv@ksu.edu with five DELETE commands will generate five messages from LISTSERV -- and each will require an "OK" message sent back by the list owner.
If you need to delete the entire membership of your list, CNS will do this for you. Send e-mail to listhelp@ksu.edu or call 532-4909 and specify:
Home |
Search |
What's New |
Help |
Comments
Kansas State University |
Computing and Network Services
June 22, 1998