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