Jose: your idea is good but very difficult to implement at present. Perhaps when we have the file server functions it will be easy to automatically add the stats files to 'listname FILELIST' with a GET=(listname) and PUT=Owner, which would allow the list owner to delete them easily and users to retrieve them. But at present, only the postmaster would be able to delete them or retrieve them :-( Any idea? As you may know I've been reshaping a few lists this weekend. I ran into a lot of troubles and decided to take steps to avoid them in the future. 1) I killed the EARNTECH list at CEARN by sending a STORE request to the wrong server -- the list intended for FINHUTC was stored at CEARN and here died the CEARN list. Hopefully I had kept a copy of it in my reader and could res tore it. I was lucky, I could have been unlucky. Version 1.5c will save the old version of the list as "listname OLDLIST" and there will be a (OLD option to the GET command to retrieve it if needs arise. I could have done a GET EARNTECH (OLD to get back a copy of the old list. 2) Issuing a GET, HOLD and FREE to the seven LSTSRV-L peers is a pain. I'll im- plement a (GLOBAL option to these commands. Ditto for DELETE. 3) It's a pain to have lists come in with a filetype of list. As you may know I had fought off a suggestion that the filetype be set to 'nodeid' because I intended to have all servers know about ALL the recipients of the list, ie a "listname LIST" and "listname RMTLIST". That would have solved the REView problem and also the send=private issue. I was discouraged by the number of people who logon to the LISTSERV userid to modify their lists (I'm the first to do it by the way :-) ), thereby thwarting any attempt at informing other servers of the change :-( Anyway, I've now opted for a filetype = nodeid on the REV/GET commands, except: - If there is no peers= keyword, the filetype will be LIST, quite logical- ly. Only one central list --> no need for nodeid. - If the command is GET and the GLOBAL option was not specified, the file- type will be LIST so that GET listname --> listname LIST and GET listna me (GLOBAL --> bunches of listname nodeid files. Also, LSVPUT has been improved: there is a new (LIST option which can be used in conjunction with the "listname nodeid" files: you just do a FLIST LSTSRV-L * (for example), then LSVPUT / (LIST, =,=,=,=,=, and the files get stored automatically at servernode = filetype. This already works and is compatible with 1.5b provided that you rename the lists manually. LSVPUT filename still stores filename LIST, of course. 4) Some servers run an obsolete version of the $DEFAULT MAILFORM. Version 1.5c will automatically RENAME MAILFORM --> OLDMFORM and NEWMFORM --> MAILFORM if $DEFAULT NEWMFORM is found on the disk. That should solve the problem. 5) Some servers still have a SAMPLE LIST (with myself as the owner usually). I'd recommend you did a TELL LISTSERV CMS ERASE SAMPLE LIST. Not that this list causes problems or anything. I'm just getting questions from user that "Why is such a widely-spread distribution list not accessible to subscrip- tion, and why does it reports it as not operational?" :-) To answer a question from many of you: file LISTSERV NAMES is not needed at all unless you want to define your own nicknames in the LISTSERV userid, of course. I'm not responsible for the stupidity of NAMEFIND which complains when you do a mere NAMEFIND (SIZE * to set up the default size of the file buffer. About the security memo: I've got a lot of requests from US people. I realized that the mailing fee was much more important than I thought yesterday... I don't mind paying 15*$1 for European users, but 10*$5 is something different (especially since I wouldn't be surprised to get more requests during the week)... I'll be delaying the US mailings until I find a solution: either mail them low priority or get permission from FRECP11 to send them through the school mailing service or suchlike. I'm not a millionaire!! Eric