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 ....