"New" Microsoft Outlook sync issues

Issues
1

Issue Description

When adding an account in the new Microsoft Outlook / Microsoft Mail client (the ones which essentially use Office 365 as a sync backend), it fails to work due to Microsoft incorrectly following the UID behaviour RFC.

They issue ENABLE UIDONLY then proceed to use normal sequencing, and disconnect when the server (correctly) rejects.

In order to support these clients we will require the ability to either disable UID capability, or even better … disable UID capability for a subset of connections.

Expected Behavior

Microsoft servers are able to connect, sync, and retrieve mail for clients.

Actual Behavior

Microsoft servers connect via IMAP, and then disconnect.

Reproduction Steps

  1. Configure stalwart
  2. Add account to Microsoft Mail or Outlook as IMAP
  3. Observed error

Stalwart Version

v0.16.x

Installation Method

Docker

Database Backend

RocksDB

Blob Storage

RocksDB

Search Engine

Internal

Directory Backend

Internal

Additional Context

Note there was a github entry raised for this by someone: UIDONLY enabled by new Outlook/Outlook.com IMAP sync client, then violated — causes BAD ... UIDREQUIRED and breaks sync · Issue #3332 · stalwartlabs/stalwart · GitHub

I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.

on

I have searched this support forum (open and closed topics) and confirm this is not a duplicate.

on

I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.

on

2

There’s no documented option to disable the UIDONLY/UID-related capabilities (or restrict them per-client) in the current Imap settings object — only timeouts, rate limits, and UID batch sizing are configurable. There is no setting to disable the UIDONLY capability globally or for a subset of connections.

This isn’t covered in the current docs. A community member or staff member will follow up.

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.

3

Same issue here, now confirmed with event-level logging on v0.16.26 (FoundationDB, 2 nodes, Docker/K8s). We upgraded from 0.16.20 because thread 1462 reported 0.16.21 as fixed — it isn’t for us.

Microsoft’s hosted sync for the new Outlook (52.98.221.205 / 52.98.222.229, EHLO *.prod.exchangelabs.com) does, in 3 of 3 sessions:

IMAP ENABLE command (imap.enable) ... details = ["CondStore", "UidOnly"]
IMAP error occurred (imap.error) ... details = "Message numbers are not allowed once UIDONLY is enabled.", code = "UIDREQUIRED", type = "BAD", id = "WIR00007"

After that it disconnects and retries roughly every 30 minutes; the Inbox never syncs, and mail composed in Outlook is never submitted (SMTP 587 STARTTLS + AUTH succeed at account setup, but no submission follows).

UIDONLY is advertised unconditionally to authenticated sessions (imap-proto/src/protocol/capability.rs) and ENABLE UIDONLY is accepted (imap/src/op/enable.rs), unchanged up to 0.16.26. Strict enforcement is RFC-correct, but in practice it makes the new Outlook unusable with Stalwart. Could you add an option to not advertise/accept UIDONLY (globally or per listener), or degrade gracefully instead of returning BAD? Happy to test a build.

4

Please report this bug to Microsoft, they are non-conformant. RFC 9586 §3 says:

the client MUST NOT use message sequence numbers (including the special marker “*”) in any arguments to IMAP commands, and the server MUST return a tagged BAD response if the client uses message sequence numbers. The server MUST include the UIDREQUIRED response code in such BAD responses

If we stop advertising UIDONLY we are disabling the extension for all clients that use it properly, such as Apple Mail.

5

I created a post in the Microsoft Feedback Portal: Community - not sure if it helps.