I’m currently using Stalwart together with Bulwark. I’m syncing users and groups through Keycloak. Is it possible to take mail identities and sync those to all users using a group, and sync those identities from AD somehow.
Currently, when a user logs in and sends an email from a shared group it gets the personal name of the sender attached. But I was wondering if I can sync an identity from the server so that a group [email protected] gets automatically the identity Company HR, for all users. And that users can’t just change identities to say anything they can think of.
Is that something I should setup in Stalwart, or should that go in Bulwark? I’d guess that information should come from Stalwart server, but I’m not sure. Thanks for any help you can give.
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.
Stalwart does not automatically sync sender identities from LDAP/AD. Identities (the “From” name/address a user is allowed to send as) are separate JMAP objects tied to each account, and by default any user with the jmapIdentityCreate/jmapIdentityUpdate permissions can create or edit their own identities freely, which is why you’re seeing users’ personal names attached to group sends.
To get what you want, there are two separate pieces:
Provisioning identities from AD/Keycloak group membership. There’s no built-in “sync identities from directory group” feature. You would need to create the Identity objects (e.g. “Company HR” / [email protected]) on each relevant account yourself, via the JMAP API or stalwart-cli, driven by your own script that reads AD/Keycloak group membership. This is external tooling on top of Stalwart, not something Bulwark or Stalwart do automatically.
Preventing users from freely changing/adding identities. You can lock this down with a Role that has jmapIdentityCreate and jmapIdentityUpdate removed from enabledPermissions (or added to disabledPermissions) for the relevant users/group. That leaves only jmapIdentityGet so users can see and select from identities an administrator has pre-created for them, but can’t invent arbitrary display names.
So the setup belongs on the Stalwart side (identities and role/permissions live there), with your own AD-to-Stalwart sync script populating the actual identity records; Bulwark is not involved in identity management.
Reference: https://support.stalw.art/… see also /docs/ref/permissions (JmapIdentity section) and /docs/ref/object/role.
This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.
Those identities are not coming from Bulwark, they are ours. Stalwart auto-creates one JMAP Identity per address an account is allowed to send from, and that includes the addresses of every group the user belongs to, which is where the [email protected] entry comes from.
The display name on all of them is taken from the user’s own description and applied to every identity we create, including the group ones. The group’s description is never looked at. So sending as hr@ shows a personal name, and no setting changes that today. Making group addresses use the group’s own description is a small change and a reasonable one; I will look at it.
The account description itself does sync already, from attrDescription on LDAP or the name claim on OIDC, so per-user display names are centrally managed. It is only the group case that is not.
A user can rename the hr@ identity once from the client and it will stick, since auto-creation never rewrites an existing identity’s name. That is per user and not something you can enforce centrally.
Regarding your wider question: what is enforced server-side is the address, not the name. An identity’s email has to be one of the account’s own or group addresses, and the submission envelope has to match it, so users cannot invent send-from addresses. Display names are free-form by design. If you also want extra send-from addresses synced, attrEmailAlias (default mailAlias) maps LDAP aliases onto the account; OIDC has no equivalent claim, so there those have to come from SCIM or be set locally.