IIS / SMTP - les e-mails sont bloqués dans mailroot / Queue
J'essaie d'envoyer des e-mails via SMTP dans le répertoire de collecte IIS. Malheureusement, les e-mails vont simplement dans le dossier mailroot/queue et y restent. Ils ne sont jamais envoyés.
Est-ce que quelqu'un sait pourquoi cela se produirait et une solution potentielle au problème?
Eu un problème similaire avec des fichiers coincés dans la file d'attente. Dans IIS, Serveur virtuel SMTP> Propriétés> Livraison> Connexions sortantes. L'option pour Limit number of connections to a été vérifié et la valeur était 0. Il a donc été configuré pour ne jamais établir de connexions sortantes, ce qui empêche les e-mails de quitter le serveur. J'ai décoché l'option et redémarré le serveur SMTP et tout allait bien.
J'ai eu ce problème aujourd'hui.
Après avoir redémarré le service "SMTP (Simple Mail Transfer Protocol)", il a recommencé à fonctionner.
Juste pour mémoire: nous avons eu un cas où le serveur ne pouvait plus résoudre les noms en raison d'un paramétrage DNS erroné. Le comportement résultant était exactement celui que vous avez décrit.
IISRESET a corrigé cela pour moi. Je crois que c'est similaire à la solution de réinitialisation du service SMTP car ce service dépend d'IIS. Après avoir redémarré le courrier dans C:\inetpub\mailroot\Queue a commencé à disparaître!
J'ai rencontré ce problème récemment. Dans mon cas, cela s'est avéré être un problème avec la définition du serveur DNS dans une carte réseau (cela en a deux pour une raison inconnue pour moi). Le serveur DNS désigné a été défini sur "127.0.0.1" au lieu du "8.8.8.8" normal qui est normalement utilisé sur ce réseau. J'ai changé cela à la valeur correcte, redémarré mon serveur SMTP et les e-mails en file d'attente ont été immédiatement distribués.
Comment j'ai compris cela pour examiner le problème de définition DNS:
- Utilisation de nslookup pour trouver un serveur mx à tester (testé 5 ou 6 serveurs différents)
- J'ai essayé de telnet sur le serveur (chaque fois rencontré un message "impossible de se connecter" qui m'a fait penser initialement aux problèmes de pare-feu)
- J'ai essayé de cingler la valeur du serveur mx testé (chaque fois rencontré un message "impossible de se connecter à l'hôte")
J'espère que cela aidera quelqu'un d'autre, ce n'était pas quelque chose que j'aurais pensé voir au début.
D'après mon expérience, cela est généralement dû à IIS SMTP essayant d'envoyer et rencontrant une erreur temporaire (code de réponse 4xx). Avez-vous activé la journalisation pour le IIS = Service SMTP et examen du journal? Désolé si tout est évident, mais il est difficile de connaître la cause ou le correctif sans savoir ce que le journal affiche.
J'ai eu le même problème après avoir changé de service de messagerie d'un hôte à un autre (le nouveau est Office 365). Après de nombreux essais et erreurs, il a finalement commencé à fonctionner en procédant comme suit:
- Ajouter mon domaine de messagerie à IIS 6 en tant que domaine "distant". (Il s'agit du domaine hébergé dans O365 et utilisé par tous les comptes d'utilisateurs).
- Dans IIS 6, double-cliquez sur ce domaine; sous "Acheminer le domaine", sélectionnez "Transférer tous les messages vers l'hôte intelligent" et entrez votre serveur (dans mon cas, "smtp.office365.com")) Cochez également la case "Autoriser le courrier entrant à être relayé vers ce domaine".
- Dans IIS 6, cliquez avec le bouton droit sur le serveur virtuel SMTP> Propriétés.
- Onglet Général: cliquez sur Avancé et ajoutez l'IP et le port 587 de votre serveur local
- Onglet Accès: assurez-vous que "Exiger le cryptage TLS" est coché. J'ai dû créer un certificat de domaine dans IIS 7 avec le nom de mon domaine de messagerie.
- Onglet Accès: Ajoutez l'adresse IP de votre serveur local aux listes "Connexion" et "Relais".
- Onglet de livraison: Sécurité sortante: sélectionnez l'authentification de base, entrez les informations d'identification d'un utilisateur sous licence valide; cochez la case "Cryptage TLS"
- Onglet de livraison: Connexions sortantes: entrez 587 pour TCP Port
- Onglet de livraison: Avancé: entrez votre domaine de messagerie comme "nom de domaine complet" et votre serveur de messagerie comme "hôte intelligent" (encore une fois dans mon cas smtp.office365.com).
Pare-feu: j'ai lu que vous devez ouvrir le port 587 pour le trafic sortant. (Je ne l'ai pas fait car il s'agit d'un serveur VOIP qui a besoin de son pare-feu.)
Office 365: ajoutez un "connecteur" sous Admin> Exchange pour autoriser votre adresse IP statique locale. Microsoft fournit ces instructions en ligne.
Je pense que le problème pourrait être qu'il y a une confusion entre IPv4 et IPv6 sur le système, donc lorsque vous spécifiez localhost, le protocole IPv6 par défaut est choisi. J'ai eu le même problème aujourd'hui et il a été résolu après que la référence localhost à l'adresse IPv6 dans les hôtes a été supprimée, bien que cela ait pu être une coïncidence (je configure également SVN). Voici donc ma configuration au cas où:
- Dans IIS7, j'ai l'option "Livrer au serveur SMTP" activée avec localhost comme serveur choisi.
- Dans IIS6, j'ai un accès défini uniquement à 127.0.0.1, aucune authentification pour les entrées ou les sorties.
J'ai joué avec les paramètres toute la journée, donc, pour être honnête, je ne sais pas quoi d'autre aurait pu influencer le fait que cela fonctionne maintenant. J'espère que cela aide au moins un peu.
J'ai récemment abordé ce problème. Quelqu'un avait installé MalwareBytes sur le serveur smtp et les dossiers mailroot smtp n'étaient pas sur liste blanche. Le logiciel a traité tout ce qui se trouvait dans la file d'attente comme une campagne de spam potentielle et l'a laissé expirer suffisamment de fois pour passer à un mauvais courrier électronique. Tous les domaines ont été affectés. Cela m'a laissé perplexe (fonctionnement sans faille depuis des années maintenant) jusqu'à ce que je regarde les processus en cours et que je remarque l'exe de mbam.
Le premier endroit à regarder est les fichiers journaux du serveur. Cela vous indiquera si votre serveur rencontre des problèmes d'envoi vers des hôtes spécifiques. La plupart du temps, cela se produit (selon mes expériences), c'est généralement le DNS (de votre côté ou à distance) qui est le coupable.
Le serveur SMTP recherche un hôte/passerelle SMTP auquel envoyer le courrier.
Si vous essayez d'envoyer à localhost, l'IP localhost serait la passerelle. Si vous essayez d'envoyer à une adresse e-mail externe comme gmail ou hotmail, vous devrez ajouter la passerelle de messagerie de votre FAI en tant qu'hôte intelligent.
Pour configurer un hôte intelligent:
- Dans IIS Manager, cliquez avec le bouton droit sur le serveur virtuel SMTP, puis cliquez sur Propriétés.
- Cliquez sur l'onglet Livraison, puis sur Avancé.
- Dans la zone Smart Host, saisissez le nom du serveur Smart Host. Vous pouvez saisir une chaîne pour représenter un nom ou saisir une adresse IP.
- Si vous souhaitez que le service SMTP tente de remettre des messages distants directement avant de les transférer vers le serveur hôte intelligent, activez la case à cocher Tenter la remise directe avant l'envoi à l'hôte intelligent. La valeur par défaut consiste à envoyer tous les messages distants à l'hôte actif, et non à tenter une remise directe.