> However, if you have a need for a list of currently available options in > a compact, easy to parse format, this can and should be provided through > a standard command. I did know that people used the flag codes, but I > thought (based on the discussions on this list when flag codes were > mentioned) that this was done only to do the equivalent of QUERY WITH. I > did not know that some people used it to prepare statistics. Anyway, I'll > look into providing a standard method for that in the next version. > > Eric LISTSERV itself could do a much better job of producing useful statistics. Of course, it will never be possible to produce all the statistics that someone might want, so tools are needed too. I recently started a wish list for LISTSERV enehancements, based on things I've thought of or have seen mentioned here. Here's a copy of the latest version: LISTSERV Wish List October 15, 1995 (1) A simple command to change the address of a subscriber (e.g., CHANGE listname old-addr new-addr). List owners could use it on their own list. LISTSERV postmasters could use it on all lists on a server. The advantage over subscribing and unsubscribing is that users settings would be preserved. The advantage over issuing a GET and editing the list of subscribers is that it's safer and would work on multiple lists. (2) Statistics on usage of lists for list owners and LISTSERV postmasters. Statistics should be kept on number of subscribers, number and size of posts, and number of bounces redirected to the list owner. Reports should be available daily, weekly, and monthly. There are various uses for this, such as to identify unused lists, identifying lists that are generating an excessive number of bounces, and to justify the existence of the LISTSERV. (3) Statistics on the usage of files in a file list, to be used primarily for identifying unused files. (4) Statistics on the usage of list archives by the data base function. (5) Messages sent to all-request should contain the list name so that bounces can be identified with the list whose owner they are for. (6) The ability to control the spam filter on a per subscriber basis, primarily for use with netnews gateways. (7) When a message is sent to two or more lists on the same server, users subscribed to more than one of the lists should receive only one copy of the message. (8) Security violations should be clearly noted in the log. (9) Control of defaults on a per server basis, by the LISTSERV maintainer. (10) A better way than using Resent- headers for a moderator to send edited messages back to the list so that they appear with the original poster's email address. (11) MIME digests. (12) Support for Delivery Status Notifications. This should allow for more automated processing of bounces. (13) LISTSERV messages in MIME format for messages to list owners, postmasters, and in response to commands. (14) Output from the QUERY command that is more amenable to machine processing. (15) QUERY support for topics.