On 12/29/2011 12:23 PM, Gedalya wrote:> Hello,
>
> I'm using proxy_maybe and auth_default_realm. It seems that when a
> user logs in without the domain name, relying on auth_default_realm,
> and the "host" field points to the local server, I get the
Proxying
> loops to itself error. It does work as expected - log on to the local
> server without proxying, if the user does include the domain name in
> the login.
>
> (IP's and domain name masked below)
>
> No domain:
>
> Dec 29 11:49:07 imap01 dovecot: pop3-login: Error: Proxying loops to
> itself: user=<jedi at ----.com>, method=PLAIN, rip=00.00.52.18,
> lip=00.00.241.140
> Dec 29 11:49:27 imap01 dovecot: pop3-login: Disconnected (auth failed,
> 1 attempts): user=<jedi at ----.com>, method=PLAIN, rip=00.00.52.18,
> lip=00.00.241.140
>
> With domain:
>
> Dec 29 11:52:13 imap01 dovecot: pop3-login: Login:
> user=<jedi at ---.com>, method=PLAIN, rip=00.00.52.18,
lip=00.00.241.140,
> mpid=19969
> Dec 29 11:52:18 imap01 dovecot: pop3(jedi at ---.com): Disconnected:
> Logged out top=0/0, retr=0/0, del=0/1, size=731
>
> Otherwise, e.g. when the proxy host is indeed another host,
> auth_default_domain works fine, including or not including the domain
> seems to make no difference, and everything works.
>
> I'm using mysql, and I'm able to get around this problem including
the
> following in the password query:
> IF(host='' or host='00.00.241.140', NULL, 'Y') as
proxy_maybe
>
> # dovecot --version
> 2.0.15
>
> # dovecot -n
> # 2.0.15: /etc/dovecot/dovecot.conf
> # OS: Linux 2.6.32-5-amd64 x86_64 Debian 6.0.3
> auth_default_realm = ----.com
> auth_mechanisms = plain login cram-md5 ntlm
> auth_username_format = %Lu
> auth_verbose = yes
> auth_verbose_passwords = plain
> dict {
> quota = mysql:/etc/dovecot/dovecot-dict-sql.conf.ext
> }
> disable_plaintext_auth = no
> login_greeting = How can I help you?
> mail_gid = vmail
> mail_uid = vmail
> passdb {
> args = /etc/dovecot/dovecot-sql.conf.ext
> driver = sql
> }
> protocols = imap pop3 lmtp
> service lmtp {
> inet_listener lmtp {
> address = 0.0.0.0
> port = 7025
> }
> }
> ssl_cert = </etc/ssl/certs/dovecot.pem
> ssl_key = </etc/ssl/private/dovecot.pem
> userdb {
> driver = prefetch
> }
> userdb {
> args = /etc/dovecot/dovecot-sql.conf.ext
> driver = sql
> }
> verbose_proctitle = yes
>
> ----- dovecot-sql.conf.ext ----
> driver = mysql
> connect = host=localhost dbname=email user=email
> default_pass_scheme = PLAIN
> password_query = SELECT password, \
> IF('%s' = 'pop3', host_pop3, host) as host, \
> IF(host='' or host='00.00.241.140', NULL, 'Y') as
proxy_maybe, \
> concat(userid, '@', domain) as destuser, \
> password as pass, \
> '/stor/mail/domains/%d/%n' AS userdb_home, \
> 'maildir:/stor/mail/domains/%d/%n/Maildir' as userdb_mail, \
> concat('*:storage=', quota_mb, 'M') as userdb_quota_rule,
\
> 'vmail' AS userdb_uid, 'vmail' AS userdb_gid \
> FROM email WHERE userid = '%n' AND domain = '%d'
> user_query = SELECT '/stor/mail/domains/%d/%n' AS home, \
> 'maildir:/stor/mail/domains/%d/%n/Maildir' as mail, \
> concat('*:storage=', quota_mb, 'M') as quota_rule, \
> 'vmail' AS uid, 'vmail' AS gid \
> FROM email WHERE userid = '%n' AND domain = '%d'
>
>
OK, it turns out the problem went away when I removed the destuser field
from the password query - it turned out to be unnecessary anyhow.
My requirements are to allow users to log in using non-plaintext
mechanisms such as CRAM-MD5, while my IMAP backends are non-dovecot and
do not have a master user feature. Passwords are stored in the database
in plaintext and presumably what I need to do is fetch the plaintext
password from the database and simply use the user's own username and
password when logging in to the backend. The wiki page on this subject
only discusses a master-user setup, and my misunderstanding of that page
lead me to think I need the destuser field. This turns out to be a
simple setup, the only field involved being the "pass" field, and
should
probably be documented on the wiki.
Either way, proxy_maybe doesn't work with auth_default_realm and
destuser, even if destuser ends up containing the exact same username
that would be constructed by auth_default_realm.