„ SMTP Zeitüberschreitung“ kann verschiedene Ereignisse beschreiben. Möglicherweise ist eine DNS Abfrage abgelaufen, eine TCP-Verbindung wurde möglicherweise nicht hergestellt oder eine hergestellte Verbindung hat möglicherweise zu lange auf eine Begrüßung oder eine abschließende Nachrichtenantwort gewartet. In diesen Phasen gibt es unterschiedliche Beweise und unterschiedliche Risiken für die Zustellung von Duplikaten. Identifizieren Sie die Phase, bevor Sie sich für eine Reparatur entscheiden.
Lösen Sie das Ziel auf, bevor Sie es testen
Erfassen Sie die Empfängerdomäne und die tatsächlich verwendete MX Antwort, einschließlich Präferenzwerten und Suchzeit. RFC 5321 beschreibt MX Auswahl und Adressauflösung, einschließlich implizitem MX Verhalten, wenn nein MX Einträge existieren. Wenn die Domäne vorhanden ist, aber über keine MX Einträge verfügt, verwendet die implizite MX Verarbeitung die Domäne selbst mit den entsprechenden Adressdatensätzen. NXDOMAIN und temporäre DNS Fehler sind unterschiedliche Ergebnisse. Das unterscheidet sich von einer expliziten Null MX Deklaration, die signalisiert, dass eine Domain keine E-Mails gemäß RFC 7505 akzeptiert. Wandeln Sie nicht jedes ungewöhnliche DNS Ergebnis in ein vermutetes Ziel um. RFC 5321 Abschnitt 5.
Behalten Sie für jeden ausgewählten Host relevante Adressfamilienergebnisse und das Verbindungsergebnis bei. Ein erfolgreicher IPv4 Test stellt nicht sicher, dass der IPv6 Pfad des fehlerhaften Absenders funktioniert. Ebenso beweist ein funktionierendes öffentliches Resolver-Ergebnis nicht, was ein bestimmtes sendendes System zuvor gesehen hat. Erfassen Sie DNS Fehler getrennt von erfolgreichen Antworten, die auf nicht erreichbare Hosts hinweisen.
Unterscheiden Sie Verweigerung von Schweigen
Eine Verbindungsverweigerung weist normalerweise auf eine explizite Ablehnung der versuchten TCP-Verbindung hin. Eine Zeitüberschreitung bedeutet, dass das erwartete Ereignis nicht innerhalb des zulässigen Intervalls beobachtet wurde. Keine der Beobachtungen allein identifiziert die verantwortliche Firewall, den Dienstbesitzer oder die verantwortliche Route. Filterung, Netzwerkfehler, Hörerverfügbarkeit und andere Bedingungen können ähnliche, für den Benutzer sichtbare Symptome hervorrufen.
Nachdem TCP erfolgreich war, notieren Sie, ob der Server seine SMTP Begrüßung gesendet hat. Identifizieren Sie dann den genauen Befehl, der auf eine Antwort wartet. RFC 5321 spezifiziert unterschiedliche Timeout-Richtlinien für mehrere SMTP Stufen. Das kurze Diagnose-Timeout eines Bedieners ist eine Testentscheidung und kein Beweis für eine Produktion MTA gegen diese Anforderungen verstößt oder diese erfüllt. Wenden Sie nicht auf jede Stufe ein aggressives Timeout an und bezeichnen Sie das Ergebnis als endgültig.
Bewahren Sie die Unsicherheit nach der Nachrichtenübertragung
Eine Zeitüberschreitung nach den endgültigen Nachrichtendaten ist schwerwiegender als ein Verbindungsfehler. Der Empfänger hätte möglicherweise die Verantwortung übernommen, während seine endgültige Antwort verloren ging. Eine Wiederholung der Transaktion kann daher zu einem Duplikat führen. Behalten Sie den Status der endgültigen Antwort als „Unbekannt“ bei, es sei denn, das Problem wird durch das Senden und Empfangen von Beweisen behoben. Kennzeichnen Sie die Nachricht nicht automatisch als „nie erhalten“. RFC 5321 Abschnitte 4.5.3.2 und 6.1.
Bei Verbindungsausfällen vor einem SMTP Austausch wurde über diese Verbindung keine Nachricht übertragen. Diese engere Schlussfolgerung beschreibt immer noch nicht frühere Versuche in derselben Warteschlange. Vergleichen Sie alle Versuche, bevor Sie entscheiden, ob eine Geschäftstransaktion erneut eingereicht werden muss.
Vergleichen Sie drei hypothetische Timeout-Datensätze
Fall A stellt niemals TCP zum ausgewählten MX her. Behalten Sie die Diagnose im Verbindungsstadium; Über diese Verbindung wurde keine SMTP Nachricht gesendet. Fall B richtet TCP ein, zeichnet aber keine 220-Begrüßung vor der vom Diagnosetool gewählten Frist auf. Untersuchen Sie das Zuhörerverhalten und die relevante Zeitüberschreitung bei der Begrüßung, anstatt es als denselben Fehler wie bei A zu bezeichnen.
Fall C überträgt Nachrichtendaten und deren Abschlusszeichen, verliert jedoch die endgültige Antwort. Die Akzeptanz ist unbekannt. Überprüfen Sie daher die Absenderwarteschlange und die Empfängernachweise, bevor Sie eine weitere Kopie hinzufügen. Diese erfundenen Fälle enthalten keine durchgeführten Socket-Tests, gemessenen Wiederherstellung oder Anbieter-Timing-Ansprüche. Ein kurzes Diagnose-Timeout ist keine Produktionsempfehlung.
Behalten Sie bei einem echten Nichtverfügbarkeits-MX-Vorfall die aufgelösten Hosts und Präferenzen, jede versuchte Adressfamilie, jede fehlgeschlagene Phasen- und Warteschlangenentscheidung bei. Ein MX mit niedrigerer Priorität, der in einem eigenständigen Test funktioniert, beweist nicht, dass der betroffene Absender ihn verwendet hat; Überprüfen Sie den tatsächlichen Versuchsverlauf.
Reparieren und bestätigen Sie den betroffenen Pfad
Weisen Sie DNS , Netzwerk- und Mail-Service-Beweise ihren jeweiligen Besitzern zu. Testen Sie dasselbe genehmigte Ziel und dieselbe Adressfamilie nach einer relevanten Korrektur erneut und behalten Sie einen Vergleich mit einem anderen autorisierten Netzwerk nur dann bei, wenn dies sinnvoll ist. Bestätigen Sie die Nachrichten zur Warteschlangenwiederherstellung und zur Alterung, bevor Sie den Erfolg melden. Schwächt die E-Mail-Authentifizierung nicht ab, weil keine TCP-Sitzung aufgebaut werden konnte.
Wählen Sie den Besitzer der fehlgeschlagenen Phase aus
- DNS Fehler: Behalten Sie das tatsächliche Resolver-Ergebnis und die tatsächliche Resolver-Zeit bei.
- TCP-Fehler: Ziel, Adressfamilie und Pfadnachweis aufzeichnen.
- Begrüßung oder Befehlswartezeit: Nennen Sie die fehlende Antwort und das konfigurierte Timeout.
- Die endgültige DATA-Antwort fehlt: Stimmen Sie die Annahme vor der manuellen erneuten Übermittlung ab.
- Wiederherstellung: Berücksichtigen Sie veraltete und abgelaufene Warteschlangenelemente, nicht nur eine erfolgreiche Verbindung.