JMAP client triggering (non-documented) "Too Many Authentication Attempts" autoban

[nigini]

Issue Description

When using a JMAP client that authenticates a dozen or so times (all successful) and makes a couple of dozen JMAP successful requests, it triggers a "Too Many Authentication Attempts" IP ban. Here is a summary of logs:

2026-03-20T18:08:59Z INFO Authentication successful (auth.success) listenerId = "http", localPort = 8080, remoteIp = <LOCAL_IP>, remotePort = 40534, accountName = "<ACCOUNT>", accountId = 2
===>> [x12 in quick succession]
2026-03-20T18:09:15Z INFO Authentication successful (auth.success) listenerId = "http", localPort = 8080, remoteIp = <LOCAL_IP>, remotePort = 40560, accountName = "<ACCOUNT>", accountId = 2
2026-03-20T18:09:29Z INFO Authentication successful (auth.success) listenerId = "http", localPort = 8080, remoteIp = <LOCAL_IP>, remotePort = 40560, accountName = "<ACCOUNT>", accountId = 2
2026-03-20T18:09:30Z INFO Banned due to authentication errors (security.authentication-ban) listenerId = "http", localPort = 8080, remoteIp = <LOCAL_IP>, remotePort = 40560, remoteIp = <EXTERNAL_IP>, accountName = "<ACCOUNT>"
2026-03-20T18:09:45Z INFO Blocked IP address (security.ip-blocked) listenerId = "http", localPort = 8080, remoteIp = <LOCAL_IP>, remotePort = 40560, listenerId = "http", remoteIp = <EXTERNAL_IP>

EVENT COUNTS IN ~ 2 min

• auth.success: 17
• auth.failed: 0
• authentication-ban: 1
• http.connection-start: 5 (4 parallel connections from webmail)
• http 204 (No Content): 7 (unauthenticated JMAP probe requests)
• http 200 (OK): 13 (successful JMAP responses)
• store.data-write: 20 (2 writes per auth = auth counter updates?)
• JMAP method calls: 24 (legitimate JMAP operations)

Expected Behavior

Based on documentation, issues, and discussion searches, I could not find any other expected behavior than simply letting the JMAP user+IP alone.

I guess the solution is to clarify how limit rates are enforced and configured, and to fix INFO messages about "Banned due to authentication errors".

Actual Behavior

User/IP blocked: (from logs)

1. INFO Banned due to authentication errors (security.authentication-ban) ...
2. TRACE HTTP response body (...) contents = "{"type":"about:blank","status":429,"title":"Too Many Authentication Attempts" (...)
3. INFO Blocked IP address (security.ip-blocked) (...)

Reproduction Steps

1. Start Stelward with all defaults;
2. Create a user;
3. Point a JMAP client (I am using this);
4. Login.
   (JMAP tends to be pretty talkative as it asks for different data in different requests...)

Relevant Log Output

[Around 20x rounds like the following: Successful Auth + Successful JMAP call]

2026-03-20T21:36:35Z TRACE Data store iteration operation (store.data-iterate) elapsed = 0ms
2026-03-20T21:36:35Z INFO Authentication successful (auth.success) listenerId = "http", localPort = 8080, remoteIp = <TRAEFIK_IP>, remotePort = 56832, accountName = "<ACCOUNT>", accountId = 2
2026-03-20T21:36:35Z TRACE Write batch operation (store.data-write) elapsed = 0ms, total = 2
2026-03-20T21:36:35Z TRACE HTTP request body (http.request-body) listenerId = "http", localPort = 8080, remoteIp = <TRAEFIK_IP>, remotePort = 56832, details = [["host", "mail.<SERVER.URL>"], ["user-agent", "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36"], ["content-length", "122"], ["accept", "*/*"], ["accept-encoding", "gzip, deflate, br, zstd"], ["accept-language", "en-GB,en;q=0.7"], ["authorization", "Basic <TOKEN>"], ["content-type", "application/json"], ["origin", "https://webmail.<SERVER.URL>"], ["priority", "u=1, i"], ["referer", "https://webmail.<SERVER.URL>/"], ["sec-ch-ua", ""Chromium";v="146", "Not-A.Brand";v="24", "Brave";v="146""], ["sec-ch-ua-mobile", "?0"], ["sec-ch-ua-platform", ""Linux""], ["sec-fetch-dest", "empty"], ["sec-fetch-mode", "cors"], ["sec-fetch-site", "same-site"], ["sec-gpc", "1"], ["x-forwarded-for", "<EXTERNAL_IP>"], ["x-forwarded-host", "mail.<SERVER.URL>"], ["x-forwarded-port", "443"], ["x-forwarded-proto", "https"], ["x-forwarded-server", "e273a72a16d3"], ["x-real-ip", "<EXTERNAL_IP>"]], contents = "{"using":["urn:ietf:params:jmap:core","urn:ietf:params:jmap:mail"],"methodCalls":[["Identity/get",{"accountId":"c"},"0"]]}", size = 122
2026-03-20T21:36:35Z TRACE Data store iteration operation (store.data-iterate) elapsed = 2ms
2026-03-20T21:36:35Z TRACE Data store iteration operation (store.data-iterate) elapsed = 3ms
2026-03-20T21:36:35Z DEBUG JMAP method call (jmap.method-call) listenerId = "http", localPort = 8080, remoteIp = <TRAEFIK_IP>, remotePort = 56832, id = "Identity/get", accountId = 2, elapsed = 8ms
2026-03-20T21:36:35Z TRACE HTTP response body (http.response-body) listenerId = "http", localPort = 8080, remoteIp = <TRAEFIK_IP>, remotePort = 56832, contents = "{"methodResponses":[["Identity/get",{"accountId":"c","state":"sae","list":[{"id":"b","name":"<ACCOUNT_NAME>","email":"<ACCOUNT>@<SERVER.URL>","replyTo":null,"bcc":null,"textSignature":"","htmlSignature":"","mayDelete":true}],"notFound":[]},"0"]],"sessionState":"3e25b2a0"}", code = 200, size = 269


[Then blocked]

2026-03-20T21:37:35Z INFO Banned due to authentication errors (security.authentication-ban) listenerId = "http", localPort = 8080, remoteIp = <TRAEFIK_IP>, remotePort = 56832, remoteIp = 159.26.103.121, accountName = "<ACCOUNT_NAME>"
2026-03-20T21:37:35Z TRACE HTTP response body (http.response-body) listenerId = "http", localPort = 8080, remoteIp = <TRAEFIK_IP>, remotePort = 56832, contents = "{"type":"about:blank","status":429,"title":"Too Many Authentication Attempts","detail":"Your request has been rate limited. Please try again in a few minutes."}", code = 429, size = 160
2026-03-20T21:37:35Z INFO Blocked IP address (security.ip-blocked) listenerId = "http", localPort = 8080, remoteIp = <TRAEFIK_IP>, remotePort = 56832, listenerId = "http", remoteIp = <EXTERNAL_IP>

Stalwart Version

v0.15.x

Installation Method

Docker

Database Backend

PostgreSQL

Blob Storage

PostgreSQL

Search Engine

PostgreSQL

Directory Backend

Internal

Additional Context

Server is behind Traefik and using JMAP-webmail as client

I acknowledge that:

• I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.
• I have searched the Stalwart repository (both open and closed Discussions and Issues) and confirm this is not a duplicate.
• I have set the logging level to trace and included relevant log output if applicable.
• I agree to follow the project's Code of Conduct.

[pschoenmakers]

I’m seeing this as well with Bulwark as the JMAP client.

In my case, login appears to succeed at first, but shortly after Stalwart starts returning 429 Too Many Authentication Attempts, and Bulwark becomes unusable until the limit clears. From the frontend side it then looks like the session expired, but the actual backend response is the auth-related 429.

So this does not seem isolated. I’m also trying to determine whether Bulwark is retrying failed auth in a loop, or whether Stalwart is counting some successful/repeated JMAP auth pattern more aggressively than expected.
bulwarkmail/webmail#104

[mdecimus]

Adjust the rate limit settings to avoid that. Alternatively grant your account the unlimited-requests permission.

[nigini]

What rate are we talking about here? To be clear, one of the points of this discussion is the lack of clarity about which rate is being enforced and how hard it was to identify the issue using the logs.

If you are talking about JMAP > rate limits, my server is using 1000/min, which is 100x higher than what I observed before the client is blocked.

[pschoenmakers]

My client was blocked after just 4 request in 20 seconds. So not sure the problem is the amount of requests at all.

[nigini]

I found something new by re-examining clean-slate server logs:

1. There is an issue with how the http_cache is being used --> that explains the JMAP client re-authenticating at every call
2. This time around, I observed auth.failed in the logs, but strangely, occured after a 10s gap between JMAP client requests
3. The fail2ban was increased at every failured but did not reach any limit, so I was able to re-login in the JMAP client.

What can I see in the logs

(first 32 seconds) 22 successful auths. Each one shows (which means the cache was not being used):
  store.data-iterate   ← get_principal() loads user from PostgreSQL
  auth.success         ← credentials verified

(10-second gap) No requests likely after the JMAP client finished updating state! 
  Then I saw a client message saying it couldn't save a draft! First failure. The log shows:
    store.data-write     ← fail2ban counter increment (IP)
    store.data-write     ← fail2ban counter increment (login)
    auth.failed          ← same credentials!

I log back in, and the pattern kind of repeats!

How to fix the JMAP auth per request

!!! It is likely that with this fix, whatever was causing the auth.fail (related to the next problem below) + fail2ban will go away

(crates/http/src/auth/authenticate.rs:37):                                                                                                                                              
  -  if http_cache.expires <= Instant::now() {
  +  if http_cache.expires >= Instant::now() {                                                                                                                                                

How I confirmed it:

(unit test code summary after fix):

  // Part 1: First request hits the store                                                                                                                                                     
  let count_before = auth_success_count();
  jmap_request_status(account.name(), account.secret()).await;                                                                                                                                
  let count_after = auth_success_count();
  assert!(count_after > count_before);  // store was hit                                                                                                                                      
                                                                                                                                                                                              
  // Part 2: Next 10 requests use the cache
  let count_before = auth_success_count();                                                                                                                                                    
  for _ in 0..10 {                                                                                                                                                                            
      jmap_request_status(account.name(), account.secret()).await;
  }                                                                                                                                                                                           
  assert_eq!(auth_success_count(), count_before);  // store was NOT hit

Why did the auth fail after a gap in requests

While looking for log messages, I found that the auth flow in backend/internal/lookup.rs:29-77 may indicate a (temporary) failure with retrieving the user? (Maybe a connection was returned to the pool after the client stopped requests for some seconds.)

  // Step 1: key-value GET (no iterate logged)                                                                                                                                                
  let account_id = self.get_principal_id(username).await?;                                                                                                                                    
                                                                                                                                                                                              
  // Step 2: only if account_id is Some — ITERATES (logged as store.data-iterate)                                                                                                             
  if let Some(account_id) = account_id                                                                                                                                                        
      && let Some(mut principal) = self.get_principal(account_id).await?                                                                                                                      
  {
      // Step 3: verify password                                                                                                                                                              
      ...         
  }                                                                                                                                                                                           

reasoning: get_principal_id does a simple get_value (a SELECT — not logged as store.data-iterate). get_principal does an iterate (is logged). So if we don't see the iterate, it means get_principal was never called, which means get_principal_id returned None.

[Sancus]

Looks like this was quietly fixed in e0105bc4#diff-a71a8aac8f5f437bf77eab36ba2d0a32455a3285b45f4f1a17972336c3aab8df lol

Just hit it, upgrading to 0.16 should resolve it I guess!