Strange authentication failure for newly created account using Stalwart CLI

Issues
1

Issue Description

I used the Stalwart CLI called from a php script to create a new account that did not exist before thus:

stalwart-cli --url http://localhost:8080 --api-key xxx create account/user
–field name=‘test’
–field description=‘Test One’
–field credentials=‘{“0”:{“@type”:“Password”,“secret”:“xx”}}’
–field domainId=‘b’
–field quotas=‘{“maxDiskQuota”:10737418240}’

An attempt to login with both web interface and IMAP from a webmail client failed immediately within 5 minutes of creation. After lots of testing, deleting and recreating the account, creating directly from the command line without php, I eventually discovered that by renaming the account to “test1” in the web administration interface, login worked immediately with the same password but when I removed the “1” in the username, login again failed. I then restarted stalwart and this time, “test” login worked. This behaviour appeared out of nowhere after hundreds of other emails were created using the same method and login worked for them.

I am using Stalwart 0.16.7 on Ubuntu 24.04.4 LTS.

Expected Behavior

Account should login right after creation and should not fail.

Actual Behavior

Explained above.

Reproduction Steps

Create an account with:

stalwart-cli --url http://localhost:8080 --api-key xxx create account/user
–field name=‘test’
–field description=‘Test One’
–field credentials=‘{“0”:{“@type”:“Password”,“secret”:“xx”}}’
–field domainId=‘b’
–field quotas=‘{“maxDiskQuota”:10737418240}’

Try to login. If login fails, rename account and login. Logout and rename account back to what it was and try to login.

Relevant Log Output

Nothing relevant from logs.

Stalwart Version

v0.16.x

Installation Method

Binary (Linux)

Database Backend

RocksDB

Blob Storage

RocksDB

Search Engine

Internal

Directory Backend

Internal

Additional Context

Snappymail and Roundcube mail clients both failed to login until after renaming and then restarting then they both worked.

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.

on

2

The root cause is clearly the negative cache (specifically emailAddressesNegative and related caches). Here is what happened and how to address it:

The login failures are almost certainly caused by Stalwart’s negative lookup cache. When the server first tried to resolve the username test (for example, during a failed or probing login attempt before the account was fully committed), it found nothing and stored that “not found” result in the negative cache. Subsequent login attempts hit that cached negative result – even though the account now existed – causing authentication to fail until the cache entry expired (default TTL: 1 hour) or the server was restarted (which clears in-memory caches).

The rename to test1 worked because that username had no negative cache entry, so the lookup went directly to the database and found the account. Renaming back to test still hit the stale negative cache entry until the restart cleared it.

What you can do:

  1. Reduce the negativeTtl in the Cache settings (WebUI: Settings > Storage > Cache, field negativeTtl). The default is 1h; lowering it (e.g. to 60s or 5m) reduces the window during which a newly created account would be invisible. The trade-off is slightly more database lookups.

  2. Avoid any lookup of an address before the account is created. If your PHP script or any client probes the address (e.g. a login attempt, RCPT TO check, etc.) before the stalwart-cli create call completes, a negative entry will be cached. Make sure the account creation finishes before any login attempt occurs.

  3. Restart is the brute-force fix (which you already discovered), since it flushes all in-memory caches.

You can adjust negativeTtl in the WebUI under Settings › Storage › Cache.

Reference: Stalwart Caching documentation

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.

3

But shouldn’t account creation automatically clear any cache entries related to the newly created mailbox by default? Is there a way to programmatically clear it for the new account?

4

This may be helpful.

5

That is extremely helpful! Thank you very much. My code checks if the mail exists first before creating it (a very normal thing in programming) so that is what led to the cache entry leading to failed login after creation.

I think that by default, when stalwart runs the account creation process in whatever form, it should automatically clear the cache for that mailbox just before creation. Maybe this can be considered for future releases because it was a rather annoying and baffling problem that wasted time dealing with. Cheers!!!