> 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.
|
