• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Forwarded to devs Autodiscover not working properly on Outlook

I want to say that we know about this issue and hear you.

We tried to find a proper solution for this issue but have no luck on the way.

Mail Autodiscover works well for old mail clients like Outlook 2016 but facing issues with the auto-configuration of Microsoft O365/2019 mail clients. The issue exists because these mail clients do not request a mail configuration directly from a Plesk server but instead using Microsoft cache servers for such purposes.

Also, it's important to note that the issue exists mostly for MS Office Pro mail clients, based on our tests of possible configurations:
mail_auto2019.png

Microsoft Support suggested for us reactive solution only: when mail autodiscover failed for a customer, you can
bypass using an MS proxy server by adding a registry key to the Outlook client (using Registry on a local machine):
-----
HKEY_CURRENT_USER\Software\Microsoft\Office\x.0\Outlook\AutoDiscover
Name : ExcludeExplicitO365Endpoint

Value : 1
------
Then a mail configuration will be requested directly from a Plesk server.

This solution is not suitable for us, but it's the best that we have for now. We continue communication with Microsoft with the hope of solving the issue.

But preliminary summary, that the new Outlook doesn't support autodiscovery for non-MS services (not Exchange servers).
 
I see your point Anthony,
But auto-configuration is working just fine on CPanel hosted emails and every other shared hosting provider I know.
it should be something done within the server, not on the client/user side.
 
I don't think a customer wil be very willing to add a key to their Windows registry. A lot of them don't even know what a registry key is.
So disappointing that there isn't a real solution to this problem! This has been abound for so long and still no solution.
Also the lack of support for IOS / MacOS / iPadOS devices is causing so much problems.
And yes, as Sol mentioned, this is working fine on cPanel.
 
outside the box...
seeing as Plesk and CPanel are these days owned by the same company...

Plesk started to make their amazing WP Toolkit available to CPanel.
Ask the CPanel folks to help you out with the Autodiscover in return.

How about that ;)
 
TomBoB said:
outside the box...
seeing as Plesk and CPanel are these days owned by the same company...

Plesk started to make their amazing WP Toolkit available to CPanel.
Ask the CPanel folks to help you out with the Autodiscover in return.

How about that ;)
Click to expand...
That sound like a great idea! Does any Plesk coder / engineer read this topic anyway? It's been around for so long and nothing is happening.
 
Anthony said:
I want to say that we know about this issue and hear you.

We tried to find a proper solution for this issue but have no luck on the way.

Mail Autodiscover works well for old mail clients like Outlook 2016 but facing issues with the auto-configuration of Microsoft O365/2019 mail clients. The issue exists because these mail clients do not request a mail configuration directly from a Plesk server but instead using Microsoft cache servers for such purposes.

Also, it's important to note that the issue exists mostly for MS Office Pro mail clients, based on our tests of possible configurations:
View attachment 18787

Microsoft Support suggested for us reactive solution only: when mail autodiscover failed for a customer, you can
bypass using an MS proxy server by adding a registry key to the Outlook client (using Registry on a local machine):
-----
HKEY_CURRENT_USER\Software\Microsoft\Office\x.0\Outlook\AutoDiscover
Name : ExcludeExplicitO365Endpoint

Value : 1
------
Then a mail configuration will be requested directly from a Plesk server.

This solution is not suitable for us, but it's the best that we have for now. We continue communication with Microsoft with the hope of solving the issue.

But preliminary summary, that the new Outlook doesn't support autodiscovery for non-MS services (not Exchange servers).
Click to expand...
Hey @Anthony,

after months or almost years of investigation on our side and in cooperation with the Plesk support, you shared this information above with us in May 2021.
I would like to know, is there any update on this problem? You stated that Plesk is continuing the communication with Microsoft about these issues.

Thanks.
 
vaelu said:
Hey @Anthony,

after months or almost years of investigation on our side and in cooperation with the Plesk support, you shared this information above with us in May 2021.
I would like to know, is there any update on this problem? You stated that Plesk is continuing the communication with Microsoft about these issues.

Thanks.
Click to expand...
Unfortunately, we were out of luck with this issue.

As a result, we dropped support for these email clients in July 2021 Change Log for Plesk Obsidian
 
Autodiscover for Office 365 – IMAP 993 / SMTP with STARTTLS 587

Managed to get it going, but under and with a few “conditions”.

This is long, bear with me.

This isn’t a general works-everywhere, but a solution that works for our servers where we use the default Plesk setup where each domain uses its own clientdomain.com as mail server with autodiscovery.

In orange the few things to keep in mind:

Autodiscovery is enabled of course and principally set up according to Plesk’s advised practice.

Have tested it on an official Office 365 Apps for Business – logged in with a valid account – only. [Have *not* tested it on a Office Pro Plus version – those which are often [illegally – but no judging] bought and downloaded for a few Quid and used at home.]

Followed @IgorG his great general advise here: Question - Autodiscover/Autoconfig SMTP port

And created my own autodiscover_587.sh containing:

Code: 
# set port 587 for Plesk autodiscover
sed -i 's/{{SMTP_PORT}}/587/g' /usr/local/psa/admin/htdocs/mailconfig/autodiscover.xml
sed -i 's/{{OUTGOING_SSL}}/off/g' /usr/local/psa/admin/htdocs/mailconfig/autodiscover.xml

The matching autodiscover.xml :

Code: 
<!-- Copyright 1999-2021. Plesk International GmbH. All rights reserved. -->
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
    <Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
        <User>
            <DisplayName>{{DISPLAY_NAME}}</DisplayName>
        </User>
        <Account>
            <AccountType>email</AccountType>
            <Action>settings</Action>
            <Protocol>
                <Type>IMAP</Type>
                <Server>{{INCOMING_SERVER}}</Server>
                <Port>{{IMAP_PORT}}</Port>
                <DomainRequired>off</DomainRequired>
                <SPA>off</SPA>
                <SSL>{{INCOMING_SSL}}</SSL>
                <AuthRequired>on</AuthRequired>
                <LoginName>{{USER_NAME}}</LoginName>
            </Protocol>
            <Protocol>
                <SSL>off</SSL>
        <Encryption>TLS</Encryption>
                <Type>SMTP</Type>
                <Server>{{OUTGOING_SERVER}}</Server>
                <Port>587</Port>
        <DomainRequired>off</DomainRequired>
        <SPA>off</SPA>
                <AuthRequired>on</AuthRequired>
                <LoginName>{{USER_NAME}}</LoginName>
            </Protocol>
            <Protocol>
                <Type>POP3</Type>
                <Server>{{INCOMING_SERVER}}</Server>
                <Port>{{POP3_PORT}}</Port>
                <DomainRequired>off</DomainRequired>
                <SPA>off</SPA>
                <SSL>{{INCOMING_SSL}}</SSL>
                <AuthRequired>on</AuthRequired>
                <LoginName>{{USER_NAME}}</LoginName>
            </Protocol>
        </Account>
    </Response>
</Autodiscover>

Here I discovered another condition. Although Big Brother / Bully Microsoft states in the connection test tool that our server lacks modern ciphers, it’s actually Microsoft that’s behind. They don’t support TLS 1.3 yet, and more importantly they also don’t support ECDSA, only RSA ciphers.
Technical reference details about encryption - Microsoft 365 Compliance
If you configured your servers to use ECDSA in panel.ini [ext-letsencrypt] key-algorithm = ECDSA, like we had, you’ll have to switch back to key-algorithm = RSA .

Now comes a further condition, with 2 possible solutions: Office 365 it’s new “feature” Simplified Account Creation. Either
1) you change a certain Registry Key, or
2) you tell your clients to please go the long way round and don’t do File – Add Account, but do: File – Account Settings – Manage Profiles – Email Accounts – New

Well 1) is obviously a no-go for a hosting provider. But 2) – if you have a good relation with your clients, and they trust you know what you’re talking about [they do with us], they follow your advice – Which leads to a nice autodiscovery even on Office365.

---

In short (on Outlook 365, Apps for Business, signed in/activated with a valid account:

  • Domains use clientdomanxyz.com as mail server and for auto discovery
  • Create specific autodiscover_587.sh with specific autodiscover.xml (you can add thunderbird / mac stuff to autodiscover_587.sh obviously)
  • Use RSA ciphers
  • Tell clients to use the old fashioned (long way) to add new mail accounts as the “modern/simple” way has a bug.
Tested it on multiple servers, on multiple client computers. ALL account setups get detected perfectly with IMAP on 993 and SMTP with STARTTLS on 587.

Not sure if there is something else that plays into it perhaps, but above works for us.

I’m very happy, clients are very happy.
 
Hi,

Can anyone please confirm if option 2) should still work?
For some reason, Outlook 365 won't assign STARTTLS on the outgoing mail server:

Screenshot 2022-04-08 at 12.07.26.png
 
Hi, just tested it. The config
Code: 
            <Protocol>
                <SSL>off</SSL>
                <Encryption>TLS</Encryption>
                <Type>SMTP</Type>
                <Server>{{OUTGOING_SERVER}}</Server>
                <Port>587</Port>
                <DomainRequired>off</DomainRequired>
                <SPA>off</SPA>
                <AuthRequired>on</AuthRequired>
                <LoginName>{{USER_NAME}}</LoginName>
            </Protocol>
works on our servers. However just by chance I came across one of our servers that had the following config - must have forgotten to update it - which did not work. In fact it produced exactly your scenario with encryption type "none".
Code: 
            <Protocol>
                <Type>SMTP</Type>
                <Server>{{OUTGOING_SERVER}}</Server>
                <Port>587</Port>
                <DomainRequired>off</DomainRequired>
                <SPA>off</SPA>
                <SSL>off</SSL>
                <AuthRequired>on</AuthRequired>
                <LoginName>{{USER_NAME}}</LoginName>
            </Protocol>
Maybe just double-check on that.
 
Are there any plans on fixing this issue so that autodiscover will work again out of the box? It's a huge pain in the *** that autodiscover doesn't work anymore.
 
occinodo said:
Are there any plans on fixing this issue so that autodiscover will work again out of the box? It's a huge pain in the *** that autodiscover doesn't work anymore.
Click to expand...
Hi, it will not work out-of-the-box for Microsoft Outlook 2019/O365 mail clients due to the limitation on the Microsoft side described above in this thread, in particular: using Microsoft cache servers for auto-configuration requests which work properly only with the Exchange servers.
We can't provide an out-of-the-box solution before it is supported on the MS side.
Also, it could work with a manual configuration as described in Forwarded to devs - Autodiscover not working properly on Outlook
 
You must log in or register to reply here.

Similar threads

K
Forwarded to devs Custom domain name configured for autodiscovery not used for iOS QR code
Replies
2
Views
367
Peter Debik
P
skibidi
Forwarded to devs DNS template placeholder aren't replaced with right IP address when using specific muli IP setup
Replies
11
Views
2K
Peter Debik
P
T
Resolved "sent items" emails in Roundcube have all same date/time after restore of mailbox
Replies
2
Views
535
TomBoB
T
T
Resolved Cloudflare extension - import / export not working
Replies
16
Views
4K
Peter Debik
P
T
Forwarded to devs Transfer of DNS Records Ext - picks wrong domain
Replies
2
Views
605
Peter Debik
P
Back
Top