Sorry for x-posting ...
The recent problems with VM-UTIL "motivated" me to do some investigations. For
all who  don't know the  TREARN peer of VM-UTIL  will be un-peered  because of
problems with jo-jo'ed mailings (which  fortunately were rejected at the other
peer).
I  wont comment  on this  very problem.  All I  did was  sending some  RELEASE
commands to various  LISTxxRx's and invetigate some list  headers. Well, there
are at least 5 different kinds of listservers around:
LISTSERV 1.6e   - current LISTSERV release
LISTSERV 1.nx   - backlevel LISTSERVs
LISTEARN 1.1    - soon-to-come (?) LISTEARN release
LISTEARN 1.0    - current relase
LISTSERV 1.5o maintained by EARN
The reason why I'm  bringing this to your attention is that  not only the code
differs but  also the network-related  control files. The current  mixture can
indeed lead to funny results:
A subscription  request for a  peered list is in  the worst case  forwarded to
three different peers  depending on the LISTxxRx I chosse  to send the request
to. Whilst this problem is known to pop up in a transition phase (usually less
than one week) it is now a permanent one.
To give a more lively example:
AWIIMC11 is 1 node downstream  from AEARN. LISTSERV@AWIIMC11 (running LISTSERV
1.6e)  insists  that my  nearest  host  for  VMUTIL is  DEARN.  LISTSERV@AEARN
(running LISTEARN) is absolutely convinced  that TREARN is the best placement.
While  this  may  only  be  some insignificant  nuisance  keep  in  mind  that
DISTRIBUTE uses the same view of the network ....
 
Well, I  don't want to  start another  war but the  facts are that  this makes
(slowly  but  steady) peering  of  lists  where  LISTSERVs and  LISTEARNs  are
involved more  or less ridiculous -  EXPLODE will be a  two-step action, first
explode the list on - let's say - a LISTSERV and after the movement explode it
again on the target LISTEARNs or v.v.
'Nuff said for know ....
 
Christian