LDAP Email Aliases Not Working for SMTP Delivery Despite Being Visible in Admin UI

[PatrickHuetter]

Description

Email aliases imported from LDAP are visible in the Admin UI but emails sent to these aliases are rejected with "Mailbox does not exist" error during SMTP delivery. The primary email address works correctly for authentication and is visible in the UI, but alias addresses cannot receive emails.

Environment

• Stalwart Version: v0.13.3
• Deployment: Kubernetes (via Helm)
• Directory: LDAP (OpenLDAP)
• License: Enterprise Edition Demo (valid license confirmed in logs)

Current Configuration

LDAP Directory Configuration

directory:
  "ldap":
    type: "ldap"
    url: "ldap://openldap.openldap.svc.cluster.local:389"
    base-dn: "dc=example,dc=com"
    
    bind:
      dn: "cn=admin,dc=example,dc=com"
      secret: "[REDACTED]"
    
    auth:
      method: "lookup"
    
    filter:
      name: "(&(objectClass=inetOrgPerson)(|(uid=?)(mail=?))(|(employeeType=Employee)(employeeType=Contractor)(employeeType=Partner)(employeeType=Service)))"
      email: "(&(objectClass=inetOrgPerson)(|(mail=?)(otherMailbox=?))(|(employeeType=Employee)(employeeType=Contractor)(employeeType=Partner)(employeeType=Service)))"
      domains: "(&(objectClass=inetOrgPerson)(|(mail=*@?)(otherMailbox=*@?)))"
    
    attributes:
      name: "uid"
      email: "mail"
      email-alias: "otherMailbox"
      secret: "userPassword"

Session Configuration

session:
  rcpt:
    directory: "'ldap'"
    relay: false
    catch-all: false

LDAP User Example

dn: uid=jdoe,ou=users,dc=example,dc=com
cn: John Doe
employeetype: Employee
mail: [email protected]
objectclass: inetOrgPerson
objectclass: organizationalPerson
objectclass: person
objectclass: top
objectclass: extensibleObject
othermailbox: [email protected]
othermailbox: [email protected]
othermailbox: [email protected]
uid: jdoe

Observed Behavior

1. User can authenticate successfully with username (jdoe) or primary email
2. Admin UI correctly displays all aliases ([email protected], [email protected], [email protected])
3. Authentication logs show successful login:

   2025-09-18T13:18:11Z INFO Authentication successful (auth.success) accountName = "jdoe"
   

4. When email is sent to alias address, it's rejected:

   2025-09-18T13:25:24Z INFO Mailbox does not exist (smtp.mailbox-does-not-exist) to = "[email protected]"
   

Expected Behavior

Emails sent to any of the alias addresses (defined in othermailbox LDAP attribute) should be accepted and delivered to the user's mailbox, just like the primary email address.

What I've Tried

1. Different filter combinations:

   • (|(mail=?)(othermailbox=?)) - lowercase, as stored in LDAP
   • (|(mail=?)(otherMailbox=?)) - camelCase, matching attribute mapping
   • With and without objectClass=inetOrgPerson
   • With and without employeeType filtering

2. Different attribute mappings:

   • email-alias: "otherMailbox" - works for displaying aliases in UI
   • email-alias: "othermailbox" - lowercase version
   • email-alias: ["otherMailbox", "othermailbox"] - both variations

3. Added session.rcpt configuration as suggested in documentation

4. Added domains filter for domain validation

Questions

1. Is there a specific filter or configuration required for LDAP email aliases to work with SMTP RCPT TO validation?
2. Does the email filter need special syntax to properly handle multi-valued alias attributes?
3. Is there a difference between how aliases are handled for UI display vs. SMTP delivery?
4. Are there any debug logs I can enable to see what LDAP query is being executed during RCPT TO validation?

Additional Context

• The LDAP attribute othermailbox is multi-valued (user has 3 aliases)
• Some users don't have the othermailbox attribute at all
• Primary email delivery works perfectly
• This appears similar to issue How to set up ldap with authentik? #521 and discussion "Mailbox does not exist" for account's email but not its aliases #1364 but the solutions there didn't work

Any help or guidance would be greatly appreciated. I'm happy to provide additional logs or test different configurations.

[PatrickHuetter]

Solution Found: Root Cause and Fix for LDAP Email Alias Delivery

I've successfully resolved this issue and wanted to share the solution and root cause for anyone facing similar problems.

Root Cause

The issue was that the LDAP attribute used for email aliases (otherMailbox) was not searchable/indexable in OpenLDAP. When Stalwart performs RCPT TO validation during SMTP delivery, it uses the filter.email LDAP filter to search for the recipient address. Since otherMailbox couldn't be indexed in OpenLDAP, the LDAP search query would return no results, even though the attribute values existed and were visible when directly reading the user object.

Why it appeared to work in the UI

The Admin UI correctly displayed aliases because Stalwart uses the email-alias attribute mapping to directly read the attribute values from the user object after authentication. This is different from searching for those values across the directory.

The Solution

Since otherMailbox is not a standard LDAP attribute that supports equality/substring indexing, I created a custom LDAP schema with a searchable attribute:

1. Added custom schema to OpenLDAP with an indexable attribute

# In OpenLDAP Helm values.yaml
customSchemaFiles:
  01-mailalias.ldif: |
    dn: cn=mailAlias,cn=schema,cn=config
    objectClass: olcSchemaConfig
    cn: mailAlias
    olcAttributeTypes: ( 1.3.6.1.4.1.99999.1.1
      NAME 'mailAlias'
      DESC 'RFC1274: RFC822 email alias'
      EQUALITY caseIgnoreIA5Match
      SUBSTR caseIgnoreIA5SubstringsMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
    olcObjectClasses: ( 1.3.6.1.4.1.99999.2.1
      NAME 'mailAliasObject'
      DESC 'Object that allows mail aliases'
      SUP top AUXILIARY
      MAY mailAlias )

customLdifFiles:
  02-index.ldif: |
    dn: olcDatabase={2}mdb,cn=config
    changetype: modify
    add: olcDbIndex
    olcDbIndex: mailAlias eq,sub

2. Updated Stalwart configuration to use the new attribute

directory:
  ldap:
    filter:
      name: "(&(objectClass=inetOrgPerson)(|(uid=?)(mail=?))(|(employeeType=Employee)(employeeType=Contractor)))"
      email: "(&(objectClass=inetOrgPerson)(|(mail=?)(mailAlias=?))(|(employeeType=Employee)(employeeType=Contractor)))"
      domains: "(&(objectClass=inetOrgPerson)(|(mail=*@?)(mailAlias=*@?)))"
    
    attributes:
      email: "mail"
      email-alias: "mailAlias"  # Changed from otherMailbox to mailAlias

3. Migrated user data to use the new attribute

dn: uid=jdoe,ou=users,dc=example,dc=com
changetype: modify
add: objectClass
objectClass: mailAliasObject
-
add: mailAlias
mailAlias: [email protected]
mailAlias: [email protected]

Testing the Fix

After implementing these changes, I verified that LDAP could now search for aliases:

# This now returns the user (previously returned nothing)
ldapsearch -x -H ldap://localhost:389 -D "cn=admin,dc=example,dc=com" -W \
  -b "dc=example,dc=com" "([email protected])" dn mail mailAlias

And emails to alias addresses are now successfully delivered!

Suggestions for Stalwart Enhancement

While this solution works, it would be beneficial if Stalwart could handle non-indexed alias attributes more gracefully. Some potential improvements:

1. Two-step validation for aliases: When an email address isn't found via the filter.email search, Stalwart could:

   • Extract the domain part
   • Search for all users in that domain
   • Check their email-alias attributes directly

2. Separate filter for alias validation: Add an optional filter.email-alias that could use a different search strategy, perhaps searching by domain first then filtering in-memory.

3. Documentation enhancement: Add a note in the LDAP documentation warning that alias attributes must be indexable/searchable in LDAP for SMTP delivery to work, as this isn't immediately obvious.

4. Diagnostic logging: Add debug logs that show the exact LDAP queries being executed during RCPT TO validation, which would help identify these types of issues faster.

Key Takeaway

The main lesson here is that LDAP attribute visibility ≠ LDAP attribute searchability. For Stalwart's email delivery to work with aliases, the alias attribute must be properly indexed in your LDAP server.

Hope this helps others facing similar issues! The combination of a custom indexed attribute and proper filter configuration completely resolved the email alias delivery problem.