Your question
I am currently setting up Stalwart Mail Server and managing users via the Internal Directory (RocksDB). However, I noticed that there doesn’t seem to be a straightforward way to deactivate or disable an individual user account (like an isActive or status boolean field).
Steps to reproduce / What I did:
Navigate to the WebUI > Management > Directory > Accounts.
Select or edit any existing account principal.
Look through the available configuration fields for a status toggle or account activation switch.
Expected behavior:
I expected to find a built-in property (e.g., isActive: true/false or a “Disable Account” checkbox) directly on the Account object to temporarily block a user from authenticating, sending, or receiving mail.
Stalwart version: 0.16 Nginx
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.
on
That’s the key piece of information. Stalwart’s permission system includes an authenticate permission that can be explicitly disabled on an account. Let me verify how to apply that.
The answer is clear from the docs. There is no single isActive toggle, but the intended mechanism is the permissions system. Here’s the complete picture:
Stalwart does not have an isActive/disabled boolean on account objects. The designed way to block a user from authenticating is to remove the authenticate (and authenticate-oauth) permissions from their account by adding those to the account’s disabledPermissions list.
Here’s how the permission system works for this:
- Every account has
enabledPermissions and disabledPermissions fields.
- The
authenticate permission controls whether a principal can log in at all. It is present in all built-in roles (admin, tenant-admin, user).
- Adding
authenticate to a user’s disabledPermissions overrides everything – disabled permissions always take precedence over enabled ones, regardless of what roles the account has.
- This can be done in the WebUI under Management > Directory > Accounts > (edit account) > Permissions, or via the JMAP API.
So the practical workflow to “disable” an account:
- Open the account in the WebUI.
- In the Permissions section, set the mode to
Merge (or Replace) and add authenticate and authenticate-oauth to Disabled Permissions.
- Save. The user will immediately be unable to log in via any protocol.
To re-enable, simply remove those entries from disabledPermissions.
This is documented in the Permissions page and the Account object 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.
Thanks for the suggestions! While stripping permissions (like authenticate) technically stops a user from logging in and sending emails, it creates a couple of significant practical issues in production:
-
Poor User Experience: When the authenticate permission is removed, mail clients receive an “Authentication Failed” error instead of an “Account Disabled” notice. As a result, users assume they just forgot their password or that the system is glitching, leading them to repeatedly try logging in or submitting support tickets.
-
Inbound Mail Accumulation: Just blocking authentication doesn’t prevent incoming emails. Mail servers from the internet will still successfully deliver messages to this disabled mailbox. Over time, it will continue to bloat, potentially accumulating thousands of unread spam emails and wasting valuable server storage.
Of course, we could go around and manually strip all other protocol permissions (like incoming mail handles) or stitch together multiple custom Sieve scripts to catch the account at various SMTP stages. However, having to juggle multiple separate workarounds just to achieve a basic, standard administrative task like cleanly deactivating a user account feels unnecessarily convoluted.
A simple, native status flag or switch on the account profile would be a much cleaner and more robust solution for system administrators.
Your feedback is valid and well-articulated. To address the two specific concerns:
On the “Authentication Failed” UX issue: This is a real limitation of the permissions approach – SMTP/IMAP/POP3 protocol errors are generic and clients cannot surface a human-friendly “account disabled” message. There is no documented mechanism in Stalwart to return a custom error string for a missing authenticate permission.
On inbound mail accumulation: This is the more tractable problem right now. You can reject inbound mail at the SMTP RCPT TO stage using a Sieve script combined with a lookup list. The workflow:
- Create a lookup list (e.g., a
MemoryLookupKey namespace called disabled-accounts) and add entries for each disabled account address.
- Attach a Sieve script to the RCPT stage (via the
script field on MtaStageRcpt) that checks key_exists('disabled-accounts', rcpt) and issues a reject with a meaningful SMTP message like "550 5.1.1 This account has been disabled.". This causes the sending MTA to bounce with a clear permanent error, stopping accumulation.
require ["variables", "envelope", "extlists", "reject"];
if key_exists('disabled-accounts', envelope :localpart "to") {
reject "550 5.1.1 This mailbox is no longer active.";
}
That said, you are correct that there is no single native “disable account” toggle today that handles both authentication blocking AND inbound rejection atomically. The underlying feature request – a first-class account status field – is a product design question rather than something documented as planned or available. A human community member or staff member may be able to confirm whether this is on the roadmap.
Relevant docs: RCPT stage Sieve scripts | Lookup lists | Permissions
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.
This is not yet supported. The only way to disable an account at the moment is to remove authentication permissions.
