Marc Dirix wrote: >> >> login,sock_allow,userid >> userA,inet:10.0.0.1:110,[EMAIL PROTECTED] >> userB,inet:10.0.0.1:110,[EMAIL PROTECTED] >> userC,inet:10.0.0.1:110,[EMAIL PROTECTED] >> >> that way your users can login with both userA, and with [EMAIL PROTECTED] >> > > Does this work with 100.000 accounts per domain?
Of course, why not? But I get your point. One way to solve this would be to fall back to the login as-is if the mapped userid fails to authenticate, or the other way around. Consider: login,userid ANY,[EMAIL PROTECTED] We could then first try the mapped value, and if fails fall back to the non-mapped login, Or, we could first try the non-mapped login, and if that fails try the mapped value. scenario 1a) try mapped: userA -> [EMAIL PROTECTED] -> success scenario 1b) try mapped: [EMAIL PROTECTED] -> [EMAIL PROTECTED]@foo.com -> fails try as-is: [EMAIL PROTECTED] -> success scenario 2a) try as-is: userA -> fails try mapped: userA -> [EMAIL PROTECTED] -> succeeds scenario 2b) try as-is: [EMAIL PROTECTED] -> success In any cases however, the login must be rejected if the sock_deny matches. tricky stuff, but doable. -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl
