ok, ok... I never said I was not going to implement any service area, my point was just that service areas are STATIC and should therefore be used only when links-distance is not sufficient... A few changes: 1) The notification letter for SUBSCRIBE is now sent to owners cc: newguy. 2) You can now indicate a specific listname in "Peers=", eg: Peers= EB0UB011,CLVM,DEARN,MD40@CMUCCVMA,CLVM 3) You now have an optional "Service=" keyword. Format is "Service= s1<,s2<,s3> >>", with each of the si being either a country name, a node name, "xxx*", "*yyy" or "xxx*yyy". 4) MOVE, ADD, SUBSCRIBE, EXPLODE, support items (2) and (3), untested. However, service areas don't work as you might intuitevely except it. Let me describe how they work and I'll explain why later. a) If the guy is not from BITNET, a search is done in DOMAIN NAMES to find the gateway's node. If not found, *sigh* peers are disregarded. b) If we have peers, and if there is a peer nearer than us, then the request gets forwarded to that peer. Service areas are ignored. c) Now service area, if any, is checked, and the request is denied if the guy is outside our service area. Hold on your flame a little while: 1) My experience of relay shows that: a) Having a SYNCHED service area file for each list on all the servers is impossible. You will always have at least one peer which will install the new file one week after everybody. In the meanwhile... :-( b) Maintaining a serious service area is just IMPOSSIBLE. Because of the unexisting naming conventions on BITNET, it is not possible to name, say, "BN*" to get all the Namur nodes. You'd catch BNL and BNLDAG too, and those are in the states. A comprehensive listing would take about 10 lines of node names, to be maintained every time the master nodes file is updated. Not to mention the havoc when a new peer is added in the vicinity. 2) Therefore the suggested modus operandi is the following: a) Local-node-only lists set "Service= Local", e basta. b) Local-institution lists set "Service= node1,node2..." or "xxxx*" (if at all possible) c) Other lists set "Service= country,country..." If there are several peers in the same country, no problem, the request will be forwarded to the nearest one. As I said before, I believe that a decent links weight file should route people correctly in 80% of cases, and is not a big problem to maintain because the same file is used in all the servers. 3) Another advantage: assume that postmaster D... at node F... is very lazy. He has a LISTSERV set with "Service= something*". Now YOU create a peer to this server, and realize that all your users get bumped to F... Not good... Espe- cially since D... never answers your mail, nor does he take time to change the list header, and of course he didn't give you privs on his list. In that case you'd be very happy to have service areas the way I defined them. I will of course try to avoid this kind of problems by not giving the listserv code to people who don't answer mail and suchlike, but you can always have a nasty surprise and there are also people I couldn't refuse to ship the code to if they asked for it. Eric