Je fais du travail de consultant pour un client d'une entreprise de développement Web, et ce problème m'a complètement bouleversé.
Le client a sa configuration Outlook pour consulter l'URL https://example.com/autodiscover/autodiscover.xml
lors de la configuration d'un compte. Auparavant, le site ne contenait pas autodiscover.xml, cela retournerait un 404 et Outlook essaierait plutôt https://autodiscover.example.com/autodiscover/autodiscover.xml
, qui fonctionnait.
Le site auparavant n'avait pas de certificat SSL et redirigeait vers la version http, ce qui renverrait un 404. Toutefois, après l'ajout d'un certificat SSL, la version https du lien fonctionne et le lien autodiscover.xml renvoie à la place.
autodiscovery must be provided a valid email address
La version non HTTPS renvoie correctement une erreur 404, mais la version HTTPS renvoie la chaîne ci-dessus. Pourquoi les deux résultats renvoient-ils des résultats différents quand ils ont la même adresse? Cela a rendu des comptes de messagerie entiers inaccessibles pour eux, de sorte qu'ils recherchent un correctif pour cet ASAP.
J'ai essayé de parcourir tous les fichiers de l'installation Wordpress pour voir si quelque chose était à l'origine de ce problème et si rien n'a été trouvé. Le site est un package revendeur de Hostgator, de sorte que cpanel ne semblait pas avoir défini de paramètre permettant de désactiver la découverte automatique pour Outlook. Le fichier .htaccess ne semblait contenir aucune règle qui devrait être la cause de cela.
Je suis complètement à court d'idées et je suis chargé de m'assurer que leur courrier électronique fonctionne à nouveau dès que possible. Toute aide est appréciée!
Votre question est un peu déroutante, vous pouvez peut-être mieux la structurer. Quoi qu'il en soit:
@Rob a raison, HTTP
et HTTPS
fonctionnent sur différents ports (80 et 443) et en réalité http://www.example.com et https: //www.example.com sont deux adresses complètement différentes. Ils peuvent également avoir un contenu différent si vous le souhaitez.
Il est possible que votre Wordpress effectue une mauvaise redirection. Dans ce cas, je recommanderais de forcer une seule redirection de l'adresse http://
vers l'adresse https://
à l'aide du fichier .htaccess
. Pour plus d'informations, vous pouvez consulter: https://stackoverflow.com/questions/1421068/htaccess-301-redirect-of-single-page
J'ai également eu ce problème après l'activation récente de SSL, avec une différence mineure en ce que https://clientsite.com/autodiscover/autodiscover.xml affiche le message d'erreur "La découverte automatique doit être fournie avec une adresse électronique valide. "lorsqu’on navigue vers et passe à http://clientsite.com/autodiscover/autodiscover.xml redirige vers https://someserver.myhostingbusinessesdomain.com/autodiscover/autodiscover.xml = et donne ensuite le même message d'erreur.
Dans mon rôle avec une agence Web fournissant le site Web du client à l'adresse clientsite.com, j'ai fourni une assistance au client lorsque la découverte automatique a cessé de fonctionner pour son compte Office365.
J'ai essayé d'ajouter une commande de redirection au fichier .htaccess à la racine du site, mais ils n'étaient même pas déclenchés pour une raison quelconque. La demande a bien atteint le serveur Web du compte hôte ou l'installation Wordpress.
Je n’ai toujours pas découvert ce qui produisait ce message d’erreur, mais j’ai trouvé un enregistrement DNS SRV nommé _ autodiscover._tcp qui est resté avant le client utilisé Office365 et toujours pointé vers le mauvais serveur de découverte automatique someserver.myhostingbusinessesdomain.com
Le disque avait des détails:
Name: _autodiscover._tcp
Port Number: 443
Host: someserver.myhostingbusinessesdomain.com
Priority: 0
Weight: 0
Le port 443 est ce qui est utilisé par https (SSL), alors j’ai pensé que cela pourrait être pertinent. Le nom _autodiscover._tcp signifie service _autodiscover avec protocole _tcp
J'ai mis à jour l'hôte avec la même valeur que pour l'enregistrement CNAME de découverte automatique, qui était autodiscover.Outlook.com (en fait, l'outil DNS que j'utilise dans cPanel/WHM requiert un caractère supplémentaire à la fin du domaine, sinon il est ajouté automatiquement. clientsite.com jusqu'à la fin lors de l'enregistrement, mais ce comportement diffère d'un outil à l'autre, je comprends)
Après la période TTL, la découverte automatique semble à nouveau fonctionner (le compte Office365 du client peut être correctement détecté à nouveau dans Outlook 2016), bien que les mêmes messages apparaissent lors de la navigation dans les URL indiquées ci-dessus pour autodiscover.xml.
Je suis conscient du fait que je ne connais pas parfaitement la configuration de la découverte automatique, mais comme cela a fonctionné pour moi, j'espère que cela fournit une solution dans certains cas, pour d'autres également.
Fait intéressant, l'outil Office365 pour vérifier la santé du domaine DNS n'a pas relevé ce problème!