" SMTP timeout" kan beskrive flere forskjellige hendelser. En DNS spørring kan ha blitt tidsavbrutt, en TCP-tilkobling kan ikke ha fullført, eller en etablert tilkobling kan ha ventet for lenge på en hilsen eller endelig meldingssvar. Disse stadiene har ulike bevis og ulike risikoer for duplikatlevering. Identifiser stadiet før du velger en reparasjon.
Bestem destinasjonen før du tester den
Registrer mottakerdomenet og MX svaret som faktisk brukes, inkludert preferanseverdier og oppslagstid. RFC 5321 beskriver MX valg og adresseoppløsning, inkludert implisitt MX atferd når nr MX poster eksistere. Når domenet eksisterer, men ikke har noen MX poster, bruker implisitt MX håndtering selve domenet med de aktuelle adressepostene; NXDOMAIN og midlertidige DNS feil er forskjellige resultater. Det er forskjellig fra en eksplisitt null MX erklæring, som signaliserer at et domene ikke godtar e-post under RFC 7505 . Ikke konverter alle uvanlige DNS resultater til en gjettet destinasjon. RFC 5321 del 5.
For hver valgt vert, bevar relevante adressefamilieresultater og tilkoblingsresultatet. En vellykket IPv4 test fastslår ikke at den mislykkede avsenderens IPv6 bane fungerer. På samme måte beviser ikke et fungerende offentlig resolver-resultat hva et bestemt sendesystem så tidligere. Registrer DNS feil separat fra vellykkede svar som peker på uoppnåelige verter.
Skille avslag fra stillhet
Et tilkoblingsavslag indikerer vanligvis en eksplisitt avvisning av forsøket på TCP-tilkobling. Et tidsavbrudd betyr at den forventede hendelsen ikke ble observert innenfor det tillatte intervallet. Ingen av observasjonene alene identifiserer ansvarlig brannmur, tjenesteeier eller rute. Filtrering, nettverksfeil, lyttertilgjengelighet og andre forhold kan gi lignende brukersynlige symptomer.
Etter at TCP lykkes, legg merke til om serveren sendte sin SMTP hilsen. Identifiser deretter den nøyaktige kommandoen som venter på svar. RFC 5321 spesifiserer distinkt tidsavbruddsveiledning for flere SMTP trinn. En operatørs korte diagnostiske timeout er et testvalg, ikke bevis på at en produksjon MTA bryter med eller tilfredsstiller disse kravene. Ikke bruk en aggressiv timeout på hver etappe og kall resultatet definitivt.
Bevar usikkerhet etter meldingsoverføring
Et tidsavbrudd etter de endelige meldingsdataene er mer delikat enn å ikke koble til. Mottakeren kan ha påtatt seg ansvaret mens det endelige svaret gikk tapt. Å gjenta transaksjonen kan derfor gi et duplikat. Hold den endelige responsstatusen som ukjent med mindre sending og mottak av bevis løser det; ikke automatisk merk meldingen "aldri mottatt." RFC 5321 avsnitt 4.5.3.2 og 6.1.
For tilkoblingsfeil før en SMTP utveksling, har ingen melding blitt overført på den tilkoblingen. Den smalere konklusjonen beskriver fortsatt ikke tidligere forsøk i samme kø. Korreler alle forsøk før du bestemmer deg for om en forretningstransaksjon trenger en ny innsending.
Sammenlign tre hypotetiske tidsavbruddsposter
Tilfelle A etablerer aldri TCP til valgt MX . Hold diagnosen på tilkoblingsstadiet; ingen SMTP melding krysset den forbindelsen. Tilfelle B etablerer TCP, men registrerer ingen 220-hilsen før diagnoseverktøyets valgte frist. Undersøk lytteratferd og den relevante hilsen-timeouten, i stedet for å kalle det samme feil som A.
Tilfelle C overfører meldingsdata og dens terminator, men mister det endelige svaret. Aksept er ukjent, så sjekk avsenderkøen og mottakerbeviset før du legger til en ny kopi. Disse oppfunne sakene inneholder ingen utførte socket-tester, målt gjenoppretting eller leverandørtidskrav. En kort diagnostisk timeout er ikke en produksjonsanbefaling.
For en reell utilgjengelig-MX-hendelse, behold de løste vertene og preferansene, hver forsøkt adressefamilie, mislykket stadium og køavgjørelse. En MX med lavere prioritet som fungerer i en frittstående test, beviser ikke at den berørte avsenderen brukte den. bekrefte den faktiske forsøkshistorikken.
Reparer og bekreft den berørte banen
Tildel DNS , nettverks- og e-posttjenestebevis til sine respektive eiere. Test den samme godkjente destinasjonen og adressefamilien på nytt etter én relevant korreksjon, og bevar en sammenligning fra et annet autorisert nettverk bare når det er nyttig. Bekreft køgjenoppretting og aldringsmeldinger før du erklærer suksess. Ikke svekk e-postautentisering fordi en TCP-økt ikke kunne opprettes.
Velg eieren av den mislykkede scenen
- DNS feil: behold det faktiske resolverresultatet og tiden.
- TCP-feil: Registrer destinasjon, adressefamilie og banebevis.
- Hilsen eller kommando vent: navngi det manglende svaret og konfigurert tidsavbrudd.
- Endelig DATA-svar mangler: avstem aksept før manuell innsending på nytt.
- Gjenoppretting: ta hensyn til aldrende og utløpte køelementer, ikke bare én vellykket tilkobling.