Jolla Phone 2026: IMAP Push not working with Stalwart Mail Server

REPRODUCIBILITY: Yes
OS VERSION: 5.2.0.22 (Finlayson)
HARDWARE: Jolla Phone (2026)
UI LANGUAGE: German
REGRESSION: Unknown; no comparison with an earlier release available

DESCRIPTION:

IMAP synchronization with a Stalwart server fails after enabling push and then fetching mail. Restarting messageserver5 or rebooting the phone did not resolve the failing state.
During failed attempts, Sailfish establishes TLS on port 993, successfully completes CAPABILITY, and then sends no LOGIN or AUTHENTICATE command. Stalwart eventually closes the unauthenticated connection with * BYE Connection timed out.
The failure was reproduced by switching the sync frequency to “Always” (push) and then fetching mail. Manual synchronization with push disabled or set to a fixed interval succeeded.
On a second account (mailbox.org) IMAP push works as expected.
Thunderbird on a desktop works with the Stalwart account, including push.

PRECONDITIONS:

  • A general IMAP email account hosted on Stalwart, using implicit TLS on port 993 and password authentication.
  • Stalwart runs in Docker. Stalwart version: 1.0.1.
  • Two IMAP accounts are configured on the phone: the affected Stalwart account and a working a second IMAP provider (mailbox.org) account.
  • Thunderbird on a desktop works with the Stalwart account, including push.

STEPS TO REPRODUCE:

1. Configure the Stalwart account with push disabled (sync frequency “Off”) and establish a working manual sync. In this investigation, re-saving the password followed by “Synchronize now” restored a working sync.

2. Change the affected account’s sync frequency to “Always” (push).

3. Fetch mail from the affected account in the Mail app.

4. Observe the messageserver log: TLS and CAPABILITY succeed, but the client does not proceed to LOGIN/AUTHENTICATE. In earlier complete failures, Stalwart closed the unauthenticated connection after approximately one minute.

5. Restarting messageserver5 or rebooting the phone did not clear the previously observed failing state.

Recovery/testing observations:

- Disabling push appeared to allow manual synchronization to work.

EXPECTED RESULT:

Both manual and automatic synchronization continue to work after initial account setup. With push enabled, the client authenticates and establishes IMAP IDLE monitoring, and new messages appear.

ACTUAL RESULT:

In the failing state, the client repeatedly stops after successful CAPABILITY, without sending an authentication command. The server closes the connection after the unauthenticated-session timeout. Sailfish reports unsuccessful actions and retries push with increasing delays.
The second account on a second IMAP provider successfully authenticates with PLAIN, establishes IDLE, and completes QRESYNC during the same logging session.

MODIFICATIONS:

Diagnostic changes made during investigation:

  • Enabled file logging in ~/.config/QtProject/Messageserver.conf.
  • Enabled IMAP, Messaging, POP and SMTP log categories.

ADDITIONAL INFORMATION:

Relevant excerpts from 29 October 2026. Times below are UTC (CET = UTC + 1 hour). Account ACCOUNT_A is the affected Stalwart account; account ACCOUNT_B is the working comparison account. Personal addresses and hostnames are omitted. Account, credential, action, mailbox UID and modification-sequence identifiers are replaced with consistent placeholders. Timestamps are retained for diagnostic correlation.
Failed Stalwart attempt:

12:14:09 SSO: starting credentials retrieval.
12:14:09 IMAP : Secure connection established
12:14:09 RECV: * OK [CAPABILITY IMAP4rev2 IMAP4rev1 ENABLE SASL-IR LITERAL+ ID UTF8=ACCEPT AUTH=PLAIN AUTH=OAUTHBEARER AUTH=XOAUTH2] Stalwart IMAP4rev2 at your service.
12:14:09 SEND a001 CAPABILITY
12:14:09 RECV: * CAPABILITY IMAP4rev2 IMAP4rev1 ENABLE SASL-IR LITERAL+ ID UTF8=ACCEPT AUTH=PLAIN AUTH=OAUTHBEARER AUTH=XOAUTH2
12:14:09 RECV: a001 OK CAPABILITY completed
12:14:10 SSO: got response.
12:15:09 RECV: * BYE Connection timed out.
12:15:09 socketError: 1 : "The remote host closed the connection"
12:15:09 Action completed ACTION_FAILED_INITIAL result failure

No AUTHENTICATE or LOGIN command occurs between CAPABILITY and the timeout. Subsequent failed attempts include SSO: init credentials while status 2.
Successful Stalwart attempt after disabling push and selecting “Synchronise now”:

12:20:11 Received new idleState for account: ACCOUNT_A state: false profile type: "syncemail"
12:20:13 SSO: init credentials while status 2
12:20:13 SEND a002 AUTHENTICATE PLAIN <password hidden>
12:20:13 RECV: a002 OK [CAPABILITY ...] Authentication successful
12:20:13 SEND a003 ENABLE QRESYNC CONDSTORE
12:20:13 RECV: * ENABLED QRESYNC
12:20:13 RECV: a003 OK ENABLE successful.
12:20:13 SEND a004 LIST "" "*"
12:20:13 RECV: a004 OK LIST completed
12:20:13 SEND a005 SELECT INBOX (QRESYNC (<UIDVALIDITY> <MODSEQ> <KNOWN_UIDS>))
12:20:13 RECV: a005 OK [READ-WRITE] SELECT completed
12:20:13 Action completed ACTION_SUCCESSFUL_SYNC result success
12:20:23 RECV: a009 OK LOGOUT completed

The excerpts are shortened and anonymised; the capability list in the successful authentication response is abbreviated. Angle-bracket placeholders replace private or account-specific values and are not literal protocol data. SSO: init credentials while status 2 appears in both failed and successful attempts, so it alone does not identify the fault. The successful attempt confirms that PLAIN authentication and QRESYNC can work for the affected account.
Latest reproduction: enabling push, then fetching mail (29 October 2026):

12:34:26 Received new idleState for account: ACCOUNT_A state: true profile type: "syncemail"
12:34:26 IDLE Session: Opening...
12:34:27 IDLE session opened, state IdleNetworkSession::State(Connected)
12:34:36 Running action RetrieveMessageListRequest ACTION_FAILED_PUSH
12:34:36 Creating SSO identity for the service "imap4" from account ACCOUNT_A with creds id CREDENTIAL_A
12:34:36 SSO: init credentials while status 2
12:34:36 IMAP : connection established
12:34:36 IMAP : Secure connection established
12:34:36 RECV: * OK [CAPABILITY IMAP4rev2 IMAP4rev1 ENABLE SASL-IR LITERAL+ ID UTF8=ACCEPT AUTH=PLAIN AUTH=OAUTHBEARER AUTH=XOAUTH2] Stalwart IMAP4rev2 at your service.
12:34:36 SEND a001 CAPABILITY
12:34:36 RECV: * CAPABILITY IMAP4rev2 IMAP4rev1 ENABLE SASL-IR LITERAL+ ID UTF8=ACCEPT AUTH=PLAIN AUTH=OAUTHBEARER AUTH=XOAUTH2
12:34:36 RECV: a001 OK CAPABILITY completed
12:34:36 "1 End:" "Capability" "OpOk"
12:35:37 RECV: * BYE Connection timed out.
12:35:37 socketError: 1 : "The remote host closed the connection"
12:35:37 Push email connection could not be established. Reattempting to establish in 30 seconds
12:35:37 Action completed ACTION_FAILED_PUSH result failure

This latest excerpt includes the complete failure: CAPABILITY succeeds at 12:34:36 UTC, no authentication command follows, and Stalwart closes the connection at 12:35:37 UTC (approximately 61 seconds later). Sailfish records a failed action and schedules a retry after 30 seconds. IdleNetworkSession::State(Connected) is not proof of an authenticated IMAP IDLE session: no AUTHENTICATE or IMAP IDLE command is shown for this attempt.

1 Like

What are authentication methods for accounts.

devel-su -p ag-tool list-accounts

devel-su -p ag-tool list-settings <id> | grep -i authentication

See [5.2.0.16][JP26] IMAP Mail Account from SFOS Backup can't send Mails - #14 by nephros

The authentication outputs are the same for the Stalwart account as well as the mailbox.org one (which works well):

smtp/authentication = 2
imap4/authentication = 2

Could you provide the same logs for mailbox with push enabled ?

I have an hypothesis of the reason why it fails: in the idle code path, the login is sent after the idle folders have been established. But the folder idling is started only if the CAPABILITY reports IDLE. But it seems that this capability is reported after login by Stalwart. This case seems not handled by the code… If mailbox.org reports IDLE in its capabilities before logging in, that may explain.

In IMAP4rev2 idle is mandatory and won’t be reported on CAPABILITY command.

Thanks for the hint. I’ll adjust the code accordingly.

Edit: here is the patch https://codereview.qt-project.org/c/qt-labs/messagingframework/+/784851

Regarding Stalwart Server, are there any plans for JMAP support?