>P.S. Of cource I know that the  explanation of this phenomenon is just a
>little bug  in just  a little  file and that  it'll be  fixed in  just a
>little while.
 
Wrong, there is no bug. Everything works as designed. DEARN does not host
a 'REDIST-L' list, and therefore has  no idea about its service areas and
its exact  peers. However, it  knows that EB0UB011  does have one  of the
peers, and so  it forwards the request there (before  1.5n, it would just
have told you  that the list doesn't exist). Only  minimal information is
available when you do  not host a peer of a list,  for obvious disk space
considerations. EB0UB011,  in its  turn, knows that  the nearest  peer to
your  node is  DB0TUI11,  which is  perfectly true.  So  it forwards  the
request  there and  then, thanks  to  Thomas, your  request is  rejected.
EB0UB011 has no way to know that DB0TUI11 operates with crazy settings. A
peered  list  should  not  have   a  service  area,  as  subscribers  are
automatically  redistributed  across the  peers  in  an optimal  fashion.
Service areas are here only to prevent unwanted users from subscribing to
campus-wide local lists and suchlike. Not to redistribute subscriptions.
 
  Eric