@Filip_Navara Yes, but for some reason according to the OP this is triggering eM Client to open a Microsoft login for OAuth verification, even though the autodiscover is only used for ActiveSync and doesn’t support Outlook-style requests. The only work around would be to remove the autodiscovery DNS entries to force eM Client to use other means of discovery to correctly discovery IMAP/SMTP using non-Oauth (basic) authentication for email. If the providers.xml worked based on the MX server IP address as mentioned in the prior response, that would cause the auto-discovery to use the providers.xml for the IMAP, SMTP, CALDAV, and CARDDAV server settings, which would be the fastest and most complete method of auto-discovery.
@Filip_Navara What does eM client use for auto discovery of the CalDAV and CardDAV servers then (especially if the server for CalDAV/CardDAV is different from the IMAP/SMTP server)? Only providers.xml? That is usually the purpose of those service records when alternatives like providers.xml doesn’t exist.
Domain name. There’s no secondary lookup.
We can add mail.imageway.com as MX lookup to providers.xml and update it for existing customers. It would not work if they use a redirect by CNAME in DNS, if I remember correctly.
The OP is triggering it because they previously used Microsoft 365 on the same domain. Since Microsoft didn’t completely wipe that information from their Autodiscover endpoint yet it still triggers the M365 flow.
Our recommended flow for this use case is to use _autodiscover._tcp SRV records pointing to the correct URLs since that gets a priority. Unfortunately, the ImageWay Autodiscover endpoint supports ActiveSync only so this method doesn’t work. Many other providers implement the full Autodiscover specification including the Outlook-style responses, or they use 3rd-party solutions like automx/automx2 software.
While providers.xml is also a way to bypass the whole Autodiscover mechanism for known providers we don’t recommend it, precisely because it only supports limited scenarios for hosted domains.
The Microsoft Autodiscover specification is extensible. We implement “CalDAV” and “CardDAV” service types returned from the autodiscover.xml endpoint. In fact, providers.xml uses subset of the same response syntax:
<Protocol xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
<Type>CalDAV</Type>
<Server>https://sync.imageway.com/cal/</Server>
<DomainRequired>on</DomainRequired>
</Protocol>
<Protocol xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
<Type>CardDAV</Type>
<Server>https://sync.imageway.com/abk/</Server>
<DomainRequired>on</DomainRequired>
</Protocol>
We updated our providers.xml to include the match by mail.imageway.com MX record. The change will be available in next v10 beta/release. We will deploy it to our servers next week and it should propagate to existing customers with v10 beta and v9.2.
1 Like
@Filip_Navara Yes, can you please replace the current ‘imageway.com’ in the providers.xml with ‘mail.imageway.com’, and use the same configuration information that is setup. Most Imageway customers do use the Imageway MX server domain name, so that change would allow the providers.xml to work with most of the custom domain names.
So the providers.xml is something that can be pushed to update on existing installs?
That makes sense, so once the information is completely wiped from the Microsoft Autodiscover endpoint then that wouldn’t happen. Thanks for clarifying.
Yes you are correct, the ImageWay Autodiscover is a limited implementation because it was only used for the ActiveSync gateway to the IMAP/SMTP/CALDAV/CARDDAV back-end. The only reason for even supporting ActiveSync was because iOS doesn’t allow IMAP IDLE. So the ActiveSync was made available for iOS users that require push based updates of email, since that was the only way to do it besides a ugly hack to use Apple’s proprietary push update system.
It sounds like in this OP case, one option would be to use the providers.xml (once you add the ImageWay MX to providers.xml and push it) until Microsoft completely wipes that information from their Autodiscover endpoint. Second option would be to remove the autodsicovery DNS information for the OP’s custom domain so it doesn’t even check the auto-discovery.
Thanks for your input on this topic and getting the providers.xml setup correctly (using the MX server) for Imageway.
@Holbourn This is your issue. As explained by @Filip_Navara, your custom domain information is still in the Microsoft Autodiscover endpoint. Once this information is removed by Micorsoft for your domain, the issue should go away.
To work-around the issue, the Autodiscovery DNS entries for your custom domain were removed, so that it hopefully doesn’t trigger the email client to check the Microsoft Autodiscover endpoint. When it comes to eM Client specially, the other option is to get the providers.xml to work for Imageway customers with custom domains, which is something eM Client is going to adjust so it will work with your domain. This update should propagate over the next several weeks to eM Client.
So it is stale Microsoft account information that is causing your specific issue with the Autodiscovery not working in the correct way with your custom domain name and Imageway email hosting. Hopefully the workarounds do the job until Microsoft does theirs and removes that old information from their Autodiscovery endpoints for your custom domain name.
Thank you @Filip_Navara for providing the details needed to diagnose and provide a fix to providers.xml. Your help has been greatly appreciated.
@Filip_Navara So based on what your saying, even if the " _autodiscover._tcp" DNS entries are removed, it still checks the Microsoft servers for the domain, correct?
If that is the case then the only fixes would be for the OP (@Holbourn) to get Microsoft to remove their domain name from their systems, or to get the providers.xml to work, which should start working once it gets pushed with the update using the Imageway MX server rather then the “imageway.com” domain name.
Many thanks to you, @Filip_Navara, and Imageway Support for spending so much time digging into this. I guessed that that old account was at the root of the problem, but it is a huge relief to know for sure and understand it, even if the issue will persist for a little while longer! In the meantime I’ll keep an eye on the beta release page.
Thank you!
1 Like
Hi,
Thank you for the work you have put into this!
I have just installed the latest release; 10.0.2934 (40de744) and the auto-discovery function worked flawlessly.
Notes. Before installing the new release:
- I uninstalled the previous version including the database.
- I flushed the DNS cache per one of Imageway’s earlier recommendations.
- Before installing this release, I had been able to get the calendar and contact modules to work as individual accounts, but I had to use ‘clean links’. I was unable to get them to work using links copied from emails, etc. (I’m not sure if this info is helpful or not.)
I will post a note in October when the old MS 365 account should be fully deleted using a different client’s auto-discovery to verify our assumptions are correct, in case the information is useful to anyone.
In the meantime I am delighted to be using eM Client and Imageway as intentended having the issue understood and solved.
Thanks again!!!
1 Like