The numerous copies of the same mail item from BROWNVM that you have all received are neither a mailing loop nor a LISTSERV bug but, "simply", a broken RSCS somewhere between BROWNVM and POLYGRAF sending 150 copies of the same file to the list (the 'Date:' field and the 'Received:' tag generated by the BROWNVM mailer are identical on all the messages). This all happened while I was in Amsterdam for the EARN-RPG meeting, ie one week ago; the reason European subscribers might still be getting messages now is the huge DISTRIBUTE backlog in the north of France. Please stop giving phone calls; these are old files and doing a RDRLIST on 6000 files, examining all the ones called LSTSRV-L to selectively discard maybe 50 of them (assuming that many are left) is not something I can demand of the FRULM11 staff, which is already busy doing its best to keep the machine up and handle the gripes from local users. A few more messages might have been distributed today as I have released the US peers of LSTSRV-L in order to have my note about HIPER 16E-002O processed; we can't have the list on hold forever due to maybe 5-10 more junk messages floating around, especially with LSTSRV-M rendered useless for practical purposes by the french backlog (which was, by the way, due to a series of 30,000 records files sent at high priority over the 9600 BSC line early this week or last weekend, followed by a line monitor failure at FRORS12 - that's about all the info I have and I gave you all the details I know). Unless a european site can volunteer, there is no alternative to FRULM11 at the moment - certainly not CEARN, which can't even process the jobs from the FRULM11 server at the rate it sends them, viz 9600bps/2 (they pile up at CEARN until the FRULM11 server goes offline). On the bright side, the 9600bps line in question is expected to be upgraded to 64k/VMNET in october or november, which should solve the problem. Just in case I might find a volunteer after all (if only for the summer): the requirements are more than 9600bps of available bandwidth to FRMOP22 (obviously if the existing traffic already creates backlogs, you don't want to add all the european DISTRIBUTE load!) over a non-volume-charged line, 5000 or more available spoolids for LISTSERV+RSCS, enough CPU time to handle the load (0.25 to 0.5 "370 MIP") and either release 1.6 or skilled operators to look after the server 7 days, stopping loops and recovering failed jobs (my experience with LISTSERV@CEARN is that it crashes 2-4 times a day and goes into a loop once every 1-2 weeks - if you are particularly unlucky, the loop with fill up the spool by writing to the console log before you discover and stop it). Eric