18

I have Dovecot v2.0.11 installed on a FreeBSD server and the user lookups for incoming email addresses are failing, but lookups for system users is successful.

Dovecot is setup to use system users, so my dovecot.conf has

 userdb {
  driver = passwd
}

and

passdb {
  driver = passwd
}

I have auth debug enabled.

For example, I have a user called webmaster, and using doveadm user for "webmaster" works as follows:

#doveadm user webmaster
userdb: webmaster
  system_groups_user: webmaster
  uid       : 1020
  gid       : 1020
  home      : /home/webmaster

However using doveadm user to lookup [email protected] fails as follows:

# doveadm user [email protected]
userdb lookup: user [email protected] doesn't exist

This is resulting in incoming mail for [email protected] to bounce with an "unknown user" error.

Here's the failure logged in /var/log/maillog:

Apr 16 20:13:35 www dovecot: auth: passwd([email protected]): unknown user

Here's the failure logged in /var/log/debug.log:

Apr 16 20:13:35 www dovecot: auth: Debug: master in: USER       1       [email protected]  service=doveadm
Apr 16 20:13:35 www dovecot: auth: Debug: passwd([email protected]): lookup
Apr 16 20:13:35 www dovecot: auth: Debug: master out: NOTFOUND  1

The users and their home directories were imported from another server and the users were setup using the vipw tool. I'm sure there's someting I missed on the import that's not "linking" the system user with the dovecot lookup.

Any ideas about what that something may be?

EDIT: Using BillThor's advice, I updated dovecot.conf as follows:

#doveconf -n passdb userdb
passdb {
  args = username_format=%n
  driver = passwd
}
userdb {
  args = username_format=%n
  driver = passwd
}

However, now, doveadm user fails in a different fashion:

#doveadm user [email protected]
doveadm(root): Error: userdb lookup([email protected]): Disconnected unexpectedly
doveadm(root): Fatal: userdb lookup failed for [email protected]

And, it no longer works for users without a domain:

#doveadm user webmaster
doveadm(root): Error: userdb lookup(webmaster): Disconnected unexpectedly
doveadm(root): Fatal: userdb lookup failed for webmaster

When I get the above messages, the following is in /var/log/maillog:

Apr 17 17:30:02 www dovecot: auth: Fatal: passdb passwd: Unknown setting: username_format=%u
Apr 17 17:30:02 www dovecot: master: Error: service(auth): command startup failed, throttling
Improve this question

5 Answers 5

Reset to default
19

Userids in dovecot using passdb don't include the domain. The userid the user should use is the local part, not the full email address.

The checks that are passing and failing are working as expected. Setting auth_username_format=%n before the password db definition does work. The domain is not validated though.

Improve this answer
2
  • Thank you for the reply, but that doesn't work, either. I've edited my question with the updated results.
    – cigarman
    Apr 17, 2011 at 17:05
  • 1
    @Coleman: Found a working solution for Dovecot 1.2. Should work for Dovecot 2 as well. See edit to my response. Found the solution in default configuration file for ubuntu.
    – BillThor
    Apr 17, 2011 at 17:44
16

I am using Ubuntu Server 12.04 and I tried the above solutions. However, I found that simplest and easiest way was in 10-auth.conf to set

auth_username_format = %n

I use PAM for the authentication which is the default in Ubuntu 12.04.

Improve this answer
1
  • Where in that file?
    – Jonathan
    May 14, 2021 at 18:27
4

auth_username_format = %n

breaks virtual domains on the same server, better idea is to use a conditional ( should work since 2.2.33 )

(see: https://doc.dovecot.org/configuration_manual/config_file/config_variables/ )

i'm using:

auth_username_format=%{if;%d;eq;hostname.startdedicated.de;%Ln;%Lu}

which is working fine. However you can use %n instead %Ln and %u instead %Lu, if you are using usernames in uppercase or uppercase/lowercase mix. change hostname.startdedicated.de to fqdn-hostname of your server.

Improve this answer
2
  • You are my hero!! At least for today :). I literally spent five hair-pulling hours trying to get virtual users to co-exist alongside system users before I stumbled upon your answer. Thank you!!!
    – Mark Olbert
    Mar 26, 2022 at 17:14
  • Thank you so much! Worked for me. I wonder how this situation was handled before this feature was implemented? Address re-writing perhaps? Also the dovecot config section with info on conditionals is quite hidden!
    – krm
    Oct 28, 2022 at 13:34
3

I suspect that Dovecot 2.1 either broke this solution or has changed the expected behavior.

I've traced the same authorization error to the userdb:

userdb {
  driver = passwd
}

When a local user (non-virtual) receives an email via exim->lmtp it includes the domain. Defining auth_username_format=%Ln does fix local delivery, but it breaks virtual deliveries. The offered fix of adding args = username_format seems to be ignored:

userdb {
  driver = passwd
  args = username_format=%n
}

and the logs include a warning 

Apr  4 11:24:57 moe dovecot: auth: Warning: userdb passwd: Move templates args to override_fields setting

Interestingly, using passwd-file does work, but auth is mad that the passwd file is owned by root.

userdb {
  driver = passwd-file
  args = username_format=%n /etc/passwd
}

Apr  4 11:26:12 moe dovecot: auth: Error: passwd-file /etc/passwd: User root has invalid UID '0'
Apr  4 11:26:12 moe dovecot: auth-worker(6855): Error: passwd-file /etc/passwd: User root has invalid UID '0'
Improve this answer
1

passwd-file: Unknown setting: username_format For me the reason was extra space:

passdb {
  driver = passwd-file
  args = scheme=SHA256-CRYPT **extra-space-here**username_format=%u /etc/dovecot/users
}

i.e. I had two spaces between CRYPT and uesrname.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .