Oh my... the loop phantom again. Seriously, folks... LSTSRV-L has 8 peers or
so, and has been having them for a very long period of time. To the best of my
knowledge it  has never looped,  even when the  UIUCVMD server went  crazy and
started  sending copies  to all  the peers  instead of  only to  the neighbour
peers.
 
  I  have however  noticed  several mailing  loops  on other  sub-distribution
lists, especially when using the  Send= Editor feature. Peer-linking inserts a
set of control fields in the mail header, which include a complete list of all
the servers that processed the mailfile.  If "I" processed it already, it goes
to the postmaster ASAP. You don't have this facility with non-peer lists.
 
  And how does DISTRIBUTE  do? First, as long as there will  be servers < 1.5g
the DISTRIBUTE  backbone will be in  danger. The older releases  do not accept
jobs from  LISTSERVs not  officially registered  in PEERS  NAMES, and  I can't
register new servers on them because of the 60 entries limit. If they detect a
problem with a  DISTRIBUTE job, it gets trashed. And  they trash the anti-loop
information generated  by 1.5g and  above if they find  it in the  job stream.
With  peers  you  don't  have  to  worry  about  going  through  your  dreaded
neighbour's 1.5b server (unless of course you want to peer with him :-) ).
 
  DISTRIBUTE does have an anti-loop protocol, but it is defeated in one of the
following two cases:
 
1) A server  < 1.5g trashes the  "went through" control record.  In 1.5j, I'll
   consider all  servers <  1.5g as  NOT supporting  DISTRIBUTE. Jobs  will no
   longer be sent  to them, even if it  means 10 extra nodes. I'm  fed up with
   1.5d/1.5f DISTRIBUTE rejections.
 
2) If there are more than 255 bytes  of "went through" info. Yes, when I wrote
   the  code  I  had  forgotten   about  this  *stupid*  GLOBALV  restriction.
   Fortunately it  can easily be  removed while keeping  upward compatibility,
   but here again 'old' servers will trash part  of the info (ie if 2 lines of
   info are generated, they will transmit only 1).
 
  I'll  try to  design a  'pass-through' protocol  to allow  'old' servers  to
propagate fields  generated by more  recent versions,  even if they  don't use
them -- they'll just pass on whatever they're asked to. The problem is that it
is much more  difficult to implement that  on CJLI where you have  no "list of
DDnames" and you have  the "!%$!$+% 255 chars limit, than  on RFC822 where the
header is straightforward and you have no size limit. But it will be done. The
problem is that it will take 2 more months for everybody to install it ;-(
 
  Eric