Comment configurer le relais SMTP Exchange Server 2016 – Serveur d’impression

Dans la plupart des organisations, plusieurs appareils ou applications doivent utiliser un service SMTP pour envoyer des e-mails. Un serveur Exchange 2016 peut vous fournir ce service, mais la configuration requise sur le serveur dépend des exigences de relais SMTP de votre scénario.

Les étapes de configuration du relais SMTP Exchange Server 2016 sont les suivantes:

1. Déterminez si votre scénario est un relais interne ou un relais externe
2. Déterminez si les appareils et les applications s'authentifieront ou se connecteront de manière anonyme
3. Pour le relais authentifié, configurez le certificat TLS pour le connecteur frontal client
4. Pour un relais anonyme, configurez un nouveau connecteur de réception limité à des adresses IP distantes spécifiques

Détermination des scénarios de relais internes et externes

Il existe généralement deux types de scénarios de relais SMTP pour lesquels Exchange Server 2016 est utilisé:

• Relais interne – les appareils et applications qui doivent envoyer des e-mails uniquement aux destinataires internes de l'organisation Exchange.
• Relais externe – les appareils et applications qui doivent envoyer des e-mails à des destinataires externes.

Jetons un coup d'œil à chacun de ces scénarios, puis à quelques considérations supplémentaires lorsque vous déployez cela dans vos propres environnements de production.

Relais SMTP interne avec Exchange Server 2016

Lors de la première installation d'Exchange Server 2016, la routine d'installation crée automatiquement un connecteur de réception préconfiguré pour être utilisé pour recevoir des messages électroniques d'expéditeurs anonymes vers des destinataires internes. Cela permet aux e-mails Internet entrants d'être reçus par le serveur et convient également aux scénarios de relais internes.

Le connecteur de réception est nommé «SERVERNAMEDefault Frontend SERVERNAME», par exemple, «EXSERVERDefault Frontend EXSERVER» dans mon environnement de test.

Vous pouvez tester ce connecteur en établissant une connexion SMTP à l'aide de Telnet et en émettant des commandes SMTP. Par exemple:

Il n'y a donc pas de configuration spécifique requise sur le serveur ou les connecteurs pour autoriser ce scénario, mais il est recommandé d'utiliser un alias DNS au lieu du vrai nom du serveur. Cela vous permettra de configurer tous vos appareils et applications avec l'alias DNS, et vous pourrez ensuite déplacer cet alias DNS pour pointer vers un autre serveur Exchange lors d'une migration.

Relais SMTP externe avec Exchange Server 2016

Suite à la démonstration précédente, voyons ce qui se passe si j'essaie d'utiliser Telnet pour envoyer un e-mail à partir d'une adresse interne valide à un destinataire externe.

Un code d'erreur SMTP "550 5.7.54, Impossible de relayer le destinataire dans un domaine non accepté" est reçu à la place. Le connecteur de réception ne permettra pas à un expéditeur anonyme et non authentifié de se relayer vers des noms de domaine externes, ce qui empêche votre serveur d'être exploité en tant que relais ouvert.

Vous pouvez résoudre ce problème de deux manières et autoriser vos appareils et applications à envoyer à des destinataires externes:

• Utilisation de l'authentification pour les connexions SMTP
• Configuration d'un connecteur de relais SMTP anonyme

Relais SMTP externe avec Exchange Server 2016 à l'aide de l'authentification

La première méthode consiste à utiliser des connexions SMTP authentifiées. Exchange Server 2016 possède un connecteur de réception conçu pour être utilisé par les clients qui doivent envoyer via SMTP appelé «SERVERNAMEClient Frontend SERVERNAME», par exemple «EXSERVERClient Frontend EXSERVER» dans mon environnement de test.

Une configuration minimale est requise pour que cela fonctionne. En supposant que vous avez déjà configuré un certificat SSL pour Exchange Server 2016 et ajouté un alias DNS pour vos appareils et applications SMTP à utiliser (j'utilise un alias DNS de mail.exchange2016demo.com dans cet exemple), vous devez également définir TlsCertificateName pour le connecteur de réception.

Utilisez Get-ExchangeCertificate pour identifier l'empreinte numérique du certificat SSL que vous utiliserez.

La syntaxe de la chaîne TlsCertificateName est composée de deux attributs différents du certificat, j'utilise donc les commandes suivantes pour appliquer la configuration à mon connecteur de réception.

Pour tester à l'aide du connecteur client frontal pour envoyer un e-mail, je vais utiliser l'applet de commande Send-MailMessage de PowerShell au lieu de Telnet. Commencez par capturer des informations d'identification valides à utiliser pour l'authentification.

Ensuite, utilisez l'applet de commande Send-MailMessage avec des paramètres spécifiant le serveur, vers et depuis les adresses, la ligne d'objet et le numéro de port.

Dans l'exemple ci-dessus, l'e-mail est correctement reçu par le destinataire externe. Ainsi, tout appareil ou application du réseau qui peut utiliser SMTP authentifié peut être configuré pour utiliser ce connecteur en écoutant sur le port 587 de votre serveur Exchange 2016.

Relais SMTP externe avec Exchange Server 2016 à l'aide de connexions anonymes

Lorsque SMTP authentifié n'est pas une option, vous pouvez créer un nouveau connecteur de réception sur le serveur Exchange 2016 qui permettra le relais SMTP anonyme à partir d'une liste spécifique d'adresses IP ou de plages IP.

Dans le Centre d'administration Exchange, accédez à flux de messagerie puis recevoir des connecteurs. Sélectionnez le serveur sur lequel vous souhaitez créer le nouveau connecteur de réception et cliquez sur le bouton "+" pour démarrer l'assistant.

Donnez un nom au nouveau connecteur. J'aime garder le nom cohérent avec les autres connecteurs par défaut. Met le Rôle à «Frontend Transport», et le Type à "Personnalisé".

Le défaut Liaisons de carte réseau vont bien. Cela représente l'IP et le port que le serveur sera écoute activé pour les connexions. Plusieurs connecteurs de réception sur le service de transport frontal peuvent écouter sur le même port de TCP 25.

Supprimez la plage IP par défaut du Paramètres réseau à distance, puis ajoutez les adresses IP ou les plages IP spécifiques à partir desquelles vous souhaitez autoriser le relais SMTP anonyme. Je ne recommande pas d'ajouter des sous-réseaux IP entiers qui contiennent d'autres serveurs Exchange car cela peut entraîner des problèmes avec les communications de serveur à serveur.

Cliquez sur Terminer pour terminer l'assistant, puis une configuration supplémentaire est encore requise.

Dans Exchange Management Shell, exécutez les deux commandes suivantes.

Nous pouvons maintenant tester le connecteur à l'aide de Telnet à partir de l'adresse IP qui a été ajoutée aux paramètres réseau à distance du connecteur de réception. Dans mon environnement de test, cette adresse IP sera désormais autorisée à envoyer des e-mails depuis n'importe quelle adresse e-mail (qu'il s'agisse d'une adresse interne valide ou non) vers n'importe quelle adresse externe.

Considérations supplémentaires

Voici quelques éléments supplémentaires que vous devez prendre en compte lorsque vous fournissez des services de relais SMTP avec Exchange Server 2016 pour votre environnement.

Haute disponibilité et équilibrage de charge

Si vous souhaitez fournir un service SMTP hautement disponible, un équilibreur de charge est la solution naturelle. Si vous prévoyez d'équilibrer la charge, vous devrez vous assurer que les mêmes connecteurs de réception existent sur tous les serveurs du pool à charge équilibrée. Cela signifie créer le même connecteur de relais sur plusieurs serveurs et gérer la même liste d'adresses IP autorisées sur ces connecteurs.

Cependant, comme vous le verrez en lisant mon article sur les problèmes d'équilibrage de charge du trafic SMTP, lorsqu'un équilibreur de charge est le NAT source des connexions, la seule adresse IP qui apparaîtra sur le serveur Exchange est celle de l'équilibreur de charge lui-même, pas la source appareil ou application. Bien que cela simplifie la configuration du connecteur de réception (seule l'IP de l'équilibreur de charge doit être ajoutée en tant qu'IP autorisée), cela ouvre un certain nombre de problèmes:

• Le contrôle d'accès (que les IP sont autorisées à envoyer) doit être appliqué à l'équilibreur de charge, sinon vous risquez d'avoir un service de relais SMTP anonyme grand ouvert sur votre réseau
• Selon l'équilibreur de charge, les sondes d'intégrité vers les serveurs Exchange peuvent ne pas détecter toutes les conditions d'intégrité, ce qui entraîne l'envoi de trafic vers des serveurs malsains (et l'échec)
• Les connexions établies via l'équilibreur de charge sont anonymes et, dans certains cas, introuvables à l'adresse IP source (selon la capacité de journalisation de votre équilibreur de charge)

Vous pouvez en savoir plus sur ces problèmes ici.

Si un équilibreur de charge n'est pas une option pour vous et que vous souhaitez toujours une haute disponibilité pour les services SMTP, vous pouvez alors envisager la répétition DNS. Cependant, de nombreux appareils et applications ne gèrent pas le round robin DNS aussi bien qu'Outlook ou un navigateur Web. Certains appareils, lorsqu'ils tentent de se connecter à l'une des adresses IP disponibles dans le round robin DNS et que cette adresse IP ne répond pas, n'essaieront pas les autres adresses IP disponibles et considéreront simplement l'échec de la tentative de connexion. Donc, cela dépend vraiment de la façon dont vos appareils et applications gèrent cette situation pour savoir si le round robin DNS sera adapté à votre environnement.

Sécurité vs commodité

De nombreuses organisations optent simplement pour l'option de relais anonyme et configurent un connecteur qui permet à une large gamme d'adresses IP de relayer les e-mails n'importe où. Il s'agit de l'approche la plus simple, mais clairement pas la meilleure en termes de sécurité et d'audit. Le relais anonyme s'appuie sur des adresses IP fiables et identifiables. Si les adresses IP se trouvent dans un pool DHCP, sont associées à un équilibreur de charge (voir ci-dessus), sont multi-utilisateurs (tels que des serveurs de terminaux) ou si l'IP / l'hôte lui-même est compromis d'une manière ou d'une autre, votre capacité à tracer les e-mails revenir à la source réelle est difficile, voire impossible.

Bien que l'authentification ajoute une certaine complexité, cela peut valoir la peine du point de vue de la sécurité. Cependant, cela signifie gérer les informations d'identification pour tous vos appareils et applications. Le partage des informations d'identification SMTP sur plusieurs systèmes peut sembler un moyen d'éviter la complexité, mais il réintroduit les problèmes associés au SMTP anonyme.

Chiffrement

Dans le tutoriel ci-dessus, j'ai démontré la configuration d'un nom de certificat TLS pour un connecteur de réception et j'ai également utilisé TLS / SSL pour mes tests avec Send-MailMessage. Si vous comptez utiliser l'authentification pour SMTP dans votre environnement ou si le trafic SMTP est sensible de quelque manière que ce soit, vous devez le protéger avec le cryptage TLS / SSL.

Connecteurs de réception multiples

Vous vous demandez peut-être comment le serveur Exchange est capable de faire la différence entre le trafic destiné à un connecteur de réception et un autre connecteur de réception, lorsque les deux écoutent sur la même adresse IP et le même numéro de port, par exemple «EXSERVERDefault Frontend EXSERVER» et «EXSERVERAnon Relay EXSERVER ”.

La réponse est dans le Paramètres réseau à distance des connecteurs de réception. Exchange utilisera le connecteur de réception qui est le correspondance la plus spécifique pour l'adresse IP source de la connexion SMTP.

Dans mes exemples ci-dessus, cela signifie que le connecteur par défaut avec ses paramètres de réseau distant de 0.0.0.0-255.255.255.255 (qui est essentiellement «n'importe où») est moins spécifique que le connecteur de relais avec ses paramètres de réseau distant de 192.168.0.30. Ainsi, lorsqu'une connexion SMTP provient de l'IP 192.168.0.30 vers le port 25 du serveur, elle sera gérée par le connecteur de relais, tandis que tout le reste se connectant au port 25 sera géré par le connecteur par défaut.

Dépannage

L'un des problèmes les plus courants lors du dépannage du comportement du connecteur de réception sur un serveur Exchange est de déterminer quel connecteur gère réellement une connexion donnée. Il existe deux façons d'aborder ce type de dépannage.

La première consiste à définir différentes bannières SMTP sur chaque connecteur. Le MVP Exchange Jeff Guillet a un exemple PowerShell que vous pouvez exécuter pour configurer la bannière SMTP de chaque connecteur avec le nom du connecteur lui-même, de sorte que lorsque vous vous connectez à Telnet, vous pouvez immédiatement voir à quel connecteur de réception vous êtes connecté.

Maintenant, lorsque vous utilisez Telnet pour vous connecter, vous verrez le nom du connecteur dans la bannière.

L'autre méthode de dépannage consiste à utiliser la journalisation du protocole. Dans l'exemple PowerShell ci-dessus, le niveau de journal de protocole pour chaque connecteur a également été défini sur «Verbose». Vous pouvez définir cela sur des connecteurs individuels si vous en avez besoin en exécutant Set-ReceiveConnector.

Vous pouvez ensuite consulter les journaux de protocole pour déterminer ce qui se passe avec les connexions SMTP. Je recommande généralement de laisser la journalisation de protocole activée pour les connecteurs de réception à tout moment.

Sommaire

Cet article montre comment Exchange Server 2016 peut être utilisé pour fournir des services de relais SMTP aux périphériques et applications de votre réseau. Comme vous pouvez le voir, il existe plusieurs approches que vous pouvez adopter pour y parvenir, chacune étant adaptée à différents scénarios et chacune ayant des avantages et des inconvénients associés.

Les besoins de relais internes sont déjà satisfaits avec la configuration par défaut d'un Exchange 2016, et SMTP authentifié pour relais externe est également disponible avec une configuration minimale. Lorsqu'un relais anonyme est requis, un connecteur de réception supplémentaire peut être facilement configuré.

Je vous recommande de prendre en compte vos besoins réels et de mettre en œuvre la solution la plus appropriée pour y répondre, au lieu de simplement configurer un connecteur de relais anonyme pour tous les appareils et applications de votre réseau.

Paul est un MVP Microsoft pour les applications et services Office et un auteur Pluralsight. Il travaille en tant que consultant, écrivain et formateur spécialisé dans Office 365 et Exchange Server.