On 19.12.2012, at 0.24, Ben Morrow <ben@morrow.me.uk> wrote:

...

Also there are already "deny" and "pass" settings. Interaction with them can be somewhat confusing.. Maybe all of these should be replaced with:

type=deny: Same as old deny=yes (deny auth if user is in list) type=precondition(?): Same as pass=yes (require another passdb to match) type=postcondition(?): Require user to exist in this passdb/userdb as well, adding any extra fields in it. type=add: Add any extra fields, if the user exists at all.

This sounds like the nsswitch.conf [notfound=continue] stuff, perhaps you could use those names?

Status success entry found notfound entry definitely not found tryagain database temporarily unavailable unavail database not responding (an error of some kind)

I wonder what's the difference between tryagain and unavail. Sounds like the same thing to me.

Action return return the current result continue try the next db and accumulate fields

with defaults of

success = return notfound = continue tryagain = continue unavail = continue

You could potentially add other actions, like 'retry' which waits a bit and retries. Some sort of 'tempfail' action, which returns temporary failure to the client, would be good, but I don't think IMAP supports that, unless you just drop the connection and assume the client will reconnect and retry.

Hmm. I guess this would work, with defaults:

passdb { skip = never success = return-ok notfound = continue unavail = continue }

The possible values for skip:

• never: always do this passdb lookup
• authenticated: skip if user is already authenticated by a previous passdb
• unauthenticated: skip if user isn't authenticated

The possible values for success/notfound/unavail:

• return, return-ok, return-fail
• continue, continue-ok, continue-fail

where return/continue preserves the success-status without changing it, while the -ok and -fail variants change the success-status. The default status is fail, only return-ok / continue-ok changes that.

So:

• deny=yes would be success=return-fail.

• pass=yes would be success=continue (or continue-fail, but usually that would be the same)

• Two passdbs, second one adding extra fields:

a) require user to be in both: passdb { success = continue }, passdb { skip = unauthenticated } b) don't require user in the second: passdb { success = continue-ok }, passdb { skip = unauthenticated }

• 3 passdbs, with first two authenticating and last one adding extra fields:

passdb { success = continue }, passdb { success = continue skip = authenticated }, passdb { skip = unauthenticated }

I think you can do pretty much any wanted combination with these. Also. I think result_ prefix would be good, too lazy to update the rest of the mail now. So result_success, result_notfound and result_unavail.

At 3PM +0200 on 30/01/13 you (Timo Sirainen) wrote:

On 19.12.2012, at 0.24, Ben Morrow <ben@morrow.me.uk> wrote:

...

This sounds like the nsswitch.conf [notfound=continue] stuff, perhaps you could use those names?

Status success entry found notfound entry definitely not found tryagain database temporarily unavailable unavail database not responding (an error of some kind)

I wonder what's the difference between tryagain and unavail. Sounds like the same thing to me.

I think it's intended to distinguish between temporary and permanent failures (like 400 and 500 SMTP errors), so for instance 'LDAP server not responding' would be tryagain, and 'LDAP server returned permission denied' would be unavail. The difference would only be useful if Dovecot was going to retry in some cases, or could return a 'temporary failure' indication to the client.

Hmm. I guess this would work, with defaults:

passdb { skip = never success = return-ok notfound = continue unavail = continue }

The possible values for skip:

• never: always do this passdb lookup
• authenticated: skip if user is already authenticated by a previous passdb
• unauthenticated: skip if user isn't authenticated

The possible values for success/notfound/unavail:

• return, return-ok, return-fail
• continue, continue-ok, continue-fail

where return/continue preserves the success-status without changing it, while the -ok and -fail variants change the success-status. The default status is fail, only return-ok / continue-ok changes that.

So:

• deny=yes would be success=return-fail.

• pass=yes would be success=continue (or continue-fail, but usually that would be the same)

• Two passdbs, second one adding extra fields:

a) require user to be in both: passdb { success = continue }, passdb { skip = unauthenticated } b) don't require user in the second: passdb { success = continue-ok }, passdb { skip = unauthenticated }

• 3 passdbs, with first two authenticating and last one adding extra fields:

passdb { success = continue }, passdb { success = continue skip = authenticated }, passdb { skip = unauthenticated }

I think you can do pretty much any wanted combination with these. Also. I think result_ prefix would be good, too lazy to update the rest of the mail now. So result_success, result_notfound and result_unavail.

Looks good to me.

Ben