Mail Stuck in Queue LastError: 451 4.4.0 SMTPSEND.SuspiciousRemoteServerError; remote server disconnected abruptly; retry will bedelayed

Prolog:

Bei diesem Kundensystem handelt es sich um eine Exchange 2013 Umgebung mit mehreren MultiRole Servern in einer DAG.
Es gibt einen Send Connector zu einer MTA Infrastruktur mit mehreren MTAs. Dabei wird die VIP der MTA Infrastruktur angesprochen.

Ausgangslage:

Bei der Umgebung  stellten wir fest, dass vermehrt E-Mails mit dem folgenden SMTP Error in den Queues stecken bleiben.

Es bleiben bei allen Servern Mails in der SmartHost Queue stecken – das Problem scheint also durch den Smarthost verursacht zu werden.

Die meisten E-Mails werden jedoch erfolgreich verarbeitet (von und zu der MTA Infrastruktur).

 

 Überprüfung:

Mit folgendem Befehl habe ich mir die relevanten Informationen der E-Mails aus den Queues ausgelesen.

Ich habe die Mails ebenfalls zur weiteren Analyse aus der Queue exportiert (Betrachtung eines Mails via Outlook kann durchaus einiges vereinfachen – Headerinformationen des Mails, Auflistung Empfänger etc.)

Ausser der grossen Empfängeranzahl (bis zu 150 Empfänger) konnte ich jedoch keine ungewöhnlichen Informationen im E-Mail identifizieren.

Somit prüfte ich die erlaubten Limiten

Kann also nicht das Problem sein.

Für diejenigen die sagen, es gibt doch noch eine Stelle um die MaxRecipients einzuschränken. Genau, nur wurde das Message bereits angenommen durch den Receive Connector – so dass dieses Limit nicht zutreffen kann. Geprüft werden könnte das Limit mit folgendem Befehl, für diejenigen die es dennoch lieber geprüft haben (Ich hab die ReceiveConnector in dem Befehl nicht gefiltert – sry, zu lacy – welcher ReceiveConnector zur Anwendung kommt, könnte aus dem Get-Message Befehl ausgelesen werden – Attribut: MessageSourceName).

 

Der Verdacht scheint sich zu bestätigen, dass das Problem auf dem SmartHost zu suchen ist.
Die Abklärungen mit den Kollegen beim SmartHost ergibt schlussendlich folgendes Bild.

Der TCP Trace zeigt, dass der Exchange Server versucht das Mail beim MTA zu deponieren, entsprechende SMTP Kommunikation ist ersichtlich.

Auf den ersten Blick konnte man auch aus dem TCP Trace nicht schlauer werden. Wir bemerkten aber, dass jeweils nach dem 100sten Empfänger die Verbindung getrennt wurde. Dies löste Verwunderung aus, da nach unserem Wissensstand keine Filterregeln oder ähnliches zwischen der Verbindung aktiv sein sollte.

 

Lösung:

Wir mussten leider feststellen, dass unser Wissensstand nicht korrekt war. Der Kunde hat vor wenigen Tagen eine neue Cisco ASA erhalten welche per Standard das ESMTP Inspection aktiv hat.

Quelle Cisco

Wie aus dem Referenzartikel zu entnehmen:

Als wir das ESMTP Inspection auf der ASA deaktiviert haben konnten die Mails erfolgreich durch den Exchange abgearbeitet werden.

 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.