I was trying to make sense of the GuardiCore blog post. They claim domain stripping when Autodiscover URIs "don't respond". They do not explain whether they mean NXDOMAIN, HTTP-5xx, HTTP-4xx or HTTP-2xx-with-wrong-content. Anyway, we can pretend it means there was no halfway sensible AutoDiscover XML response. One thus arrives at the first conclusion that the server plays no role in the bug, whether it's Exchange or grommunio/Gromox. It also fits one's general intuition that backoff algorithms generally are sender-side (think TCP's backoff as result of congestion).
At this time however, I cannot confirm there is an information leak in the client side. I tried with Outlook 2019 (16.0.10378.20029) & Wireshark. Note that is different from the versions GC used themselves (16.0.13901) and what they observed (16.0.9029), so I am not sure what to make of it. I observed:
- Adding a MAPI profile through Outlook's blue dialog
foobar@haha.asdfxxx.com.br (non-existing zone) has only produced the three DNS queries IN A haha.asdfxxx.com.br, IN A autodiscover.haha.asdfxxx.com.br, IN SRV _autodiscover._tcp.haha.asdfxxx.com.br. No attempt was made to even resolve autodiscover.asdfxxx.com.br or autodiscover.com.br.
- Adding a MAPI profile, again through the blue dialog, with an existing domain, e.g.
foobar@nflchallenge.com.br, the same occurs, there are only those three DNS queries, to nflchallenge.com.br, autodiscover.nflchallenge.com.br and _autodiscover._tcp.nflchallenge.com.br.
- Adding a MAPI profile through Control Panel ("E-mail (32-bit)" or what-have-you) leads to a few more lookups, specifically the hostnames
imap, pop3, smtp and mail within nflchallenge. Once again it did not inquire about autodiscover.com.br.
I also find no mention of the word "back-off" in the MS-OXDISCO and MS-OXDSCLI specification, and GC would do good in providing a pointer.
