>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