'director_tag' field returned from passdb lookup results in 'unknown passdb extra field'

[Dan]

Hello all,


I'm working with director in tandem with 'director_tags' to group some 
backend hosts. I've assigned the groups to the hosts by appending a '@' 
character after the IP address of a backend host under 
director_mail_servers:

...

director_mail_servers = 192.168.0.1 at foo 192.168.0.2 at bar 192.168.0.3 at foobar

...

I can confirm that the backend hosts possess the correct tags by issuing:

# doveadm director status
mail server ip   tag    vhosts state state changed users
192.168.0.1  foo    100    up    -             0
192.168.0.2  bar    100    up    -             0
192.168.0.3  foobar 100    up    -             0


And examining that the tags have been assigned correctly.

My passdb lookup is using mysql, and it appears as such:

passdb {
   args = /etc/dovecot/dovecot-sql.conf
   driver = sql
}

This file looks like:

driver = mysql
connect = host=localhost dbname=xxx user=xxx password=xxx
password_query = select director_tag, username, domain, password, 'Y' as 
`proxy` from users where username = '%n' and domain = '%d'
iterate_query = select director_tag, username, domain from users


I have a database that contains the following columns:

username, domain, password, home, UID, GID, active, and director_tag


To assign users to a backend, I went off of the documentation that states:

 > " A passdb lookup can return "director_tag" field containing the 
wanted tag name. "

To fulfill this, I return the 'director_tag' in the passdb lookup, 
through password_query.

The mapping seems to work. When I change the row in the database, the 
user gets proxied to the new backend on the next connection.

However, My question is, Why does this appear in the logs?

"dovecot[1963]: imap-login: Debug: Ignoring unknown passdb extra field: 
director_tag"

How could this be an unknown passdb extra field, when the documentation 
states that you may return a field containing this key?

In the file core/src/login-common/client-common-auth.c - Starting at 
line 142, there is no if condition checking for 'director_tag'. This 
causes that line to be output to debug handle.

Is this intentional?


Thank you for your time.



Full configuration:

auth_debug = yes
auth_debug_passwords = yes
auth_mechanisms = plain login
auth_verbose = yes
auth_verbose_passwords = yes
director_mail_servers = 192.168.0.1 at foo 192.168.0.2 at bar 192.168.0.3 at foobar
director_servers = x.x.x.x y.y.y.y
director_user_expire = 5 mins
disable_plaintext_auth = no
doveadm_port = 24245
haproxy_trusted_networks = x.x.x.x y.y.y.y 127.0.0.1
login_greeting = Dovecot At Your Service
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope 
encoded-character vacation subaddress comparator-i;ascii-numeric 
relational regex imap4flags copy include variables body enotify 
environment mailbox date index ihave duplicate mime foreverypart extracttext
passdb {
   args = /etc/dovecot/dovecot-sql.conf
   driver = sql
}
protocols = imap pop3
service director {
   fifo_listener login/proxy-notify {
     mode = 0666
     user = $default_login_user
   }
   inet_listener {
     port = 9090
   }
   unix_listener director-userdb {
     mode = 0600
   }
   unix_listener login/director {
     mode = 0666
   }
}
service imap-login {
   executable = imap-login director
   inet_listener imap {
     haproxy = yes
     port = 143
   }
   inet_listener imaps {
     haproxy = yes
     port = 993
     ssl = yes
   }
}
service ipc {
   unix_listener ipc {
     user = dovecot
   }
}
service pop3-login {
   executable = pop3-login director
   inet_listener pop3 {
     haproxy = yes
     port = 110
   }
   inet_listener pop3s {
     haproxy = yes
     port = 995
     ssl = yes
   }
}
ssl_cert = </etc/dovecot/private/dovecot.pem
ssl_dh = # hidden, use -P to show it
ssl_key = # hidden, use -P to show it
userdb {
   args = /etc/dovecot/dovecot-sql.conf
   driver = sql
}
protocol doveadm {
   auth_socket_path = director-userdb
}