Comment utiliser Mail Contact pour activer le relais SMTP sortant ?
Considérez le scénario suivant. Vous avez besoin de délivrer des emails à destination/provenance d’un serveur d’application qui reçoit des emails via SMTP. Vous souhaitez utiliser la protection Exchange Online, le domaine SMTP du serveur d’application peut envoyer des e-mails via SMTP. Mais il n’est pas routable ou contactable via Internet et ne peut donc pas recevoir de réponses aux messages envoyés. La messagerie de votre organisation est en configuration hybride avec un serveur Exchange sur site. Ce dernier est configuré pour permettre à vos serveurs d’application de relayer les e-mails sortants via Office 365.
Votre serveur d’application peut recevoir des emails externes via Exchange Online s’il utilise un objet Mail Contact. Cet objet acceptera les emails destinés à Exchange Online. Puis il les retransmettra sur site pour les distribuer à votre serveur d’applications. Dans cet article, nous vous montrerons comment réaliser cette opération et comment résoudre les problèmes courants que vous pourriez rencontrer.
Exemple de configuration du relais SMTP
Dans notre scénario d’exemple, nous avons un serveur d’application qui envoie des messages en tant que Application.Mailbox. Il possède deux adresses électroniques différentes : l’adresse interne utilisée dans le serveur d’application et l’adresse définie dans Office 365.
Dans cet exemple, notre adresse e-mail Office 365 est : Application.Mailbox@wordfish.co.uk
L’adresse électronique du serveur d’application interne est : Application.Mailbox@resdomain.local
L’adresse email Office 365 doit relayer le courrier vers le serveur d’application sur site. Pour cela le domaine de messagerie non routable a besoin d’un connecteur spécifique. Ce dernier doit pouvoir acheminer les messages vers le domaine sur site spécifique du serveur d’application.
Il est important de noter que vous pourriez plutôt ajouter le domaine au connecteur hybride. Cependant nous ne le recommandons pas. En effet, l’exécution de l’assistant de configuration hybride supprimera le domaine du connecteur.
Il faut aussi s’assurer que l’environnement sur site est en mesure d’envoyer le courrier au serveur d’application, comme illustré ci-dessous :
Comme le serveur d’application doit envoyer des messages SMTP, Exchange sur site peut servir de relais :
Après avoir mis en œuvre cette configuration, le serveur d’application peut envoyer et recevoir le courrier. Et tout peut sembler bien, au départ…
Certains e-mails sont signalés comme spams ou ne sont pas délivrés
Les problèmes de livraison de courrier avec certains serveurs de courrier sur Internet sont communs.
En général, vous vérifiez que les enregistrements, comme les enregistrements SPF, sont correctement configurés. Vous vérifiez et constatez que le SPF est correctement configuré et que vous n’êtes pas blacklisté. La livraison du courrier électronique en général est bonne.
Cependant, l’envoi d’un courriel de test via le serveur d’application et l’analyse des en-têtes montrent quelques résultats intéressants.
Après envoi d’un message de test, ouvrez les en-têtes du message dans un client comme Outlook. Vous pouvez ensuite copier et coller les en-têtes dans l’analyseur d’en-tête de message de Microsoft.
Il s’agit d’un outil utile, car il vous permet d’examiner facilement les propriétés contenues dans les en-têtes de message. Vous pouvez ainsi identifier rapidement le problème en question. Dans l’exemple ci-dessous, nous avons mis en évidence ce qui semble être le problème sous-jacent :
Vous pouvez voir ci-dessus que dans le chemin de retour, l’adresse « de » de l’enveloppe est sur le domaine interne resdomain.local.
Un domaine Return-Path invalide est une raison suffisante pour que le serveur de messagerie récepteur rejette le message.
Dans cet exemple, nous pouvons reconfigurer facilement Office 365 afin que le serveur d’application relaye les messages. Nous allons modifier la configuration à des fins de test pour obtenir la configuration présentée ci-dessous :
Après avoir effectué les changements de configuration, nous allons effectuer à nouveau le test du relais SMTP, comme indiqué ci-dessous :
Nous allons suivre le même processus d’investigation que précédemment et examiner les en-têtes du message à réception. Le routage direct, plutôt que via Exchange Hybrid, montre que cette fois le Return-Path est conforme aux attentes :
Alors, qu’est-ce qui se passe ?
Conclusion
Observez la majuscule inhabituelle du chemin de retour dans le premier exemple. Et notez qu’il s’agit exactement de la même adresse en caractères gras dans l’objet Mail Contact (l’adresse de réponse) :
Exchange sur site reçoit l’email et utilise l’objet Mail Contact comme adresse de l’enveloppe lorsqu’il le relaie vers Office 365. Il ne change pas l’adresse de réponse vue par l’utilisateur, donc à première vue, tout se comporte comme prévu.
Bien qu’Office 365 ait le même objet Mail Contact, le comportement n’est pas le même. Exchange Online ne modifie pas l’adresse de l’enveloppe.
Vous pourriez envisager de relayer tous vos serveurs d’applications par Office 365 et Exchange Online directement. Toutefois, cette configuration ne convient pas à de nombreuses organisations. En effet elle nécessite des modifications importantes du pare-feu, notamment pour permettre aux serveurs d’applications de communiquer directement sur Internet.
Nous allons plutôt choisir de corriger ce problème en mettant à jour l’objet contact de nos serveurs d’application dans Exchange sur site. La solution la plus simple consiste à définir la bonne adresse comme adresse de réponse dans le contact de messagerie :
Résumé
La migration de vos applications pour relayer et recevoir du courrier via Exchange Online Protection et Office 365 est une bonne décision. Elle garantit que les messages sont correctement protégés à la fois lorsqu’ils quittent votre organisation et lorsque les réponses sont reçues. Cependant, ce n’est pas toujours simple. En vous assurant que vous définissez correctement les objets Mail Contact sur site, vous pouvez éviter les pièges potentiels.
