0

I have set up Postfix to use Dovecot SASL with PAM and Unix users, and Dovecot LDA (LMTP) for local mailbox storage. After some testing, turns out incoming mail gets declined with the reason:

Error: passdb lookup failed for [user]: Configured passdbs don't support credentials lookups

That's both troublesome and troubling - I opted for PAM-based authentication because all sources I found suggested it's the simplest and most reliable way. It's hard for me to troubleshoot what's going wrong at this moment - I'm not sure if it's truly an issue with PAM or if something's wrong with my configuration.

Logs

The doveadm lookup test:

$ doveadm auth lookup [user]
Error: passdb lookup failed for [user]: Configured passdbs don't support credentials lookups

Dovecot debug log after the lookup test:

$ cat /var/log/dovecot/dovecot-debug.log | tail -5
[date][time] auth: Debug: master in: PASS    1       [user]  service=doveadm debug
[date][time] auth: Debug: pam([user]): Performing passdb lookup
[date][time] auth: Debug: pam([user]): passdb doesn't support credential lookups
[date][time] auth: Debug: pam([user]): Finished passdb lookup
[date][time] auth: Debug: passdb out: FAIL   1       reason=Configured passdbs don't support credentials lookups

Relevant configuration

The /etc/dovecot/conf.d/10-auth.conf file:

auth_username_format = %Ln
auth_mechanisms = plain login
!include auth-system.conf.ext

The /etc/dovecot/conf.d/auth-system.conf.ext file:

passdb {
    driver = pam 
    args = session=yes failure_show_msg=yes dovecot
}
userdb {
    driver = static
    args = uid=vmail gid=vmail home=/var/vmail/%n
}

The /etc/pam.d/dovecot file is the default that came with the Rocky Linux (that equals RHEL and is the same as Fedora) Dovecot package:

#%PAM-1.0
auth       required     pam_nologin.so
auth       include      password-auth
account    include      password-auth
session    include      password-auth

However, I also tried the configuration as suggested by the official Dovecot PAM documentation and it didn't yield any different results. I am confident in the rest of my configuration, as I spent considerable time studying the options, but I still barely understand the PAM config...

All logs point at the issue being with the Dovecot SASL itself, not with the Postfix or Dovecot configuration. Any suggestions would be much appreciated.

3
  • PAM passdb driver just gives you a binary auth success/failure result, and your userdb does not help in identifying which users exist. What do you want to happen when a message comes in for [email protected]?
    – anx
    Apr 8, 2022 at 12:44
  • Preferably the "Undeliverable mail returned to sender" reply, but if I understand it correctly, that is a task for Postfix, not Dovecot. Dovecot just needs to validate whether this user exists on the machine via SASL and return the answer to Postfix. Authentication doesn't happen at this stage - but it needs to work for when users try to read their mailboxes over IMAP/POP3. Apr 8, 2022 at 18:41
  • 1
    (To be precise, even better: postfix when instructed to reject_unverified_recipient learns via LMTP that Dovecot could not find that user, and says so on the incoming connection. The responsibility of generating the return message is then upon the relay of the sender, meaning your setup does not need to generate backscatter.)
    – anx
    Apr 8, 2022 at 22:16

1 Answer 1

1

I have no idea if this is the proper solution to the problem (now coming back and reading anx's comment on my original post makes me wonder if it is), but I managed to get both the lookup and authentication working by adding a second passdb entry into the Dovecot's configuration.

In the Dovecot configuration, I preceded the PAM password database entry with a passwd password database entry:

# e.g. /etc/dovecot/conf.d/auth-system.conf.ext
passdb { # This is not a typo
         # Passwd can be used both as a passdb and a userdb
    driver = passwd
}
passdb {
    driver = pam
    args = dovecot
}

This makes user lookups with doveadm auth lookup [user] succeed. However, the passwd database can't authenticate users, as the passwords are no longer stored in the /etc/passwd file on Unix systems. When that happens, the lookup continues with the PAM password database, which correctly authenticates the user. This can be tested with the doveadm auth test [user] command.


I added this as an accepted answer, because the solution/workaround currently worked for me. If anyone has any suggestions or knows how this could be solved in a better way, I'm happy to accept it instead. With just the PAM database being the default configuration on Rocky Linux (practically RHEL), it makes me surprised it wouldn't work out of the box.

You must log in to answer this question.

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