>An advantage to this over peering was to not have to worry about peer linking >to the wrong list and possibly creating a loop. For one list reducing this >chance of error is nice, for 40 lists this is worthwhile. EB0UB011 has 67 lists, 44 of them public. Of the 44 public lists, 29 of them have one or more peers -- there are lists with 2 peers and lists with up to 15 peers, 3 peers beeing the average. I have *never* had a loop, expect when installing a list. Beeing an owner for other peers has helped me to stop loops when other node's postmasters were not at work -- note that, from that point of view, the probability of loops *decreases* when there are more peers: the time difference is an advantage here. >... The security aspect of peering is not favorable, it is >possible to create loops. Monday night Tony Dahbura, Harri Salminen and me were testing the new I-GRAPH and VLSICAD lists. Some misunderstandings lead us to create a peer structure which formed a neat loop: SUVM ---> FINHUTC ---> EB0UB011 ---> SUVM. Tony sent a test mail, and I received two copies: one directly from SUVM and another from FINHUTC. No more copies. I tried then from my side (my list mentioned both SUVM and FINHUTC as peers) and a while later I received a note from my LISTSERV saying : "Possible loop in the peer structure for list I-GRAPH"; the offending mail was transferred to my reader. I looked at it, and it had some inter-server tags. One of them (X-LSVVia I think) listed ALL THE PEERS in the path: since my note was sent from EB0UB011, then forwarded to SUVM, then FINHUTC and then back to EB0UB011, it looked something like X-LSVVia: VLSICAD@EB0UB011 VLSICAD@SUVM VLSICAD@FINHUTC EB0UB011 was immediately able to detect the loop with a single Find(lsvvia,myself) instruction. Conclusion: when Eric says that LISTSERV has very powerful loop-detection strctures, he's not lying :-) > With DISTRIBUTE only the contribution end is centralized, meaning, once the >job is relayed to the next node it doesn't matter if the central node is >down. Yes, but this does not address the point I mentioned: mailing activity is totally suspended if the central node is down. >--Judith Molka Jose Maria