Issue Description
POST /autodiscover/autodiscover.xml returns the same Outlook-schema response (IMAP/POP3/SMTP) whatever AcceptableResponseSchema the client asks for. A client that requests the ActiveSync schema (http://schemas.microsoft.com/exchange/autodiscover/mobilesync/responseschema/2006) gets HTTP 200 with a body it can’t use. Microsoft’s autodetect service then classifies the domain as Exchange ActiveSync. New Outlook for Windows stops autofilling the IMAP settings, and when the user picks IMAP or POP by hand it guesses imap.<domain>/pop.<domain>/smtp.<domain>.
Expected Behavior
Stalwart doesn’t implement ActiveSync, so a request whose AcceptableResponseSchema is the mobilesync schema should not get a successful reply. An Autodiscover error response or a non-2xx status would do. Clients and Microsoft’s autodetect service can then fall back to the IMAP/SMTP settings. More generally, a request for any response schema other than the Outlook one should not be answered with the Outlook body.
Actual Behavior
HTTP 200 with the Outlook response. The body is identical to the reply to a request for outlook/responseschema/2006a:
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
<Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
...
<Account>
<AccountType>email</AccountType>
<Action>settings</Action>
<Protocol><Type>IMAP</Type>...</Protocol>
<Protocol><Type>POP3</Type>...</Protocol>
<Protocol><Type>SMTP</Type>...</Protocol>
</Account>
</Response>
</Autodiscover>
Microsoft Remote Connectivity Analyzer (https://testconnectivity.microsoft.com), “Exchange ActiveSync” test, reports for this endpoint:
The Microsoft Connectivity Analyzer failed to obtain an Autodiscover XML response.
The Response element in the payload was null.
(It reads only a Response element in the mobilesync namespace, and there isn’t one.)
The “Outlook connectivity” test against the same endpoint gets the IMAP/POP3/SMTP settings as expected, so the Outlook path itself works.
Effect on Outlook
Microsoft’s cloud autodetect service is what new Outlook for Windows queries when adding an account:
curl -s 'https://prod.autodetect.outlook.cloud.microsoft/autodetect/detect?app=outlookdesktopBasic&services=office365,outlook,google,icloud,yahoo,imap,pop3,smtp&protocols=all&timeout=20' \
-H 'X-Email: [email protected]'
- Before
autodiscover.<domain>had a valid certificate, the service returned{"protocol":"imap","hostname":"mail.example.com","port":993,...}(plus SMTP and POP3), and Outlook autofilled them. - After, for every domain on the server:
{"protocols":[{"protocol":"eas","validated":false}]}. Outlook no longer autofills anything.
Reproduction Steps
-
Put
autodiscoverin a domain’s certificate subject alternative names, so thathttps://autodiscover.example.compresents a valid certificate. -
Send an ActiveSync Autodiscover request:
curl -s https://autodiscover.example.com/autodiscover/autodiscover.xml \ -H 'Content-Type: text/xml' \ --data '<?xml version="1.0" encoding="utf-8"?> <Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/mobilesync/requestschema/2006"> <Request> <EMailAddress>[email protected]</EMailAddress> <AcceptableResponseSchema>http://schemas.microsoft.com/exchange/autodiscover/mobilesync/responseschema/2006</AcceptableResponseSchema> </Request> </Autodiscover>'
Stalwart Version
v0.16.x
Installation Method
Docker
Database Backend
PostgreSQL
Blob Storage
PostgreSQL
Search Engine
PostgreSQL
Directory Backend
SQL
Additional Context
Client: new Outlook for Windows, Microsoft Outlook 1.2026.915.300 (client 20260918007.16, WebView2 154.0.4258.37). Account setup is driven by Microsoft’s cloud autodetect service (prod.autodetect.outlook.cloud.microsoft), not by the client probing the server itself.
Also verified with Microsoft Remote Connectivity Analyzer (testconnectivity.microsoft.com): the “Outlook connectivity” test gets the IMAP/POP3/SMTP settings from autodiscover; the “Exchange ActiveSync” test gets HTTP 200 with the same 1573-byte Outlook body and reports “The Response element in the payload was null”.
Network: Stalwart runs on Kubernetes. Port 443 is reached through HAProxy on a VPS in TCP mode with SNI routing (TLS passthrough), so Stalwart terminates TLS itself with its own ACME certificates (DNS-01). No HTTP reverse proxy rewrites the requests or responses. Four domains on the server; all show the same behaviour once autodiscover. is on the certificate.
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