|Deletions are marked like this.||Additions are marked like this.|
|Line 5:||Line 5:|
|* login_user: Master passdb can use this to change the username. (v2.2.13+)|
|Line 39:||Line 40:|
Password database extra fields
The primary purpose of a password database lookup is to return the password for a given user. It may however also return other fields which are treated specially:
user: Change the username (eg. lowercase it).
- login_user: Master passdb can use this to change the username. (v2.2.13+)
allow_nets: Allow user to log in from only specified IPs.
proxy and proxy_maybe: Proxy the connection to another IMAP/POP3 server.
host: Send login referral to client.
nologin: User isn't actually allowed to log in even if the password matches, with optionally a different reason given as the authentication failure message.
nodelay: Don't delay reply to client in case of an authentication failure.
- nopassword: If you want to allow all passwords, use an empty password and this field.
The password database may also return fields prefixed with userdb_. These fields are only saved and used later as if they came from the user database's extra fields. Typically this is done only when using prefetch userdb.
Note that boolean fields are true always if the field exists. So nodelay, nodelay=yes, nodelay=no and nodelay=0 all mean that the nodelay field is true. With SQL the field is considered to be non-existent if its value is NULL.
password_query = SELECT userid as user, password, 'Y' as proxy, host \ FROM users WHERE userid = '%u'
format is <ldap attribute 1>=<dovecot field 1>,<ldap attribute 2>=<dovecot field 2>,...
pass_attrs=uid=user, userPassword=password, someAttribute=proxy, hostName=host
Note about the "proxy" or "proxy_maybe" fields: these represent an existence test.
In LDAP, this translates to "will proxy (or proxy_maybe) if this attribute exists". This allows the proxy behaviour to be selectable per user. To have it "always" on, use a template, e.g.: