There is (if I'm not mistaken) an inconsistency and/or a bug in the handling of the Service= keyword. Given the following list header: Confidential= Service Service= Austria a user with address [log in to unmask] can neither "see" this list nor subscribe to it, which seems perfectly normal. Now with the header Confidential= Service Service= Austria,*.AT the user gets this list on a LIST command but still can not subscribe. The reason is that in case of a SUBSCRIBE command the originators (domain) nodeid is replaced with the gateway's nodeid - therefore the pattern-matching fails while on the other hand the country of the domain-style address (default ???) is used for the "country"-match. Funny enough if the SUB-request comes via X-SUB the gateway resolution is bypassed and the above works (or - I think it works) provided the pattern is given. *-----* There is no simple solution to that as far as I can see (doesn't it require several months and a type-4 ...? oh, no politics, please). Maybe I'm missing something - as far as I can see the gateway resolution only works for finding the nearest peer to the gateway is not the LISTSERV receiving the request in the first place. Then the request is forwarded AND if the PATTERN for the domain is set in the "best" peer (i.e. if it has a Service= definition) the request is accepted. *-----* Correct me, Eric, if I'm wrong: there are two things in LSVBESTP: a) country and pattern matching to collect several nodes into an "area" b) finding the gateway to a domain AND taking the gateway node into account when checking for the Service-area (in other words if the gateway for the user is in the service-area then the user is considered to be in the area). But I'm not sure about case b) (- how can I restrict access to only a subdomain then ?). Christian P.S.: I know, I'm an EARN user ....