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.

[europacafe]

Thanks.
update: after inspecting the network traffic, it always reports content-length:78 of its response header, for preflight request, even there is no content. As you suggested, I null it out at my Haproxy (reverse proxy) backend.