IIS / SMTP - E-Mails bleiben in Mailroot / Queue hängen

Ich versuche, E-Mails über SMTP im IIS-Abholverzeichnis zu senden. Leider werden die E-Mails nur in den Ordner Mailroot / Queue verschoben und bleiben dort. Sie werden nie wirklich gesendet.

Weiß jemand, warum dies passieren würde und eine mögliche Lösung für das Problem?

Hatte ein ähnliches Problem mit Dateien in der Warteschlange stecken. Klicken Sie im IIS-Manager auf Virtueller SMTP-Server> Eigenschaften> Übermitteln> Ausgehende Verbindungen. Die Option für Limit number of connections towurde markiert und der Wert war 0. Es wurde also so konfiguriert, dass keine ausgehenden Verbindungen hergestellt werden und die E-Mails den Server nie verlassen. Ich habe die Option deaktiviert und den SMTP-Server neu gestartet und alles war in Ordnung.

Ich hatte heute dieses Problem.

Nach dem Neustart des SMTP-Dienstes (Simple Mail Transfer Protocol) funktionierte er wieder.

Nur zur Erinnerung: Wir hatten einen Fall, in dem der Server aufgrund falscher DNS-Einstellungen keine Namen mehr auflösen konnte. Das resultierende Verhalten war genau das, was Sie beschrieben haben.

IISRESET hat das für mich behoben. Ich glaube, es ähnelt der Lösung zum Zurücksetzen des SMTP-Dienstes, da dieser Dienst von IIS abhängt. Nach dem Neustart verschwand die Mail in C: \ inetpub \ mailroot \ Queue!

Ich bin kürzlich auf dieses Problem gestoßen. In meinem Fall stellte sich heraus, dass es ein Problem mit der DNS-Serverdefinition in einem Netzwerkadapter war (dies hat aus irgendeinem Grund zwei, die mir unbekannt sind). Der angegebene DNS-Server wurde auf "127.0.0.1" anstelle des normalen "8.8.8.8" festgelegt, der normalerweise in diesem Netzwerk verwendet wird. Ich habe dies auf den richtigen Wert geändert, meinen SMTP-Server neu gestartet und die in der Warteschlange befindlichen E-Mails wurden sofort verteilt.

Wie ich das herausgefunden habe, um das Problem der DNS-Definition zu untersuchen:

• Mit nslookup einen MX-Server zum Testen finden (5 oder 6 verschiedene getestet)
• Es wurde versucht, eine Telnet-Verbindung zum Server herzustellen (jedes Mal wurde eine Meldung angezeigt, dass keine Verbindung hergestellt werden konnte, sodass ich anfangs an Firewall-Probleme dachte).
• Versucht, den Wert für den getesteten MX-Server zu pingen (jedes Mal, wenn die Meldung "Verbindung zum Host konnte nicht hergestellt werden" angezeigt wird)

Hoffentlich hilft das jemand anderem, hätte ich mir anfangs nicht gedacht.

Nach meiner Erfahrung liegt dies normalerweise daran, dass IIS SMTP versucht, einen temporären Fehler (4xx-Antwortcode) zu senden, der auftritt. Haben Sie die Protokollierung für den IIS-SMTP-Dienst aktiviert und das Protokoll überprüft? Tut mir leid, wenn das alles offensichtlich ist, aber es ist schwer, die Ursache oder den Fix zu kennen, ohne zu wissen, was das Protokoll anzeigt.

Ich denke, das Problem könnte sein, dass es eine Verwechslung zwischen IPv4 und IPv6 auf dem System gibt. Wenn Sie also localhost angeben, wird das Standard-IPv6-Protokoll ausgewählt. Ich hatte heute das gleiche Problem und es wurde behoben, nachdem der lokale Host-Verweis auf die IPv6-Adresse in den Hosts entfernt wurde, obwohl dies ein Zufall gewesen sein könnte (ich richte auch SVN ein). Also hier ist mein Setup für alle Fälle:

1. In IIS7 ist die Option "An SMTP-Server senden" mit localhost als ausgewähltem Server aktiviert.
2. In IIS6 habe ich Zugriff nur auf 127.0.0.1 festgelegt, keine Authentifizierung für eingehende oder ausgehende.

Ich habe den ganzen Tag an den Einstellungen herumgespielt, um ehrlich zu sein, ich bin mir nicht sicher, was sonst die Tatsache beeinflusst haben könnte, dass es jetzt funktioniert. Hoffe das hilft zumindest ein bisschen.

Der erste Ort, an dem Sie suchen müssen, sind die Server-Protokolldateien. Hier erfahren Sie, ob Ihr Server Probleme beim Senden an bestimmte Hosts hat. Die meiste Zeit, in der dies passiert (nach meinen Erfahrungen), ist in der Regel DNS (entweder auf Ihrer Seite oder aus der Ferne) der Schuldige.

Der SMTP-Server sucht nach einem SMTP-Host / -Gateway, an den die E-Mail gesendet werden kann.

Wenn Sie versuchen, an localhost zu senden, ist die localhost-IP das Gateway. Wenn Sie versuchen, an eine externe E-Mail-Adresse wie Google Mail oder Hotmail zu senden, müssen Sie das E-Mail-Gateway Ihres Internetdienstanbieters als Smarthost hinzufügen.

So richten Sie einen Smarthost ein:

1. Klicken Sie mit der rechten Maustaste in dem II-Manager auf den virtuellen SMTP-Server, und klicken Sie dann auf Eigenschaft.
2. Klicken Sie auf die Registerkarte Übermittlung, und klicken Sie auf Erweitert.
3. Geben Sie im Feld Smarthost den Namen des Smarthost-Servers ein. Sie können eine Zeichenfolge eingeben, um einen Namen darzustellen, oder eine IP-Adresse eingeben.
4. Wenn der SMTP-Dienst versuchen soll, Remotemeldungen direkt zuzustellen, bevor sie an den Smarthost-Server weitergeleitet werden, aktivieren Sie das Kontrollkästchen Direktzustellung vor dem Senden an den Smarthost versuchen. Standardmäßig werden alle Remotemeldungen an den Smarthost gesendet, und es wird keine direkte Zustellung versucht.

Ich hatte das gleiche Problem, nachdem ich den E-Mail-Dienst von einem Host auf einen anderen umgestellt hatte (neu ist Office 365). Nach vielen Versuchen und Irrtümern funktionierte es nun wie folgt:

1. Hinzufügen meiner E-Mail-Domäne zu IIS 6 als "Remotedomäne". (Dies ist die Domain, die in O365 gehostet wird und die von allen Benutzerkonten verwendet wird.)
2. Doppelklicken Sie in IIS 6 auf diese Domäne. Wählen Sie unter "Domain weiterleiten" die Option "Alle E-Mails an Smarthost weiterleiten" und geben Sie Ihren Server ein (in meinem Fall "smtp.office365.com"). Aktivieren Sie außerdem das Kontrollkästchen "Eingehende E-Mails an diese Domäne weiterleiten lassen".
3. Klicken Sie in IIS 6 mit der rechten Maustaste auf den virtuellen SMTP-Server> Eigenschaften.
   • Registerkarte "Allgemein": Klicken Sie auf "Erweitert" und fügen Sie die IP-Adresse und den Port 587 Ihres lokalen Servers hinzu
   • Registerkarte "Zugriff": Stellen Sie sicher, dass "TLS-Verschlüsselung erforderlich" aktiviert ist. Ich musste in IIS 7 ein Domänenzertifikat mit dem Namen meiner E-Mail-Domäne erstellen.
   • Registerkarte "Zugriff": Fügen Sie Ihre lokale Server-IP zu den Listen "Verbindung" und "Relais" hinzu.
   • Registerkarte "Übermittlung": Ausgehende Sicherheit: Wählen Sie die Standardauthentifizierung aus, und geben Sie die Anmeldeinformationen eines gültigen lizenzierten Benutzers ein. Aktivieren Sie das Kontrollkästchen für "TLS-Verschlüsselung"
   • Registerkarte Übermittlung: Ausgehende Verbindungen: Geben Sie als TCP-Port 587 ein
   • Registerkarte "Zustellung": Erweitert: Geben Sie Ihre E-Mail-Domain als "Vollständig qualifizierten Domainnamen" und Ihren E-Mail-Server als "Smarthost" ein (auch in meinem Fall smtp.office365.com).

Firewall: Ich habe gelesen, dass Sie Port 587 für ausgehende Verbindungen öffnen müssen. (Ich habe es nicht getan, weil dies ein VOIP-Server ist, dessen Firewall deaktiviert sein muss.)

Office 365: Fügen Sie unter Admin> Exchange einen "Connector" hinzu, um Ihre lokale statische IP-Adresse zuzulassen. Microsoft stellt diese Anweisungen online zur Verfügung.

Bin vor kurzem auf dieses Problem gestoßen. Jemand hatte MalwareBytes auf dem SMTP-Server installiert, und die SMTP-Mailroot-Ordner wurden nicht auf die Whitelist gesetzt. Die Software hat alles in der Warteschlange als potenzielle Spam-Kampagne behandelt und das Timeout so oft eingestellt, dass es auf Badmail verschoben wurde. Alle Domänen waren betroffen. Hatte mich verwirrt (seit Jahren einwandfreier Betrieb ..), bis ich mir laufende Prozesse ansah und mbams Exe bemerkte.

Ich hatte das gleiche Problem. Wie andere sagten, handelte es sich um DNS. Ich habe auf unseren internen DNS-Servern eine Forward-Lookupzone für unseren öffentlichen Domänennamen (der sich von unserem internen Domänennamen unterscheidet). Ich musste die MX-Einträge in dieser internen Forward-Lookup-Zone hinzufügen, um sie mit den MX-Einträgen in unseren öffentlichen DNS-Einträgen abzugleichen. Dies löste das Problem.