1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
|
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> [PasswordDatabase.ExtraFields.User.txt]: Change the username (eg.
lowercase it).
* <allow_nets> [PasswordDatabase.ExtraFields.AllowNets.txt]: Allow user to log
in from only specified IPs.
* <proxy and proxy_maybe> [PasswordDatabase.ExtraFields.Proxy.txt]: Proxy the
connection to another IMAP/POP3 server.
* <host> [PasswordDatabase.ExtraFields.Host.txt]: Send login referral to
client.
* <nologin> [PasswordDatabase.ExtraFields.NoLogin.txt]: 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> [PasswordDatabase.ExtraFields.NoDelay.txt]: 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.
How to return these extra fields depends on the password database you use. See
the <password database> [PasswordDatabase.txt] pages on how to do it. Some
passdbs however don't support returning them at all, such as <PAM>
[PasswordDatabase.PAM.txt].
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>
[UserDatabase.txt]'s extra fields. Typically this is done only when using
<prefetch userdb> [UserDatabase.Prefetch.txt].
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.
Examples
--------
SQL
---
dovecot-sql.conf.ext:
---%<-------------------------------------------------------------------------
password_query = SELECT userid as user, password, 'Y' as proxy, host \
FROM users WHERE userid = '%u'
---%<-------------------------------------------------------------------------
LDAP
----
dovecot-ldap.conf
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.:
---%<-------------------------------------------------------------------------
pass_attrs=uid=user,userPassword=password,=proxy=y,hostName=host
---%<-------------------------------------------------------------------------
passwd-file
-----------
---%<-------------------------------------------------------------------------
user:{plain}pass::::::proxy=y host=127.0.0.1
---%<-------------------------------------------------------------------------
(This file was created from the wiki on 2013-11-24 04:42)
|
