Stalwart integration Showing CORS Error

[svandive]

I believe this project (Bulwark) is geared toward integration with a Stalwart JMAP mail server. However, no matter what I do, I can't seem to get around a CORS failure when trying to use Bulwark. I have Stalwart up and running with Bulwark on the same Docker host. However, whenever I try to log in to Bulwark, I receive the following error:

The server is reachable but is blocking cross-origin requests. Check your JMAP server's CORS settings and allow this domain.

Stalwart is configured with Relaxed CORS, and I can see the connection is properly passing the CORS header:
access-control-allow-origin: *

It more looks like a Stalwart issue, to be honest. It appears Stalwart is not building the pre-flight correctly for the https://mail.example.com/.well-known/jmap and is producing a 204 with a bad content length. Bulwark sees this as a CORS failure and stops.

Anybody else having issues getting Bulwark working with Stalwart and seeing a CORS failure?

[rathlinus]

What Bulwark is flagging there is not just a missing Access-Control-Allow-Origin header, but a browser-level refusal of the authenticated cross-origin request to /.well-known/jmap.

Bulwark does a browser-side GET to https://mail.example.com/.well-known/jmap with an Authorization header. That forces a CORS preflight on OPTIONS /.well-known/jmap. If that preflight is malformed, missing required allow headers, or gets rewritten by a reverse proxy, the browser blocks the real request and Bulwark surfaces it as the generic CORS error you saw.

So yes, this sounds more like a Stalwart or proxy-side preflight issue than a Bulwark-specific bug.

Things to verify:

• OPTIONS /.well-known/jmap returns a valid 200 or 204
• no invalid Content-Length
• Access-Control-Allow-Origin matches the Bulwark origin
• Access-Control-Allow-Methods includes GET, POST, OPTIONS
• Access-Control-Allow-Headers includes at least Authorization

Also, being on the same Docker host does not make it same-origin from the browser's perspective. webmail.example.com and mail.example.com are still cross-origin.

If you have nginx, Traefik, Caddy, Cloudflare, or another proxy in front of Stalwart, I would inspect that layer first. It is very plausible the proxy is generating or altering the OPTIONS response for /.well-known/jmap.

As a workaround, putting Bulwark and the JMAP endpoint behind the same origin avoids the browser CORS path entirely.

[fuegoio]

I had to add in the Stalwart configuration http.permissive-cors = true for this to work.

My Bulwark and Stalwart are on two different origins. I think it's hard to have both on the same origins as you need to enumerate which path goes to Stalwart for JMAP explicitely.

[europacafe]

http.permissive-cors = true is there. I don't have a problem with browsers on Windows, but I have the cors problem with iOS Safari/Edge/Chrome. Strange

[svandive]

Safari is much more strict. Since it’s a content-length issue in the preflight CORS check, Safari browsers will drop the whole thing which Bulwark registers as a CORS issue since it dies on the preflight. Firefox and Edge are less strict about it. Unfortunately, on iOS, all browsers have to use Apple’s WebKit, which means materially under the hood, Firefox on iOS is just Safari with a skin on it.

[svandive]

I ended up adding a middleware header rewrite to Traefik to null out the content length. This has resolved my issue for now. I’ve also opened an issue on Stalwart to get them to address the RFC violation.

[CaptnAdhok]

I ended up adding a middleware header rewrite to Traefik to null out the content length. This has resolved my issue for now. I’ve also opened an issue on Stalwart to get them to address the RFC violation.

Hello and thanks for your answer. How did you do that please ?

[svandive]

I’m running Pangolin as the Proxy, which uses Traefik under the hood. I added a service called middleware manager to my Pangolin / Traefik container. This was necessary because of how Pangolin and Traefik share configurations. However, with just Traefik, you should be able to load the “header” middleware and configure it to set the content-length to “”. This sets it to zero as it should be in a Preflight.

However, I will say version 0.16 of Stalwart has corrected this bug and works now without having to have the header rewrite in place.

If you need additional details, let me know. I don’t have access to my setup at the moment, but I can help answer questions this evening if you have any. .

[CaptnAdhok]

on v0.16 you can inject headers directly from stalwart.
The problem is i'm on v0.16 and i still can't access stalwart from bulwark.

[ChiliBen]

on v0.16 you can inject headers directly from stalwart. The problem is i'm on v0.16 and i still can't access stalwart from bulwark.

!!!DO NOT DO THIS!!!

content-length: 0 will be injected into every response, including the admin UI — so the browser receives the HTML shell but reads zero bytes of it. You will essentially be locked out of the admin UI, and stalwart-cli doesn't handle this gracefully either.

You can recover by clearing responseHeaders via the JMAP API using your admin credentials:

curl -sk --ignore-content-length --http1.0 -u "admin:changeme" -X POST -H "Content-Type: application/json" -d '{"using":["urn:stalwart:jmap"],"methodCalls":[["x:Http/set",{"update":{"singleton":{"responseHeaders":{}}}},"0"]]}' https://mail.example.com/jmap

The --ignore-content-length and --http1.0 flags are both required:

--ignore-content-length tells curl to read past the header
--http1.0 forces the server to close the connection after responding so curl gets an EOF instead of hanging indefinitely. Technically irrelevant, but you need it to see if you get a clean response.

You'll know it worked if you get back something along the lines of

{"methodResponses":[["x:Http/set",{"accountId":"*******","updated":{"singleton":null}},"0"]],"sessionState":"********"}

[svandive]

My header adjustment to set the length to zero was specific to the path for /.well-known/jmap in Traefik.