Ok, let's consider the situation in technical terms.
 
A piece of mail is basically a header plus a body. When LISTSERV sends mail to
a peer list, it  adds special tags to the header. These tags  do not appear on
mail sent to non-peer subscribers. However,  the header is still there, and if
this non-peer subscriber  happens to be a  list, it can still  know the actual
origin of the mailfile etc.
 
A file is basically a body without header, but with a small tag attached to it
telling  you the  address of  the  sender. When  LISTSERV  sends a  file to  a
backbone  LISTSERV, it  creates  a kind  of  "header" (ie  the  DIST crap)  to
identify the  file origin and  destination. When the file  is sent to  a final
user, this crap is removed and only the body is sent. The little tag points to
the LISTSERV  userid, not the original  sender. If this final  subscriber is a
list, it  is in  deep trouble. The  NJE address is  a LISTSERV  machine, which
indicates that this  file doesn't come from  a user but from  some list (which
one?? No way to know). If the list is not peered, there is no problem since it
cannot point back  to the original list (whatever that  original list may be),
so  the file  can be  distributed  normally. Now  if  the list  is peered,  it
probably points back to the original list and a loop will occur if the file is
redistributed. This is what caused the dreaded DIST2 loop, and what caused the
duplicata on NODUPD-D. Note that the file will always be sent with DIST header
if the destination node's LISTSERV is on  the backbone, in which case there is
no problem. The DIST2 loop stemmed from  the fact that UIUCVMD is on the DIST1
backbone but not on the DIST2 one.
 
Solutions:
 
1. Rule out that non-backbone sites are  not allowed to get peer lists, unless
   these lists  have "Files=  NO" in effect.  You seem to  think that  this is
   unacceptable, so let's forget about it.
 
2. Rule out that non-backbone sites  are forced to accept DISTRIBUTE jobs that
   contain  ONLY recipients  for their  own site.  This makes  it possible  to
   always send  a DIST  job and  solves the  problem PROVIDED  THE DESTINATION
   NODE'S LISTSERV  IS REGISTERED. I'm  afraid people who want  DISTRIBUTE off
   want it all the  time, but maybe they could concede that  if there are only
   local recipients...
 
3. Force a DIRECT send of the  file to the destination site if the destination
   userid is a peer list and the  destination LISTSERV is not on the backbone.
   Then  the NJE  address can  be inspected  to "cut  off the  source branch".
   You're going to have a loop if the peers are improperly linked.
 
Note  that besides  the loop  problem, you  are in  trouble if  INFORM=MAIL is
specified by the file sender. In that  case, if the destination list is not on
the backbone,  it's going  to get  a raw copy  of the  file plus  the standard
notification mail. If it is in the backbone, DISTRIBUTE will not actually send
anything to the list userid so it will be ok.
 
Comments?
 
  Eric