En förbättrad statuskod är en strukturerad ledtråd, inte en fullständig incidentrapport. "5.7.1" kan begränsa undersökningen mot säkerhet eller policy, men den kan inte identifiera policyägaren, påverkad rutt eller korrekt konfigurationsändring på egen hand. Behåll den fullständiga diagnostiken bredvid koden under hela felsökningen.
Läs alla tre komponenterna
RFC 3463 definierar förbättrade statuskoder med klass-, ämnes- och detaljkomponenter. Klassen skiljer på framgång, ihållande övergående misslyckande och permanent misslyckande. Ämneskategorier särskiljer områden som adressering, postlådestatus, routing och säkerhet eller policy. Detaljen begränsar tillståndet inom det ämnet. Det vanliga tresiffriga SMTP svaret förblir en del av bevisningen. RFC 3463.
Behandla inte det slutliga numret som en global felidentifierare. Innebörden beror på den fullständiga förbättrade koden och tillämplig registrering eller leverantörsdokumentation. Ett mottagande system kan också returnera användbar prosa utan en förbättrad kod. Om de grundläggande och förbättrade klasserna verkar inkonsekventa, bevara de exakta byten och undersök leverantörens beteende istället för att tyst skriva om loggen.
Separat SMTP svar från leveransrapporter
Ett SMTP svar inträffar under en konversation. Ett leveransstatusmeddelande kan rapportera resultat senare och kan beskriva flera mottagare. RFC 3464 definierar fält inklusive Final-Recipient, Action, Status, Remote-MTA och Diagnostic-Code. Läs blocken per mottagare oberoende av varandra; ett fel bevisar inte att varje mottagare misslyckades. RFC 3464 avsnitt 2.
Action och Status svarar på olika frågor. Åtgärd: misslyckad betyder rapporteringen MTA har stoppat försök för den mottagaren. Status: 4.2.2 kan fortfarande beskriva den tillfälliga orsaken till att brevlådan är full efter att återförsök har slutat; misslyckades plus en 4.xx-status är giltig i ett DSN, inte ett inkonsekvent SMTP svar. Till exempel kommer en utgången vara med dessa fält inte att återupptas automatiskt bara för att kapaciteten återgår. Kontrollera den faktiska kön innan du godkänner någon ersättning. Se RFC 3464 avsnitt 2.3.3.
Ett mänskligt läsbart studsämne är användbart för triage men kan utelämna de avgörande fälten. Skaffa den maskinläsbara rapporten eller sändningsloggen när det är möjligt. Håll rapportservern åtskild från fjärrservern och särskilj en rapports tidsstämpel från tidsstämpeln för det misslyckade SMTP kommandot.
Läs ett hypotetiskt mottagarblock
Antag att en sändningslogg registrerar RCPT TO för missing@example.test följt av 550 5.1.1. Ett illustrativt DSN-mottagareblock kan innehålla Final-Recipient: rfc822; missing@example.test , Åtgärd: misslyckades, Status: 5.1.1, Remote-MTA: dns; mx.example .test och Diagnostic-Code: smtp; 550 5.1.1 Ingen sådan användare. Dessa är uppfunna fältvärden, inte en utförd transaktion eller en fullständig MIME rapport.
Den misslyckade åtgärden är slutgiltig för den här mottagaren, medan diagnostiken pekar på adressering. Den fastställer inte varför adressen är otillgänglig eller vad som hände med andra mottagare. Få dessa svar från deras egna block och betrodda loggar. Slutlig mottagare, Åtgärd och Status är obligatoriska per mottagare; Remote-MTA och Diagnostic-Code är villkorade eller valfria. Deras frånvaro är inte tillåtelse att uppfinna en avvisande värd eller feltext.
För okända registrerade detaljer, se den aktuella IANA förbättrat statusregister och den citerade specifikationen, sedan leverantörens nuvarande förklaring. RFC 3463 tillhandahåller ramverket, inte en uttömmande lista över varje senare kod.
Förvandla koden till en testbar hypotes
För en adresseringskod, bekräfta den avsedda adressen och mottagningssystemets beteende. För en routingkod, inspektera den misslyckade nästa hopp- och ruttkonfigurationen. För en säkerhets- eller policykod, identifiera det namngivna kravet och dess ägare. Undvik att börja med en föredragen DNS ändring och sedan tolka varje svar som stöd för det.
Spela in en hypotes, bevisen den förutsäger och det minsta auktoriserade testet. Ett korrigerat meddelande ska jämföras med originalet på den aktuella färdvägen och mottagarklassen. Bevara ett motsägelsefullt resultat som användbart bevis snarare än att tvinga in det i den ursprungliga förklaringen. Eskaleringspaket bör innehålla tidsstämplar, exakt svar, påverkad omfattning och redan testade ändringar, med meddelandeinnehåll och personuppgifter minimerade. En koduppslagning är början på diagnosen, inte dess slutförande.
Bygg ett användbart eskaleringspaket
- Identitet: behåll meddelande- och köidentifierare, kuvertmottagare som inte fungerar och påverkad omfattning.
- Tidslinje: post inlämning, misslyckat försök och rapport ankomst separat.
- Diagnos: inkludera exakt SMTP svar, kommandosteg och DSN-fält per mottagare.
- Ägarskap: särskilj rapporteringssystemet från det avvisande systemet, med bevis för varje.
- Nästa steg: ange en testbar orsak, den minsta auktoriserade kontrollen och eventuella motstridiga bevis. Minimera personuppgifter.