1
Are Shared Hosters supporting MAPI and ActiveSync?
Question asked by Howell Dell - 5/24/2023 at 7:30 AM
Unanswered
I am getting more and more requests for MAPI and ActiveSync when using the new versions of Outook as customers want that O365 capability like being on Exchange. This is also part of the marketing of SmarterMail BTW.

ActiveSync generally works great and does not have any issues with Autodiscover plus I can easily perform a Manual Setup to override AutoDiscover. However, some versions of Exchange support in gMail for various Android platforms could be better. I am thinking about looking at eM Client.

The issue for me is older (I am on Build 8025) versions SmarterMail are not compatible with the latest Outlook that is part of Microsoft 365. Now the latest Build 8538 appears to work but has some teething issues as the MAPI has been updated. I am confident that SmarterMail will get this all worked out, however, my +40 domain customers on my Shared SmarterMail don't want to hear about teething issues.

I am eyeing upgrading to Build 8451 (Feb 20, 2023) and Build 8251 (Aug 4, 2022).

Moreover, Microsoft insists that the Autodiscover FQDN matches the FQDN if the MRS IIS Web Site for autodiscover.<customer-domain>, for <customer-domain>/autodiscover/autodiscover.xml and then you have the DNS SRV record which seems to want autodiscover.<customer-domain>.

How are Shared Hosters dealing with this issue? We don't seem to have any documentation? What about setting a dedicated MRS IIS on the same SmarterMail Server for each client so that autodiscover works correctly for MAPI?

Does anyone have solutions or recommendations for me on a)solve the autodiscover issue and b) BUILD Version.

26 Replies

Reply to Thread
0
Howell Dell Replied
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?
0
We are running it as a shared server and run 8538 currently with no issues in a std. MAPI environment.
0
Howell Dell Replied
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.
0
I run seperate certificates for each domain in IIS.
0
Howell Dell Replied
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?
0
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.


0
Howell Dell Replied
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.

0
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.
0
Heimir Eidskrem Replied
We do shared hosting and certify the web (letsencrypt).  100 fqdn per cert.  

1
Ben Replied
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.
0
We use the same setting as Ben for many different customers.

No issue reported.
Gabriele Maoret - Head of SysAdmins at SERSIS
Currently manages 3 SmarterMail installations (1 in cloud for SERSIS which provides service to a few hundreds 3rd party Mail Domains + 2 on premise to customers)
0
Wont you get a certificate error doing it that way??
0
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…
Gabriele Maoret - Head of SysAdmins at SERSIS
Currently manages 3 SmarterMail installations (1 in cloud for SERSIS which provides service to a few hundreds 3rd party Mail Domains + 2 on premise to customers)
0
Hmmm thats a game changer..... i always beleived we needed a certificate for autodiscovery on the server for any domain resident....

That changes things.....
0
Howell Dell Replied
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 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.
0
Reto Replied
> I'm not sure what the programmatic flow path for Outlook code to look at the DNS SRV 
> record. Is that first or last?

I assume Outlook is working more or less like the Microsoft Remote Connectivty Analyzer. The steps outlined in the test are:
- Attempting to contact the Autodiscover service using the HTTP redirect method. autodiscover.example.com
- Attempting to contact the Autodiscover service using the DNS SRV redirect method.

I assume different version of Outlook do it differently, but I would expect that the DNS SRV is always last. 
0
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?
0
Reto Replied
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.
1
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.
0
Reto Replied
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).
0
Ben Replied
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.
0
Howell Dell Replied
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.

1
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):
0
Karl Jones Replied
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.
1
Howell Dell Replied
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.
0
Howell Dell Replied
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?

Reply to Thread