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