Toimitusilmoitus sisältää usein useita palvelimien nimiä, päivämääriä ja osoitteita. Raportin lähettänyt järjestelmä ei välttämättä ole se järjestelmä, joka hylkäsi viestin. Jäsennä sen toimitustilakentät ja korreloi alkuperäinen yritys ennen DNS tai postilaatikon muutoksen tekemistä raportin aiherivin perusteella.
Tunnista raportointi- ja etäjärjestelmät
RFC 3464 määrittää toimitustilan runkomuodon. Reporting-MTA tunnistaa ilmoituksen tuottavan järjestelmän. Remote-MTA, jos se on olemassa, tunnistaa raportoituun toimitusyritykseen liittyvän etäjärjestelmän. Diagnostic-Code voi säilyttää etäprotokollan vastauksen. Ihmisen luettava selitys on hyödyllinen, mutta sen proosa ei saisi korvata strukturoituja kenttiä. RFC 3464 kohdat 2.2 ja 2.3.
Kirjaa sekä järjestelmän tunnistetiedot että raportoidut ajat. Välittäjä, joka hyväksyi sähköpostin sovelluksesta, voi myöhemmin saada hylkäysilmoituksen vastaanottajapalvelimelta ja rakentaa itse DSN:n. Välittimen nimen käsitteleminen hylkäyskohteena voi lähettää tutkimuksen väärälle järjestelmänvalvojalle ja hämärtää alkuperäisen SMTP vastauksen.
Lue jokainen vastaanottajalohko itsenäisesti
Lopullinen vastaanottaja tunnistaa vastaanottajan, jota toimitustilan lohko koskee. Alkuperäinen vastaanottaja, kun se on läsnä, voi säilyttää aikaisemman vastaanottajan identiteetin. Toiminto kuvaa toimitustoimintoa, kuten epäonnistunut tai viivästynyt. Status sisältää parannetun tilakoodin. Valinnainen diagnostiikkakoodi, viimeinen yrityspäivä ja Yritä uudelleen asti voivat tarjota hyödyllistä lisäkontekstia, mutta kaikki raportit eivät tarjoa niitä.
Kun diagnostiikkakoodi on olemassa, RFC 3464 kohta 2.3.6 tulkitsee toimitetun Remote-MTA:n myöntäjäkseen; ilman Remote-MTA:ta diagnostiikka johtuu Reporting-MTA:sta. Tämä kenttäsääntö ei todista, etteikö aikaisempaa etäyritystä ole koskaan tapahtunut. Vahvista koko historia luotetuilla lokeilla.
DSN voi sisältää useita vastaanottajalohkoja erilaisilla toimilla ja tila-arvoilla. Älä käytä yhtä virhettä kaikille alkuperäisessä To- tai Cc-otsikossa. Vastaavasti puuttuva valinnainen kenttä ei ole todiste siitä, että vastaavaa tapahtumaa ei koskaan tapahtunut. Pidä poissaolo tuntemattomana ja käytä jono- tai jäljitystodisteita aukon täyttöön.
Lue hypoteettinen voimassaolon päättymisilmoitus
Kuvittele, että relay.example hyväksyy viestin ja vastaanottaa sitten 452 4.2.2 Postilaatikko täynnä osoitteesta mx.example , kun sitä yritetään toimittaa. Kun sen määritetty toimitusaika on umpeutunut, rele tuottaa DSN:n. Opetusote voisi tunnistaa Reporting-MTA: dns; relay.example , Remote-MTA: dns; mx.example , Lopullinen vastaanottaja: rfc822; recipient@example.test , Toiminto: epäonnistui, Tila: 5.4.7 ja diagnostiikkakoodi: smtp; 452 4.2.2 Postilaatikko täynnä.
Tämä on keksitty kenttäopastus, ei täydellinen MIME raportti tai suoritettu sähköpostinvaihto. Lopullinen tila kuvaa toimitusajan päättymistä, kun taas säilynyt diagnoosi kuvaa viimeistä kapasiteetin epäämistä. Kentät vastaavat erilaisiin kysymyksiin. Tämä ei ole yleinen suositeltu kartoitus: RFC 3463 n osio 3.5 käskee palauttaa todellisen toimitusongelmakoodin vanhenemisen sijaan, jos mahdollista. Säilytä tarkin tuettu syy. RFC 3464 sallii myös toiminnon: epäonnistui 4.xx-tilassa raportoinnin jälkeen MTA on hylännyt yritykset; ohimenevä syy ei tarkoita, että alkuperäinen jää jonoon.
Yhdistä omaa raporttiasi varten alkuperäinen lähetys, yritykset, vanhentumispäätös ja raportti saapumisesta erikseen. Älä oleta, että kuvaavat nimet, ajoitus tai kentät vastaavat palveluntarjoajaa. Säilytä puuttuvat valinnaiset kentät täyttämättä niitä arvatuilla arvoilla.
Korreloi ennen kuin toimit
Yhdistä ilmoitus alkuperäisen kirjekuoren vastaanottajaan, lähetysaikaan ja käytettävissä oleviin jonotunnisteisiin. Original-Envelope-Id voi auttaa korrelaatiossa, kun se on olemassa; palautettu Message-ID on toinen vihje eikä itse ilmoituksen riittävä todennus. Raportit voivat olla väärennettyjä tai väärennettyjä paluupolku osoitteita, joten odottamaton palautus ei saa automaattisesti laukaista lähettäjän asetusten muutosta.
Käytä luotettavia lähetyslokeja varmistaaksesi, että organisaatio todella lähetti viestin. Vältä avaamasta palautettuja liitteitä tai seuraamasta valtuustietokehotteita vain siksi, että viesti muistuttaa palautusta. Jos vastaavaa palautetta ei ole, tutki raporttia mahdollisesti pyytämättömänä tai väärennetynä sen sijaan, että käsittelet sitä todisteena tilin vaarantumisesta.
Määritä korjaus oikealle tasolle
Osoitteen tila siirtyy postilaatikkoon tai ota yhteyttä omistajaan. Reitti- tai yhteysongelma vaatii kuljetustodisteita. Todennusdiagnostiikka vaatii todelliset asiaankuuluvat viestitunnisteet ja vastaanottoarvioinnin. Säilytä täydellinen diagnoosi, jotta asiantuntija voi erottaa samannäköiset viat.
Korreloi kaikki uudet yritykset hyväksytyn korjauksen jälkeen sen omiin jonoihin ja viestitunnisteisiin. Älä korvaa historiallista raporttia myöhemmällä tuloksella. Sulje alkuperäinen vika, korjaus ja vaihtotoimitus toisiinsa liittyvinä mutta erillisinä tapahtumina. Tämä säilyttää rehellisen aikajanan, kun viivästynyt raportti saapuu onnistuneen uudelleenlähetyksen jälkeen.
Valmistele vastaanottajakohtainen eskalaatio
- Korrelaatio: yhdistä raportti lailliseen lähetykseen käyttämällä vastaanottajaa, aikaa ja jonotodisteita.
- Myöntäjä: säilytä Reporting-MTA erillään Remote-MTA:sta ja diagnostiikan myöntäjästä.
- Tulos: Säilytä toiminto, tila ja alkuperäinen diagnostiikkakoodi pakottamatta niitä vastaamaan.
- Omistaja: määritä varsinainen vikakerros, ei pelkkä palautuksen lähettäjä.
- Yksityisyys: anna vain tarpeelliset raporttikentät; älä lähetä asiaankuulumatonta palautetun viestin sisältöä.