it looks like Dovecot is now trying to authenticate against the local password and not lldap.

That is what the default ACCOUNT_PROVISIONER=FILE is meant to do. For LDAP you would set ACCOUNT_PROVISIONER=LDAP.

Just to clarify, DMS supports only file based account config or LDAP based, we don't have both. LDAP is community contributed so support for that is limited.

You are using LDAP for your accounts, so I am not sure why you used setup CLI to create/manage a user, perhaps you assumed it to integrate with LDAP?

You should instead manually create your desired account ([email protected]) via lldap like you would have for any other users there without DMS involved. Is there a reason you would expect DMS to support the file based account and LDAP at the same time, a reason why adding this user to your LDAP service is not preferred?

Crossed wires I think. Let me try to clarify.

I had some existing mailboxes that were provisioned natively in mailserver via the ./setup.sh before I integrated ldap. These failed when I added the ldap config, presumably due to the ENABLE_QUOTAS feature which hadn't been disabled. As part of an attempt to troubleshoot that issue, I tried to list the email accounts using the email list command - at which point I saw the errors. I misinterpreted your message as meaning that provisioning accounts from ldap was not supported, which is why I modified the ACCOUNT_PROVISIONER variable, mistakenly thinking this would mean accounts were provisioned from file, but authenticated by ldap.

I have alterned my config now so that ACCOUNT_PROVISIONER=LDAP, but ENABLE_QUOTAS=0.

Sorry for any confusion.

They should fail in the sense of changing provisioner via ACCOUNT_PROVISIONER ENV. DMS will either configure for the file accounts or LDAP accounts.

The old accounts mailboxes in /var/mail should still be there, but the configuration with LDAP might be slightly different that it doesn't quite match the expected path in /var/mail, assuming you recreated the accounts in LDAP.

Really sorry to come back to you again, but have been attempting to troubleshoot an issue all day without resolution. Still related to LDAP.

Users accounts have been authentication against LDAP and have been able to send and receive messages. The last user message was received at 10.14 this morning - but nothing since. No configuration changes were made other than to set up another application (Dolibarr) as an SMPT client.

I did notice I was getting a tonne of suspicious looking connection attempts with different - non-existing email addresses on my domain, so I enabled FAIL2BAN - but this was AFTER the mail failure.

The messages is the logs are:

2025-04-28T19:43:14.094370+02:00 mail dovecot: imap(1471): Error: Couldn't drop privileges: User is missing UID (see mail_uid setting)

Recipient address rejected: User unknown in virtual mailbox table.

I have tried adding user-defined attributes to my user schema in lldap, but I still get the same errors.

If I do an ldap query though, I can see....

# extended LDIF
#
# LDAPv3
# base <ou=people,dc=recognition-circular,dc=org> with scope subtree
# filter: ([email protected])
# requesting: uidNumber gidNumber mailuidnumber mailgidnumber 
#

# [email protected], people, recognition-circular.org
dn: [email protected],ou=people,dc=recognition-circular,dc=or
 g
mailgidnumber: 5000
mailuidnumber: 5000

# search result
search: 2
result: 0 Success
control: 1.2.840.113556.1.4.319 false MAUCAQEEAA==
pagedresults: estimate=1 cookie=

# numResponses: 2
# numEntries: 1`

As far as I am aware, accounts should be managed by ldap - LDAP_PROVISIONER=LDAP

Thanks in advance for your help.

Presumably the user attributes config for Dovecot is not matching a user correctly with lldap when queried?

I unfortunately don't have the time to assist right now, LDAP support needs to be reworked (you can subscribe to this PR), and a demo config setup with revised LDAP docs. I just have not been able to allocate time for that yet, so if you want to use LDAP you're mostly on your own for now.

AFAIK our test suite as a basic LDAP integration test that is known to work with OpenLDAP:

• Config files
• Test file with Bitnami OpenLDAP image

The lldap project has a DMS example too IIRC.

There is also the open issues tagged for LDAP support, closed issues may also have some insights that may assist you from past discussions.

Generally my advice for issues like this is to really focus on minimal/simple config, just get a working DMS setup and go from there. Avoiding extra features like Fail2Ban to rule out any interference.

Another tip is to backup your data and temporarily use new volumes to reset the state (be sure to recreate the container as per our troubleshooting/debugging docs page describes). This can usually provide a clean slate that you can at least confirm a working setup and attempt to reproduce the set of commands/config where the breakage is introduced, which is actually useful/helpful (to either fix a bug, or improve our docs for others running into the problem).