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