NB: https://portal.smartertools.com/community/a95385/8538-issue-with-relative-url-paths.aspx talks about using SmarterMail with a Reverse proxy. That could be an idea, however, with Build 8538 it seems SmarterMail is not fully compliant with relative URLs.

How does one implement a Proxy on IIS and could this solve my AutoDiscover issue?

We are running it as a shared server and run 8538 currently with no issues in a std. MAPI environment.

To Brian Bjerring-Jensen: Are you doing Shared Hosting? If so how do you manage the multiple customer autodiscover FQDN as Outlook requires the customer FQDN to be listed in the Cert? I have +40 Domains so I can store all of that in one Cert.

I run seperate certificates for each domain in IIS.

To Brian Bjerring-Jensen:  Are you do this in an automated fashion or manual? Please elaborate in more detail if you desire.

I am guessing you are saying for the customer specific IIS Bindings you have a dedicated Certificate then pick that from the Certificate Store? I don't think I can do that with Certify the Web. Are you using ACME Certs or have you choose another method?

I use certificates from Digicert and the process is manual from our side.

It takes about 5 mins to install. You just need it as a .pfx file. Digicert has a utility to convert a .cer.

OK. I just tested this manually using Certify the Web Site by creating a standalone IIS Virtual Server for the customer FQDN. Then I went back to manually add customer FQDN back to the main IIS SmarterMail Virtual Server. It seems to work... I have more testing to do...

The bigger issue is late M365 (aka O365) Outlook does not like SmarterMail Build 8025.

We run Office 2021 LTSC on all our customers and not O365 for that reason and #gdpr as well.

We have disabled quite a lot of telemetry also.

We do shared hosting and certify the web (letsencrypt).  100 fqdn per cert.  

I do shared hosting and don't need to setup any of that.

I just have our main mail domain (mail.hostingcompany.com) and a SRV record for each customer domain...

MAPI autodiscover works fine with this.

We use the same setting as Ben for many different customers.

No issue reported.

Wont you get a certificate error doing it that way??

No certificate errors and everything works fine. Tested now with a random customer account on MY PC using Outlook 365.

NOTE: This is with my CLOUD server with SmarterMail 8451, I will upgrade this server in 10-15 days to SM 8538 if no new serious bugs are discovered…

Hmmm thats a game changer..... i always beleived we needed a certificate for autodiscovery on the server for any domain resident....

That changes things.....

Yep, I was told also you need autodiscover.<customer-fqdn> DNS record plus redirect from 

http[s]<customer-fqdn>/autodiscover/autodiscover.xml to SmarterMail.

Without the above Autodiscover DNS records and redirect you risk a credential leak. Are folks aware of the now 1.5 to 2 Year Autodiscover BUG? The Outlook Autodiscover has an FQDN “back-off” procedure. This “back-off” mechanism is the culprit of credential leak because it is always trying to resolve the Autodiscover portion of the domain and it will always try to “fail up,” so to speak trying at first: https://Autodiscover.example.com/Autodiscover/Autodiscover.xml, then http://Autodiscover.example.com/Autodiscover/Autodiscover.xml,

then https://example.com/Autodiscover/Autodiscover.xml,

then http://example.com/Autodiscover/Autodiscover.xml
and notice both https and http are attempted.

Worse yet, the credentials are sent from Outlook clients to the request URL with an HTTP Basic authentication header which includes the hapless user's Base64-encoded credentials. DUMB!

I'm not sure what the programmatic flow path for Outlook code to look at the DNS SRV record. Is that first or last?

Some are saying the M$ Code in Outlook was poor and then tried autodiscover.[tld] as well. Some hackers had purchased some of these domains. Over a year ago Microsoft had registered some 68 domains related to Autodiscover. It is NOT clear what Micrsoft has done to resolve the poor Autodiscover implementation in their Microsoft Outlook and Office 365 mail clients to resolve the issue further. 

Anyone know of a CVE assignment for this issue and its resolution?

The question becomes is what you are saying is a good idea or not relative to the security concern...  I will see if I take a current version of Outlook and capture its network traffic.

> I'm not sure what the programmatic flow path for Outlook code to look at the DNS SRV 

I assume Outlook is working more or less like the Microsoft Remote Connectivty Analyzer. The steps outlined in the test are:

So youre saying that the ones only using SRV records in their way of handling autodiscovery would potentially leak all the MAPI users passwords since SRV records are served as the last option?

I have read the article from Guardicore and some other publications. It's not clear if the findings of Guardicore are true. I have seen contradicting evidence by some other people. The fact that there is no CVE for this seems to indicate that this "back-off" is not a problem. It could be that some non microsoft implementations of autodiscover did try to connect to such "back-off" domains, but it seems that Microsoft is not one of them.

You can follow the way it checks for connectivity here...

https://testconnectivity.microsoft.com/tests/Ola/input

then it will tell you in what order it tries to connect.

Yes, the Connectivity Analyzer show more or less how it works. But there might be Outlook versions that did it different and there have been other vendor implementations that did it different and wrong (for example old Samsung Phones and Apple Mail on iOS).

I'm not sure how big of a deal this is though - generally for shared hosting, the admin of the website has admin access to the mail service anyway so nothing is going to be leaked.

The only way this seems that it could be an issue is if different people look after the website and mail services. In which case the web guy could capture the domain.com/autodiscover traffic. But then I don't see the way around that.

If it was solely the autodiscover.domain that was the problem, that could be protected by the website people not having DNS access.

If understand correctly the leak occurs when the autodiscover.xml is accessed because Outlook passes the credentials on each try which maybe in the clear as well.

This also means if you have hosting separation between the corporate web site and SmarterMail then the corporate web site could proxy or simply capture the XML data interchange thus get the credentials. Another thing is we know that corporate web sites can be accessed improperly then hackers can and do insert code for any number of nefarious purposes.

Since nobody made a CVE about and neither did Microsoft the issue has faded into the background and we don't know what has happened unless we test.

What we need to do is come up with a community standard that promotes best practices and some kind of codebase to automate this process.

I add this to every users registry before setting up the account to avoid leaking credentials.

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Outlook\AutoDiscover]
"ExcludeExplicitO365Endpoint"=dword:00000001
"ExcludeHttpRedirect"=dword:00000001
"ExcludeHttpsRootDomain"=dword:00000001
"ExcludeScpLookup"=dword:00000001

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Outlook\AutoDiscover\RedirectServers]
"smartermail.cloudpros.dk"=hex(0):

Here is a good tool to test Autodiscovery if anyone might need it.
https://www.priasoft.com/autodiscover-testing-tool/ It also has the advance options to create the Registry entries mentioned above and then some.

I appreciate the RegEdit, however, I'm sure how helpful that is when you are trying to deploy to end customer's Windows PCs that you don't have administrate rights. Sometimes I do have access and most times I do not.

For https://www.priasoft.com/autodiscover-testing-tool/; do we know anything about the Priasoft, Inc of Tempe, AZ. I have to look at this tool, however, do we trust them because I assume you have to provide username and password to test the eMail Server?