Software: Apache/2.2.22 (Debian). PHP/5.6.36 

uname -a: Linux h05.hvosting.ua 4.9.110-amd64 #3 SMP Sun Nov 4 16:27:09 UTC 2018 x86_64 

uid=1389(h33678) gid=1099(h33678) groups=1099(h33678),502(mgrsecure) 

Safe-mode: OFF (not secure)

/usr/share/doc/dovecot-core/wiki/   drwxr-xr-x
Free 1.48 GB of 7.22 GB (20.44%)
                            Encoder    Tools    Proc.    FTP brute    Sec.    SQL    PHP-code    Update    Feedback    Self remove    Logout    

Viewing file:     PasswordDatabase.ExtraFields.txt (3.21 KB)      -rw-r--r--

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)