“ SMTP time-out” kan verschillende gebeurtenissen beschrijven. Er is mogelijk een time-out opgetreden bij een DNS query, een TCP-verbinding is mogelijk niet voltooid of een tot stand gebrachte verbinding heeft mogelijk te lang gewacht op een begroeting of een laatste antwoord op het bericht. Deze fasen brengen verschillend bewijsmateriaal en verschillende risico's op dubbele levering met zich mee. Identificeer de fase voordat u een reparatie kiest.
Bepaal de bestemming voordat u deze test
Registreer het ontvangende domein en het daadwerkelijk gebruikte MX antwoord, inclusief voorkeurswaarden en opzoektijd. RFC 5321 beschrijft MX selectie en adresresolutie, inclusief impliciet MX gedrag wanneer nee MX records bestaan. Wanneer het domein bestaat maar geen MX records heeft, wordt bij impliciete MX afhandeling het domein zelf gebruikt met de toepasselijke adresrecords; NXDOMAIN en tijdelijke DNS fouten zijn verschillende resultaten. Dat is anders dan een expliciete null MX declaratie, die aangeeft dat een domein geen e-mail accepteert onder RFC 7505 . Converteer niet elk ongebruikelijk DNS resultaat naar een geraden bestemming. RFC 5321 sectie 5.
Bewaar voor elke geselecteerde host de relevante adresfamilieresultaten en het verbindingsresultaat. Uit een succesvolle IPv4 test blijkt niet dat het IPv6 pad van de falende afzender werkt. Op dezelfde manier bewijst een werkend resultaat van een openbare oplosser niet wat een bepaald verzendend systeem eerder zag. Registreer DNS fouten afzonderlijk van succesvolle antwoorden die naar onbereikbare hosts verwijzen.
Maak onderscheid tussen weigering en stilte
Een verbindingsweigering duidt doorgaans op een expliciete weigering van de poging tot TCP-verbinding. Een time-out betekent dat de verwachte gebeurtenis niet binnen het toegestane interval is waargenomen. Geen van beide observaties alleen identificeert de verantwoordelijke firewall, service-eigenaar of route. Filtering, netwerkfouten, beschikbaarheid van luisteraars en andere omstandigheden kunnen soortgelijke, voor de gebruiker zichtbare symptomen veroorzaken.
Nadat TCP is gelukt, controleert u of de server de SMTP begroeting heeft verzonden. Identificeer vervolgens het exacte commando dat op een reactie wacht. RFC 5321 specificeert verschillende time-outrichtlijnen voor verschillende SMTP fasen. De korte diagnostische time-out van een operator is een testkeuze en geen bewijs dat er sprake is van een productie MTA deze vereisten schendt of eraan voldoet. Pas niet één agressieve time-out toe op elke fase en noem het resultaat definitief.
Behoud onzekerheid na berichtoverdracht
Een time-out na de laatste berichtgegevens is gevoeliger dan een mislukte verbinding. De ontvanger zou de verantwoordelijkheid op zich hebben kunnen nemen terwijl zijn uiteindelijke antwoord verloren was gegaan. Het herhalen van de transactie kan dus een duplicaat opleveren. Houd de status van het uiteindelijke antwoord op onbekend, tenzij het verzenden en ontvangen van bewijs dit probleem oplost; label het bericht niet automatisch als ‘nooit ontvangen’. RFC 5321 paragrafen 4.5.3.2 en 6.1.
Bij verbindingsfouten voorafgaand aan een SMTP uitwisseling is er geen bericht verzonden via die verbinding. Die engere conclusie beschrijft nog steeds niet eerdere pogingen in dezelfde wachtrij. Correleer alle pogingen voordat u besluit of een zakelijke transactie opnieuw moet worden ingediend.
Vergelijk drie hypothetische time-outrecords
Geval A brengt nooit TCP tot stand voor de geselecteerde MX . Houd de diagnose in de aansluitfase; er is geen SMTP bericht over die verbinding gegaan. Geval B stelt TCP in, maar registreert geen begroeting vóór de door het diagnostische hulpmiddel gekozen deadline. Onderzoek het gedrag van de luisteraar en de relevante time-out voor de begroeting, in plaats van dit dezelfde fout te noemen als A.
Geval C verzendt berichtgegevens en de terminator ervan, maar verliest het uiteindelijke antwoord. Acceptatie is onbekend, dus controleer de wachtrij van de afzender en het bewijs van de ontvanger voordat u nog een kopie toevoegt. Deze verzonnen cases bevatten geen uitgevoerde sockettests, gemeten herstel of timingclaim van de provider. Een korte diagnostische time-out is geen productieaanbeveling.
Voor een echt niet-beschikbaar-MX-incident bewaart u de opgeloste hosts en voorkeuren, elke poging tot adresfamilie, mislukte fase- en wachtrijbeslissing. Een MX met een lagere prioriteit die in een zelfstandige test werkt, bewijst niet dat de betrokken afzender deze heeft gebruikt; controleer de geschiedenis van de daadwerkelijke pogingen.
Repareer en bevestig het getroffen pad
Wijs DNS , netwerk- en mailservicebewijs toe aan hun respectievelijke eigenaren. Test dezelfde goedgekeurde bestemming en adresfamilie opnieuw na één relevante correctie, en bewaar een vergelijking met een ander geautoriseerd netwerk alleen als dit nuttig is. Bevestig wachtrijherstel en verouderingsberichten voordat u succes verklaart. Verzwak de e-mailauthenticatie niet omdat er geen TCP-sessie tot stand kon worden gebracht.
Kies de eigenaar van de mislukte fase
- DNS fout: bewaar het daadwerkelijke resultaat en de tijd van de oplossing.
- TCP-fout: recordbestemming, adresfamilie en padbewijs.
- Begroeting of commando wacht: geef het ontbrekende antwoord en de geconfigureerde time-out een naam.
- Het definitieve DATA-antwoord ontbreekt: acceptatie afstemmen vóór handmatige herindiening.
- Herstel: houd rekening met verouderde en verlopen wachtrij-items, niet slechts één succesvolle verbinding.