Goodmorning,
I created a group mail but it doesn’t receive mails. I’m using an external ldap directory (Active Directory).
The group shows, I added account to it, subscribed to the imaps folder but i can’t receive mails. Even with the internal mail delivery testing the mail is undeliverable.
Let me look into how groups and LDAP directories work together in Stalwart.
The most common cause of this is a mismatch between Stalwart’s default LDAP filters/attributes and how Active Directory models groups. Here is what to check:
1. The filterMailbox filter does not match AD groups
Stalwart’s default filterMailbox filter looks for objectClass=groupOfNames, but Active Directory uses objectClass=group. The default will therefore never find your AD group by email address, making delivery fail. You need to override it in your Directory configuration to match AD’s schema. For example:
{
"@type": "Ldap",
"filterMailbox": "(|(& (objectClass=user)(|(mail=?)(mailAlias=?)))(& (objectClass=group)(|(mail=?)(mailAlias=?))))"
}
Adjust the objectClass values to match exactly what your AD uses (user and group are the typical AD classes).
2. The groupClass attribute must match
The groupClass field tells Stalwart which object class identifies a group entry (default is "groupOfNames"). For AD, set it to "group" so the server treats those entries as groups and expands members for delivery.
3. The mail attribute must be set on the AD group
Stalwart looks up groups by their mail attribute (via filterMailbox). Make sure the AD group object actually has a mail attribute set to the group’s email address, since AD does not add this by default.
4. Member expansion with filterMemberOf
The default filterMemberOf is (&(objectClass=groupOfNames)(member=?)). For AD, change groupOfNames to group so Stalwart can correctly enumerate group members during delivery.
The relevant documentation is at:
filterMailbox, filterMemberOf, groupClass fields)This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong. If you found it useful, mention @helpbot in any reply to ask follow-up questions and the bot will respond again.
@helpbot was useful, I’ve included mail of groups in the query. However the group get listed as an account instead of as a group. GroupClass and “memberOf” are set
The issue is specifically with groupClass. Stalwart reads back the objectClass attribute from the LDAP entry and compares it against the groupClass value to decide whether to treat the entry as a group or an individual account. Since the default is "groupOfNames" and Active Directory uses "group", Stalwart is classifying your AD group entries as regular user accounts instead of groups – which is why members are not being expanded for delivery.
You need to set groupClass to "group" in your Directory configuration:
{
"@type": "Ldap",
"groupClass": "group"
}
To summarize all the AD-specific overrides you likely need together:
{
"@type": "Ldap",
"groupClass": "group",
"filterMailbox": "(|(& (objectClass=user)(|(mail=?)(mailAlias=?)))(& (objectClass=group)(|(mail=?)(mailAlias=?))))",
"filterMemberOf": "(&(objectClass=group)(member=?))"
}
The attrClass field (which tells Stalwart which LDAP attribute holds the object class) defaults to ["objectClass"] and should be correct for AD already – the key is that groupClass must match what AD actually puts in that attribute ("group", not "groupOfNames").
Reference: LDAP object attributes docs and the groupClass field reference.
This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong. If you found it useful, mention @helpbot in any reply to ask follow-up questions and the bot will respond again.
the issue got fixed after logging in to an email client. So configure the directory as the bot suggested
the group get listed and created but if i try to send a mail to its email address i get ERROR Authentication error (auth.error) listenerId = “submissions”, localPort = 465, remoteIp = 192.+++.0.++, remotePort = 59793, details = “Account ID from directory does not correspond to a user account”, accountName = “commerciale@+++++”, accountId = 23, causedBy = “crates/smtp/src/inbound/rcpt.rs:255”, details = “Failed to verify address.” but mail to users get delivered fine. The group account with his mail get listed in ui and linked to user.
This is a classification mismatch. Stalwart treats an LDAP entry as a group only when the attribute you configured for the object class returns a value that matches the configured group class. For Active Directory that class value is group. If that does not line up, the entry is treated as an account, and the fact that the address was once listed as an account suggests it was synced as one earlier, leaving a registry object of the wrong type that now conflicts when resolution returns a group.
Two things to check: in the LDAP directory settings, make sure the class attribute is the one that actually carries objectClass and the group class is set to group, and then remove the stale account principal that exists for that group address so the registry no longer holds the wrong type for it. Normal user mail working tells me the rest of the directory wiring is fine.
About the mail getting listed as user I managed to fix it by deleting the stale account and letting Stalwart create the group doing an IMAP sync instead of testing the mail adress freshly added with the inbound delivery tester.
Now everithing should be working. The mail are listed as group and the users are assigned. My mail filter for the directory is (|(&(objectClass=user)(|(sAMAccountName=?)(mail=?)(proxyAddresses=?)))(&(objectClass=group)(|(mail=?)(proxyAddresses=?))))
Should I check if there are stale accounts in any other way?
I managed to fix it on my own.
in my external directory the “Account Type Attribute” entry wasn’t set. For AD it should be set to objectClass.
Now everything is working.
