mujmap icon indicating copy to clipboard operation
mujmap copied to clipboard

Sync with Fastmail fails with 403 error

Open ntrocado opened this issue 3 months ago • 1 comments

$ mujmap sync -v
error: Could not sync mail: Could not index mailboxes: Could not complete API request: https://api.fastmail.com/jmap/api/: status code 403

I've been getting this error message for a couple of days. I made no changes to my system, and I confirmed that the api token is still valid through the fastmail web app.

Any ideas?

ntrocado avatar Sep 07 '25 11:09 ntrocado

I am also running into this issue. Have not had time to diagnose

Lyndeno avatar Sep 18 '25 18:09 Lyndeno

Using mujmap -vv sync yields a flow that looks like:

GET https://api.fastmail.com/.well-known/jmap => 302
GET https://api.fastmail.com/jmap/session => 401
GET https://api.fastmail.com/jmap/session => 200
POST https://api.fastmail.com/jmap/api/ => 403

This looks to me like it makes sense. 302 Found to move from well-known resource marker to actual location. 401 Auth Required to flag that client should auth. 200 OK to indicate that my session is established. Of course, it all falls down when we hit 403 Forbidden.

After setting up an expect() in get_mailboxes(), I see that last has error text content of "Forbidden":

thread 'main' panicked at src/remote.rs:615:14:
get_mailboxes request() failed: Request { source: Status(403, Response[status: 403, status_text: Forbidden, url: https://api.fastmail.com/jmap/api/]) }

and the request that gets the 403 response is issued with a payload identical-ish to aerc:

[["Mailbox/get", {"accountId": "<<id>>", "properties": ["id", "parentId", "name", "role"]},"0"]]

I've tried forcing properties to None to omit that stanza (so the request would be Actually Identical to the one I see aerc issuing) but that doesn't change anything. In a fit of desperation I even tried modifying the User-Agent away from "ureq/2.4.0" in case that was it.

I can't see much difference in the request that succeeds (establishing a session, so I know my creds aren't borked) and the one that fails (asking for Mailboxen). I think my next avenue would likely be to check in on what's happening with update_session_state() since it looks like the session is established but I'm not sure if that's well-founded?

Additionally, replacing the Mailbox/get with an Identity/get doesn't help.

Hajitorus avatar Nov 18 '25 10:11 Hajitorus