Parannettu tilakoodi on jäsennelty vihje, ei täydellinen tapahtumaraportti. "5.7.1" voi rajata tutkimuksen turvallisuuteen tai käytäntöön, mutta se ei voi tunnistaa käytännön omistajaa, vaikuttanutta reittiä tai korjata konfiguraatiomuutosta yksinään. Pidä täydellinen diagnostiikka koodin vieressä vianmäärityksen ajan.
Lue kaikki kolme osaa
RFC 3463 määrittelee parannetut tilakoodit luokka-, aihe- ja yksityiskohtakomponenteilla. Luokka erottaa onnistumisen, jatkuvan ohimenevän epäonnistumisen ja pysyvän epäonnistumisen. Aiheluokat erottavat alueet, kuten osoite, postilaatikon tila, reititys ja turvallisuus tai käytäntö. Yksityiskohta kaventaa aihetta. Tavallinen kolminumeroinen SMTP vastaus on edelleen osa todisteita. RFC 3463.
Älä käsittele lopullista numeroa globaalina virhetunnisteena. Merkitys riippuu täydellisestä parannetusta koodista ja sovellettavasta rekisteröinti- tai toimittajadokumentaatiosta. Vastaanottava järjestelmä voi myös palauttaa hyödyllistä proosaa ilman parannettua koodia. Jos perus- ja lisäluokat vaikuttavat epäjohdonmukaisilta, säilytä tarkat tavut ja tutki palveluntarjoajan toimintaa sen sijaan, että kirjoitat lokia hiljaa.
Erota SMTP vastaukset toimitusraporteista
SMTP vastaus tapahtuu keskustelun aikana. Toimituksen tilailmoitus voi raportoida tulokset myöhemmin ja kuvata useita vastaanottajia. RFC 3464 määrittelee kentät, mukaan lukien lopullinen vastaanottaja, toiminto, tila, etä-MTA ja diagnostiikkakoodi. Lue vastaanottajakohtaiset lohkot itsenäisesti; yksi epäonnistuminen ei todista jokaisen vastaanottajan epäonnistuneen. RFC 3464 osa 2.
Toiminta ja tila vastaavat eri kysymyksiin. Toimi: epäonnistunut tarkoittaa raportointia MTA on lopettanut kyseisen vastaanottajan yritykset. Tila: 4.2.2 voi silti kuvata ohimenevän postilaatikon täyttymisen syyn uudelleenyritysten loppumisen jälkeen; epäonnistui plus 4.xx-tila on kelvollinen DSN:ssä, ei epäjohdonmukainen SMTP vastaus. Esimerkiksi vanhentunut tuote näillä kentillä ei jatku automaattisesti vain siksi, että kapasiteetti palaa. Tarkista todellinen jono ennen kuin hyväksyt vaihdon. Katso RFC 3464 kohta 2.3.3.
Ihmisen luettavissa oleva pomppimiskohde on hyödyllinen lajittelussa, mutta se voi jättää pois ratkaisevat kentät. Hanki koneellisesti luettava raportti tai lähetysloki, jos mahdollista. Pidä raportointipalvelin erillään etäpalvelimesta ja erota raportin aikaleima epäonnistuneen SMTP komennon aikaleimasta.
Lue hypoteettinen vastaanottajalohko
Oletetaan, että loki tallentaa RCPT TO:lle missing@example.test jälkeen 550 5.1.1. Havainnollistava DSN-vastaanottajalohko voisi sisältää Final-Recipient: rfc822; missing@example.test , Toiminto: epäonnistui, Tila: 5.1.1, Remote-MTA: dns; mx.example .test ja diagnostiikkakoodi: smtp; 550 5.1.1 Ei tällaista käyttäjää. Nämä ovat keksittyjä kenttäarvoja, eivät suoritettua tapahtumaa tai täydellistä MIME raporttia.
Epäonnistunut toiminto on lopullinen tälle vastaanottajalle, kun taas diagnostiikka viittaa osoitteeseen. Se ei kerro, miksi osoite ei ole käytettävissä tai mitä muille vastaanottajille tapahtui. Hanki nämä vastaukset omista lohkoistaan ja luotettavista lokeistaan. Lopullinen vastaanottaja, Toiminto ja Tila ovat pakollisia vastaanottajakohtaisia kenttiä. Remote-MTA ja Diagnostic-Code ovat ehdollisia tai valinnaisia. Heidän poissaolonsa ei ole lupa keksiä hylkäävä isäntä tai virheteksti.
Jos haluat tuntemattomia rekisteröityjä tietoja, katso nykyinen IANA parannettu tilarekisteri ja lainattu spesifikaatio, sitten palveluntarjoajan nykyinen selitys. RFC 3463 tarjoaa puitteet, ei tyhjentävää luetteloa kaikista myöhemmistä koodeista.
Muuta koodi testattavaksi hypoteesiksi
Vahvista osoitekoodia varten tarkoitettu osoite ja vastaanottojärjestelmän toiminta. Tarkista reitityskoodin epäonnistuneet seuraavan hypyn ja reittiasetukset. Jos haluat turva- tai käytäntökoodin, tunnista nimetty vaatimus ja sen omistaja. Vältä aloittamasta ensisijaisella DNS muutoksella ja tulkitsemasta sitten jokaista vastausta sen tukena.
Kirjaa yksi hypoteesi, sen ennustamat todisteet ja pienin sallittu testi. Korjattua viestiä tulee verrata alkuperäiseen kyseisellä reitillä ja vastaanottajaluokassa. Säilytä ristiriitainen tulos hyödyllisenä todisteena sen sijaan, että pakottaisit sen alkuperäiseen selitykseen. Eskalointipakettien tulee sisältää aikaleimat, tarkka vastaus, vaikutusalue ja jo testatut muutokset, ja viestien sisältö ja henkilötiedot on minimoitu. Koodihaku on diagnoosin alku, ei sen valmistuminen.
Rakenna hyödyllinen eskalaatiopaketti
- Identiteetti: säilytä viestin ja jonon tunnisteet, epäonnistunut kirjekuoren vastaanottaja ja vaikutusalue.
- Aikajana: tietueen lähetys, epäonnistunut yritys ja raportin saapuminen erikseen.
- Diagnoosi: sisällytä tarkka SMTP vastaus, komentovaihe ja vastaanottajakohtaiset DSN-kentät.
- Omistajuus: erottele raportointijärjestelmä hylkäävästä järjestelmästä ja esitä todisteet jokaisesta.
- Seuraava vaihe: Ilmoita yksi testattava syy, pienin valtuutettu tarkistus ja mahdolliset ristiriitaiset todisteet. Minimoi henkilötiedot.