[Bug]: No Client Access after 1.4.14 Upgrade

[svandive]

Description

Had a fully functional Bulwark --> Stalwart (v0.15.5) setup. I updated the Bulwark container to 1.4.14, and now Users can no longer login.

Accessing the Bulwark Login screen works fine. Entering credentials fails with the Error:
An unexpected error occurred. If this persists, contact your administrator.

No information or detail about the failed login is listed in the Bulwark logs (set to DEBUG).

Stalwart is configured for basic password authentication. Access from other JMAP clients works fine.

Admin Page login works fine, but of course uses a completely different methodology to Client login.

Without logs to identify an issue, I'm not sure where to go from here.

Steps to Reproduce

Upgraded operational Stalwart 0.15.5 + Bulwark implementation to 1.4.14. No other changes or updates.

Expected Behavior

If solution was accessible prior to upgrade the expectation is of course that you can login post upgrade.

Actual Behavior

Error on Login Screen: An unexpected error occurred. If this persists, contact your administrator.

I have to ask, are there expected errors???

Bulwark Version

1.4.14

Stalwart Mail Server Version

0.15.5

Browser

Safari

Operating System

macOS

Screenshots / Screen Recording

Relevant Logs or Error Output

I wish...

Additional Context

No response

[rathlinus]

There will be no logs in the container, please check the browser console on the client for errors

[MagnusFriendz]

I am encountering a similar error with Stalwart OIDC Login.

Webpage says:

Authentication Failed
Failed to complete authentication. Please try again.

Console says:

[ERROR]"OAuth login error:"
Error: No mail account found in session
connect — 4941-09d750c1e8f7410d.js:314

I just changed the Bulwark Version to 1.4.14 - no changes were made to Stalwart or .env ...

Stalwart logs show successful authentication:

04/19/2026, 02:51:16 PM
STDERR
2026-04-19T14:51:16.009675000+02:00 2026-04-19T12:51:16Z INFO Authentication successful (auth.success) listenerId = "https", localPort = 443, remoteIp = <redacted> remotePort = 0, accountName = "<redacted>", accountId = <redacted>
04/19/2026, 02:51:16 PM

Stalwart Login works normally.

Rolling back to previous Bulwark version makes Log-In possible again.

[svandive]

Thank you for the details about where the Logs would be showing. What I am seeing in the Browser Inspector is:

[Error] [ERROR] – "Login error:"
Error: No mail account found in session
connect — 4941-09d750c1e8f7410d.js:314
error (3718-5edea8dcb16d19b9.js:1:694)
(anonymous function) (4941-09d750c1e8f7410d.js:1:90574)

Just to clarify, there is a mail account for the login that is being used. I have tried several accounts to login but they all return this same error.

[rathlinus]

The session parsing didnt change between 1.4.13 and 1.4.14, so the error means Stalwart is returning a 200 session with no accounts populated. Could you capture the following from the failing login:

DevTools → Network → /.well-known/jmap → copy the full JSON response body (redact account IDs if you want). Specifically I need to see whether accounts and primaryAccounts are empty or missing.

The request headers for that same call (to confirm the Authorization header is present and correctly formed).
@MagnusFriendz for the OIDC case, please also decode the access token (jwt.io) and share the scope claim. If Stalwart expects a JMAP-related scope to include accounts in the session, the default openid email profile may not be enough.

If you can also hit /.well-known/jmap with the same credentials from curl (or Thunderbird) and compare the response against what Bulwark receives, that would immediately tell us whether this is client or serverside.

[rathlinus]

Or what version did you guys roll back to?

[svandive]

Running curl from my desktop I get the proper response from Stalwart:

svandive@minim4-10gb ~ % curl -v -u "scott@wakefield.haus:temp-password" \
  https://mail.wakefield.haus/jmap/session
* Host mail.wakefield.haus:443 was resolved.
* IPv6: (none)
* IPv4: 100.27.4.110
*   Trying 100.27.4.110:443...
* Connected to mail.wakefield.haus (100.27.4.110) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256 / [blank] / UNDEF
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=wakefield.haus
*  start date: Apr  3 20:32:20 2026 GMT
*  expire date: Jul  2 20:32:19 2026 GMT
*  subjectAltName: host "mail.wakefield.haus" matched cert's "*.wakefield.haus"
*  issuer: C=US; O=Let's Encrypt; CN=R13
*  SSL certificate verify ok.
* using HTTP/2
* Server auth using Basic with user 'scott@wakefield.haus'
* [HTTP/2] [1] OPENED stream for https://mail.wakefield.haus/jmap/session
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: mail.wakefield.haus]
* [HTTP/2] [1] [:path: /jmap/session]
* [HTTP/2] [1] [authorization: Basic c2NvdHRAd2FrZWZpZWxkLmhhdXM6dmFyUm82LWt1bWJhZC1jaWd4b2Q=]
* [HTTP/2] [1] [user-agent: curl/8.7.1]
* [HTTP/2] [1] [accept: */*]
> GET /jmap/session HTTP/2
> Host: mail.wakefield.haus
> Authorization: Basic c2NvdHRAd2FrZWZpZWxkLmhhdXM6dmFyUm82LWt1bWJhZC1jaWd4b2Q=
> User-Agent: curl/8.7.1
> Accept: */*
> 
* Request completely sent off
< HTTP/2 200 
< access-control-allow-headers: Authorization, Content-Type, Accept, X-Requested-With
< access-control-allow-methods: POST, GET, PATCH, PUT, DELETE, HEAD, OPTIONS
< access-control-allow-origin: *
< content-type: application/json; charset=utf-8
< date: Sun, 19 Apr 2026 13:39:07 GMT
< 
{"capabilities":{"urn:ietf:params:jmap:core":{"maxSizeUpload":50000000,"maxConcurrentUpload":4,"maxSizeRequest":10000000,"maxConcurrentRequests":4,"maxCallsInRequest":16,"maxObjectsInGet":500,"maxObjectsInSet":500,"collationAlgorithms":["i;ascii-numeric","i;ascii-casemap","i;unicode-casemap"]},"urn:ietf:params:jmap:mail":{},"urn:ietf:params:jmap:calendars":{},"urn:ietf:params:jmap:calendars:parse":{},"urn:ietf:params:jmap:contacts":{},"urn:ietf:params:jmap:contacts:parse":{},"urn:ietf:params:jmap:filenode":{},"urn:ietf:params:jmap:principals":{},"urn:ietf:params:jmap:principals:availability":{},"urn:ietf:params:jmap:submission":{},"urn:ietf:params:jmap:vacationresponse":{},"urn:ietf:params:jmap:sieve":{"implementation":"Stalwart v1.0.0"},"urn:ietf:params:jmap:blob":{},"urn:ietf:params:jmap:quota":{},"urn:ietf:params:jmap:websocket":{"url":"wss://mail.wakefield.haus:443/jmap/ws","supportsPush":true}},"accounts":{"c":{"name":"scott@wakefield.haus","isPersonal":true,"isReadOnly":false,"accountCapabilities":{"urn:ietf:params:jmap:mail":{"maxMailboxesPerEmail":null,"maxMailboxDepth":10,"maxSizeMailboxName":255,"maxSizeAttachmentsPerEmail":50000000,"emailQuerySortOptions":["receivedAt","size","from","to","subject","sentAt","hasKeyword","allInThreadHaveKeyword","someInThreadHaveKeyword"],"mayCreateTopLevelMailbox":true},"urn:ietf:params:jmap:submission":{"maxDelayedSend":2592000,"submissionExtensions":{"FUTURERELEASE":[],"SIZE":[],"DSN":[],"DELIVERYBY":[],"MT-PRIORITY":["MIXER"],"REQUIRETLS":[]}},"urn:ietf:params:jmap:vacationresponse":{},"urn:ietf:params:jmap:contacts":{"maxAddressBooksPerCard":null,"mayCreateAddressBook":true},"urn:ietf:params:jmap:contacts:parse":{},"urn:ietf:params:jmap:calendars":{"maxCalendarsPerEvent":null,"minDateTime":"0001-01-01T00:00:00Z","maxDateTime":"65534-12-31T23:59:59Z","maxExpandedQueryDuration":"P52W1D","maxParticipantsPerEvent":20,"mayCreateCalendar":true},"urn:ietf:params:jmap:calendars:parse":{},"urn:ietf:params:jmap:websocket":{},"urn:ietf:params:jmap:sieve":{"maxSizeScriptName":512,"maxSizeScript":1048576,"maxNumberScripts":100,"maxNumberRedirects":1,"sieveExtensions":["body","comparator-elbonia","comparator-i;ascii-casemap","comparator-i;ascii-numeric","comparator-i;octet","convert","copy","date","duplicate","editheader","enclose","encoded-character","enotify","envelope","envelope-deliverby","envelope-dsn","environment","ereject","extlists","extracttext","fcc","fileinto","foreverypart","ihave","imap4flags","imapsieve","include","index","mailbox","mailboxid","mboxmetadata","mime","redirect-deliverby","redirect-dsn","regex","reject","relational","replace","servermetadata","spamtest","spamtestplus","special-use","subaddress","vacation","vacation-seconds","variables","virustest"],"notificationMethods":["mailto"],"externalLists":null},"urn:ietf:params:jmap:blob":{"maxSizeBlobSet":7499488,"maxDataSources":16,"supportedTypeNames":["Email","Thread","SieveScript"],"supportedDigestAlgorithms":["sha","sha-256","sha-512"]},"urn:ietf:params:jmap:quota":{},"urn:ietf:params:jmap:principals":{"currentUserPrincipalId":"c"},"urn:ietf:params:jmap:principals:availability":{"maxAvailabilityDuration":"P52W1D"},"urn:ietf:params:jmap:filenode":{"maxFileNodeDepth":null,"maxSizeFileNodeName":255,"fileNodeQuerySortOptions":[],"mayCreateTopLevelFileNode":true}}}},"primaryAccounts":{"urn:ietf:params:jmap:mail":"c","urn:ietf:params:jmap:submission":"c","urn:ietf:params:jmap:vacationresponse":"c","urn:ietf:params:jmap:contacts":"c","urn:ietf:params:jmap:contacts:parse":"c","urn:ietf:params:jmap:calendars":"c","urn:ietf:params:jmap:calendars:parse":"c","urn:ietf:params:jmap:websocket":"c","urn:ietf:params:jmap:sieve":"c","urn:ietf:params:jmap:blob":"c","urn:ietf:params:jmap:quota":"c","urn:ietf:params:jmap:principals":"c","urn:ietf:params:jmap:principals:availability":"c","urn:ietf:params:jmap:filenode":"c"},"username":"scott@wakefield.haus","apiUrl":"https://mail.wakefield.haus:443/jmap/","downloadUrl":"https://mail.wakefield.haus:443/jmap/download/{accountId}/{blobId}/{name}?accept={type}","uploadUrl":"https://mail.* Connection #0 to host mail.wakefield.haus left intact
wakefield.haus:443/jmap/upload/{accountId}/","eventSourceUrl":"https://mail.wakefield.haus:443/jmap/eventsource/?types={types}&closeafter={closeafter}&ping={ping}","state":"3e25b2a0"}%                                                                               

I believe this is the output your requesting from the Browser Tools:

{
    "capabilities": {
        "urn:ietf:params:jmap:core": {
            "maxSizeUpload": 50000000,
            "maxConcurrentUpload": 4,
            "maxSizeRequest": 10000000,
            "maxConcurrentRequests": 4,
            "maxCallsInRequest": 16,
            "maxObjectsInGet": 500,
            "maxObjectsInSet": 500,
            "collationAlgorithms": [
                "i;ascii-numeric",
                "i;ascii-casemap",
                "i;unicode-casemap"
            ]
        },
        "urn:ietf:params:jmap:mail": {},
        "urn:ietf:params:jmap:calendars": {},
        "urn:ietf:params:jmap:calendars:parse": {},
        "urn:ietf:params:jmap:contacts": {},
        "urn:ietf:params:jmap:contacts:parse": {},
        "urn:ietf:params:jmap:filenode": {},
        "urn:ietf:params:jmap:principals": {},
        "urn:ietf:params:jmap:principals:availability": {},
        "urn:ietf:params:jmap:submission": {},
        "urn:ietf:params:jmap:vacationresponse": {},
        "urn:ietf:params:jmap:sieve": {
            "implementation": "Stalwart v1.0.0"
        },
        "urn:ietf:params:jmap:blob": {},
        "urn:ietf:params:jmap:quota": {},
        "urn:ietf:params:jmap:websocket": {
            "url": "wss://mail.wakefield.haus:443/jmap/ws",
            "supportsPush": true
        }
    },
    "accounts": {},
    "primaryAccounts": {},
    "username": "",
    "apiUrl": "https://mail.wakefield.haus:443/jmap/",
    "downloadUrl": "https://mail.wakefield.haus:443/jmap/download/{accountId}/{blobId}/{name}?accept={type}",
    "uploadUrl": "https://mail.wakefield.haus:443/jmap/upload/{accountId}/",
    "eventSourceUrl": "https://mail.wakefield.haus:443/jmap/eventsource/?types={types}&closeafter={closeafter}&ping={ping}",
    "state": "0"
}

[svandive]

I'm totally sure you guys HATE people posting AI generated output, but this is what Claude is telling me for what it's worth.

---

The data you've shared tells the story clearly — and it's actually enough for the Bulwark developer to diagnose it. Here's what to send them:
The browser response to /.well-known/jmap shows empty accounts, primaryAccounts, and blank username — that's the unauthenticated session. The curl response to /jmap/session with credentials shows the fully populated session.
The critical difference is that /.well-known/jmap returns a 307 redirect to /jmap/session. When a browser follows a cross-origin redirect, it strips the Authorization header from the redirected request per the Fetch spec. So the sequence is:

Bulwark hits /.well-known/jmap with Authorization: Basic ...
Stalwart responds with 307 → /jmap/session
Browser follows redirect but drops the Authorization header
Stalwart sees an unauthenticated request and returns the empty session
Bulwark gets a 200 with empty accounts and throws "No mail account found"

curl doesn't have this problem because it re-sends credentials on redirects by default.
The fix should be on the Bulwark side — instead of hitting /.well-known/jmap with credentials and expecting a populated session back, it should hit /.well-known/jmap without credentials for discovery, extract the apiUrl from the response, then make a separate authenticated request directly to /jmap/session. This is actually what the JMAP spec intends — /.well-known/jmap is a discovery endpoint, not an authenticated session endpoint.

[rathlinus]

Can you test the newest beta?

[svandive]

I can... Give me a few minutes...

[MagnusFriendz]

I posted a related error before occuring only in Safari (Apple WebKit) - it is the same this time. Firefox, Chrome, Opera are working for me.

Rolled back to version 1.14.10 which was the latest Safari-working version with my Caddy set-up. I fixed this issue before by manually manipulating Stalwarts CORS headers in Caddy https://github.com/bulwarkmail/webmail/issues/117

This time the Safari console is not showing any CORS errors like before...but again, no token is arriving. Weired.

@svandive are you using Safari as well? And maybe Stalwart behind a reverse proxy?

I am now trying to find how to adapt my Caddyfile this time.

@rathlinus I just discovered you did some security fixes effective version 1.4.11. So maybe this killed my Caddy "fix" (which I actually found with Claude as well... ;-) )

Safari has the most strict rules application (as of MDN Web Docs) of all major browsers. I think Stalwart and Bulwark should be able to deal with the standards out of the box without the necessity of workarounds. I am wondering where and how to adress this as it is impossible for production set-ups to dig into the whole stack configuration every time there is a new (minor) release. Adressing Apple would be a waste of time and effort. They'd ignore the submission or just refer to the MDN Docs...

I am a sys admin and no programmer which sometimes gives me a lack of understanding the underlying code base...so an idea how to solve this permanently for all upcoming versions is out of my caps I'm afraid.

Hopefully we could find a solution here. I'll do what I can to help.

[svandive]

The updated version built from "main" is working perfectly now!!

[MagnusFriendz]

I'll give it a try as well.

[svandive]

@MagnusFriendz
I am using Safari on a Mac, and my install lives behind Traefik as part of Pangolin (Pangolin uses Traefik under the covers). Stalwart and Bulwark both live in my home lab network but with a Public domain (wakefield.haus) that resolve to my Pangolin instance running on a VPS at AWS. I have had to work around a bug in Stalwart that makes an improper request for the preflight. the content-length of the preflight should be 0 (zero) but it's not so I use a header middleware on Traefik to set it to zero length before sending the preflight to Bulwark. Stalwart has fixed the bug, but it's not in a release yet.