On 09/08/17 15:19, Mike Brudenell via Exim-users wrote: > - Supply a valid username and valid password: Authentication succeeds > - Supply a valid username and invalid password: Authentication fails > with "535 Incorrect authentication data" > - Supply an invalid username and a password: Authentication fails with > "435 Unable to authenticate at present"
> But with the third the log shows > > failed to bind the LDAP connection to server ldap.york.ac.uk:389 - LDAP > error 32: No such object > > This does cause an expansion error which then, as documented, causes > server_condition to instead defer with the 435 SMTP response. For this the > LDAP error is "LDAP error 32: No such object" > > Maybe the latter isn't being handled properly and so causing the expansion > failure rather than returning a false failure? It's explicitly how it's coded. > From a security point of view, surely it's not good to return different > responses if the username exists/doesn't exist? It gives an attacker a way > of discovering what usernames actually exist so can then focus on their > password. (cf. The "Invalid username or password" generic login failure > messages.) You could argue that it's a specification, or design, bug. I'm not sure we'd want to change how it works though, at least as default. Possibly an option for different behaviour. Possible workaround, then: check explicitly for a valid username before checking the password? (It is possible to code a test for a "defer" explicitly in ACLs, but it's a trifle complex. If you prefer that route, ask and I'll look it up) -- Cheers, Jeremy -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/