En forbedret statuskode er et struktureret fingerpeg, ikke en komplet hændelsesrapport. "5.7.1" kan indsnævre undersøgelsen i retning af sikkerhed eller politik, men den kan ikke identificere politikejeren, den berørte rute eller den korrekte konfigurationsændring alene. Opbevar den komplette diagnostik ved siden af koden under fejlfindingen.
Læs alle tre komponenter
RFC 3463 definerer forbedrede statuskoder med klasse-, emne- og detaljekomponenter. Klassen skelner mellem succes, vedvarende forbigående fiasko og permanent fiasko. Emnekategorier skelner mellem områder som adressering, postkassetilstand, routing og sikkerhed eller politik. Detaljen indsnævrer tilstanden inden for det pågældende emne. Det almindelige trecifrede SMTP svar forbliver en del af beviset. RFC 3463.
Behandl ikke det endelige nummer som en global fejlidentifikator. Betydningen afhænger af den komplette forbedrede kode og gældende registrerings- eller udbyderdokumentation. Et modtagesystem kan også returnere nyttig prosa uden en forbedret kode. Hvis de grundlæggende og forbedrede klasser virker inkonsekvente, bevar de nøjagtige bytes og undersøg udbyderens adfærd i stedet for i det stille at omskrive loggen.
Adskil SMTP svar fra leveringsrapporter
Et SMTP svar opstår under en samtale. En leveringsstatusmeddelelse kan rapportere resultater senere og kan beskrive flere modtagere. RFC 3464 definerer felter, herunder Final-Recipient, Action, Status, Remote-MTA og Diagnostic-Code. Læs per-modtager-blokkene uafhængigt; en fejl beviser ikke, at hver modtager fejlede. RFC 3464 afsnit 2.
Handling og Status besvarer forskellige spørgsmål. Handling: mislykkedes betyder rapporteringen MTA har stoppet forsøg for den pågældende modtager. Status: 4.2.2 kan stadig beskrive den forbigående postkasse-fuld årsag efter genforsøg er opbrugt; mislykkedes plus en 4.xx-status er gyldig i et DSN, ikke et inkonsekvent SMTP svar. For eksempel vil en udløbet vare med disse felter ikke genoptages automatisk, blot fordi kapaciteten vender tilbage. Kontroller den faktiske kø, før du godkender en erstatning. Se RFC 3464 afsnit 2.3.3.
Et menneske-læsbart afvist emne er nyttigt til triage, men kan udelade de afgørende felter. Få den maskinlæsbare rapport eller sendelog, når det er muligt. Hold rapporteringsserveren adskilt fra fjernserveren, og skeln en rapports tidsstempel fra tidsstemplet for den mislykkede SMTP kommando.
Læs en hypotetisk modtagerblok
Antag, at en afsendelseslog registrerer RCPT TO for missing@example.test efterfulgt af 550 5.1.1. En illustrativ DSN-modtagerblok kunne indeholde Final-Recipient: rfc822; missing@example.test , Handling: mislykkedes, Status: 5.1.1, Remote-MTA: dns; mx.example .test og Diagnostic-Code: smtp; 550 5.1.1 Ingen sådan bruger. Disse er opfundne feltværdier, ikke en udført transaktion eller en komplet MIME rapport.
Den mislykkede handling er endelig for denne modtager, mens diagnosticeringen peger på adressering. Det fastslår ikke, hvorfor adressen er utilgængelig, eller hvad der skete med andre modtagere. Få disse svar fra deres egne blokke og betroede logfiler. Final-Recipient, Action og Status er obligatoriske pr. modtager felter; Remote-MTA og Diagnostic-Code er betingede eller valgfrie. Deres fravær er ikke tilladelse til at opfinde en afvisende vært eller fejltekst.
For ukendte registrerede detaljer, se den aktuelle IANA forbedret statusregister og den citerede specifikation, derefter udbyderens aktuelle forklaring. RFC 3463 leverer rammen, ikke en udtømmende liste over hver senere kode.
Gør koden til en testbar hypotese
For en adresseringskode skal du bekræfte den tilsigtede adresse og modtagesystemets adfærd. For en routingkode skal du inspicere den mislykkede næste hop og rutekonfiguration. For en sikkerheds- eller politikkode skal du identificere det navngivne krav og dets ejer. Undgå at starte med en foretrukken DNS ændring og derefter fortolke hvert svar som understøttelse af det.
Optag en hypotese, beviserne den forudsiger og den mindste autoriserede test. En rettet besked skal sammenlignes med originalen på den relevante rute og modtagerklasse. Bevar et modstridende resultat som nyttigt bevis i stedet for at tvinge det ind i den oprindelige forklaring. Eskaleringspakker bør omfatte tidsstempler, nøjagtigt svar, berørt omfang og ændringer, der allerede er testet, med beskedindhold og personlige data minimeret. Et kodeopslag er begyndelsen på diagnosen, ikke dens afslutning.
Byg en nyttig eskaleringspakke
- Identitet: behold meddelelses- og kø-id'erne, konvolutmodtageren og det berørte omfang.
- Tidslinje: Registrer indsendelse, mislykket forsøg og rapportankomst separat.
- Diagnose: Inkluder det nøjagtige SMTP svar, kommandotrin og DSN-felter pr. modtager.
- Ejerskab: skelne rapporteringssystemet fra det afvisende system, med bevis for hver.
- Næste trin: angiv en testbar årsag, den mindste autoriserede kontrol og eventuelle modstridende beviser. Minimer personlige data.