J'ai un serveur SMTP existant sur notre réseau qui est utilisé pour envoyer des courriels à partir d'une variété d'imprimantes, d'applications, etc... J'ai installé le serveur SMTP IIS sur un nouveau serveur Windows Server 2012 R2 pour remplacer le serveur SMTP actuel. Pour le configurer, j'ai copié les paramètres du serveur SMTP existant presque exactement, à l'exception du changement d'adresse IP interne.
Nous disposons d'un enregistrement SPF afin de pouvoir envoyer des courriers électroniques sans utiliser de smarthost ou de routage via notre fournisseur de courrier électronique. Nous n'avons rencontré aucun problème à ce sujet. Pour éviter de mettre à jour notre enregistrement SPF, nous avons configuré nos règles Sonicwall pour acheminer les courriels sortants des deux serveurs SMTP de manière à ce qu'ils semblent provenir de la même adresse externe, smtp.domain.com.
Voici à quoi ressemblent nos règles NAT :
Interne (smtp.domain.com) 192.168.1.2 -> 68.68.68.68 (smtp.domain.com)
Interne (primarysmtp.domain.com) 192.168.1.3 -> 68.68.68.68 (smtp.domain.com)
Nous avons changé une imprimante pour utiliser le nouveau serveur SMTP (primarysmtp.domain.com) à des fins de test. Les courriels sont reçus par le serveur SMTP et placés dans le dossier Queue, ce qui est une bonne chose. Maintenant, nous n'arrivons pas à envoyer ces courriels.
J'ai téléchargé l'outil SMTPDIAG pour le tester. J'ai d'abord pensé qu'il s'agissait d'un problème de DNS, mais le test l'a confirmé. Il ne se connecte pas au fournisseur de messagerie cible.
Nous pensions qu'il s'agissait du pare-feu avancé de Windows, mais il est complètement désactivé sur le serveur.
Nous avons alors pensé qu'il s'agissait des règles de notre Sonicwall, mais ils sont presque exactement les mêmes que ceux que nous utilisons déjà . Nous ne trouvons aucun endroit qui bloque le port 25. La nouvelle règle NAT a également ZÉRO statistiques de trafic, de sorte qu'il ne semble pas qu'il y ait quoi que ce soit qui sorte du nouveau serveur pour utiliser la règle NAT.
Nous avons essayé de réinitialiser IIS et d'arrêter et de démarrer le serveur SMTP à plusieurs reprises.
Le test échoue toujours avec l'erreur 10061. Mes recherches sur Google ne m'ont mené nulle part. Est-il possible que Windows Server 2012 R2 bloque toujours le trafic sortant sur le port 25, même si le pare-feu est désactivé ? Qu'est-ce qui nous manque ?
