I am using Stalwart with Kanidm as ldap directory, which uses multiple occurrences of the mail attribute instead of an extra alias attribute. I am using the same ldap attribute for attrEmail and attrEmailAlias.
Expected Behavior
I would have expected for additional occurrences of the mail attribute to be used as aliases.
Actual Behavior
Stalwart only delivers to the first address.
The issue is that map_entry in backend/ldap/lookup.rs consumes all the attrEmail attributes while setting only the primary mail, thus leaving none for the same-valued attrEmailAlias attribute.
I am not too thrilled about the patch to tests. I have simply added another mail: entry to the Jane entry, as openldap is okay with that, but the order should not be guaranteed, as far as I know. It works reliably in my testing, though. I am also running this on my server and it now works as expected.
Disclosure: I am new to Rust and AI has been used.
Stalwart Version
v0.16.x
Installation Method
NixOS
Database Backend
RocksDB
Blob Storage
RocksDB
Search Engine
Internal
Directory Backend
LDAP
I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.
on
I have searched this support forum (open and closed topics) and confirm this is not a duplicate.
on
I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.
Confirmed by reading the source: in map_entry (crates/directory/src/backend/ldap/lookup.rs), each LDAP attribute name from the entry is matched against attr_email and attr_email_alias via an if / else if chain. Since matching is done per attribute name rather than per value, if the same LDAP attribute (e.g. mail) is configured as both attrEmail and attrEmailAlias, only the attr_email branch fires — it takes the first value as the primary address and discards the rest, so the attr_email_alias branch never runs for that attribute and none of the additional mail values become aliases.
This matches your diagnosis: any directory (like Kanidm) that stores primary + alias addresses as repeated values of a single attribute will lose all but the first value when that same attribute name is reused for both attrEmail and attrEmailAlias.
This is a genuine bug in the current LDAP mapping logic. A staff or community member will follow up on this thread to review your proposed fix.
This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.
There is one case that I revealed through my lazier testing, that I don’t think is handled by the upstream fix, as far as I can tell:
It could be possible for attrEmail and attrEmailAlias to be distinct, but attrEmail to appear multiple times anyway. Not sure if that case is found in the wild, but it should be legal according to the openldap schema.