Oh, but that  is a bug in  the loop detection algorithm.  I had inadvertently
assumed that the *name* LISTSERV puts in the "Sender:" tag would NOT be trashed
by the mailer. Evidently I was wrong  as the UMASS mailer trashed everything to
only keep the USERID@NODE which LISTSERV was not able to recognize, unfortunate
ly. I'll fix that in the next release.
 
  The PUT  command for LINKSWT FILE  was successfully processed at  FRECP11 and
BNANDP11 but seems to have been trashed at CEARN, there is probably a bug some-
where. Well I  never tested this before...  Anyway I'll resend the  file in the
next shipment.
 
  Peter, what you suggest is not totally possible and/or can't completely solve
the problem. LISTSERV  will not send to  ALL peers but to the  nearest one, who
will forward to the nearest, etc. The first server will assign a LISTSERV node-
id to each of the recipients but keeps this information to itself: I was attemp
ting not to place any information that could be recreated later in the jobfile.
Well I could  change that. But still,  the nodes tables would have  to be used.
Let's  say  I  distribute  to X@CEARN,  X@DEARN,  [log in to unmask]  LISTSERV@FRECP11
assigns the recipients to CEARN, DEARN and HEARN respectively, and forwards the
file to CEARN. CEARN  knows that X@DEARN is serviced by  DEARN and X@HNYxxxx is
serviced by HEARN but must still use  its node table to determine that the file
should only be sent to DEARN who will forward it later then. It is not possible
nor desirable to prepare the complete  "path" in the original server. First, it
would take  an *awful* lot  of CPU time  and would take a  lot of space  in the
distributed job.  And second, the nodes  tables are more likely  to be accurate
near the  places where changes  have been made  than somewhere else.  Let's say
that tomorrow Israel  is unplugged from Italy and connected  to Germany. Tables
in the US will  probably be incorrect but you can expect  the DEARN and TAUNIVM
tables to have been updated.
 
  So, it  may help  the problem  to have the  first server  impose its  list of
"servers who will  serve this or that  person" but it's not  a PERFECT solution
and you may  still have a few problems.  A good solution is to  add some error-
recovery routines  which would  manage to  distribute the  file anyway,  with a
warning to the sender and postmaster though.
 
  Eric