En leveringsmelding inneholder ofte flere servernavn, datoer og adresser. Systemet som sender rapporten er ikke nødvendigvis systemet som avviste meldingen. Analyser leveringsstatusfeltene og korreler det opprinnelige forsøket før du gjør en DNS eller postboksendring basert på rapportens emnelinje.
Identifiser rapporterings- og fjernsystemer
RFC 3464 definerer kroppsformatet for leveringsstatus. Rapportering-MTA identifiserer systemet som produserer varselet. Remote-MTA, når den er tilstede, identifiserer et eksternt system knyttet til det rapporterte leveringsforsøket. Diagnostisk kode kan bevare den eksterne protokollresponsen. Den menneskelesbare forklaringen er nyttig, men dens prosa bør ikke erstatte de strukturerte feltene. RFC 3464 avsnitt 2.2 og 2.3.
Registrer både systemidentiteter og de rapporterte tidspunktene. Et relé som godtok e-post fra applikasjonen kan senere motta et avslag fra en mottakerserver og konstruere DSN selv. Å behandle reléets navn som den avvisende destinasjonen kan sende en undersøkelse til feil administrator og skjule det opprinnelige SMTP svaret.
Les hver mottakerblokk uavhengig
Final-Recipient identifiserer mottakeren som en leveringsstatusblokk gjelder for. Original-mottaker, når den er tilstede, kan bevare en tidligere mottakeridentitet. Handling beskriver leveringshandlingen, for eksempel mislykket eller forsinket. Status har en forbedret statuskode. Valgfri diagnosekode, siste forsøksdato og vil prøve på nytt inntil kan gi nyttig tilleggskontekst, men ikke alle rapporter gir dem.
Når diagnosekode er tilstede, tolker RFC 3464 avsnitt 2.3.6 en medfølgende Remote-MTA som utsteder; uten Remote-MTA tilskrives diagnostikken Reporting-MTA. Denne feltregelen beviser ikke at det ikke har vært noen tidligere fjernforsøk. Bekreft hele historien med pålitelige logger.
Et DSN kan inkludere flere mottakerblokker med forskjellige handlinger og statusverdier. Ikke bruk én feil på alle i den originale Til- eller Kopi-overskriften. På samme måte er et manglende valgfritt felt ikke et bevis på at den tilsvarende hendelsen aldri har skjedd. Bevar fravær som ukjent og bruk kø- eller sporbevis for å fylle tomrommet.
Les en hypotetisk utløpsmelding
Tenk deg at relay.example godtar en melding, og deretter mottar 452 4.2.2 Mailbox full fra mx.example når du prøver å levere. Etter at den konfigurerte leveringstiden utløper, produserer reléet en DSN. Et undervisningsutdrag kan identifisere Reporting-MTA: dns; relay.example , Remote-MTA: dns; mx.example , Sluttmottaker: rfc822; recipient@example.test , Handling: mislyktes, Status: 5.4.7 og diagnosekode: smtp; 452 4.2.2 Postkasse full.
Dette er en oppfunnet feltgjennomgang, ikke en fullstendig MIME rapport eller en utført e-postutveksling. Den endelige statusen beskriver utløp av leveringstid, mens den bevarte diagnostikken beskriver siste kapasitetsavslag. Feltene svarer på ulike spørsmål. Dette er ikke en universell foretrukket kartlegging: RFC 3463 seksjon 3.5 sier å returnere den faktiske leveringsproblemkoden i stedet for utløp når det er mulig. Bevar den mest spesifikke støttede saken. RFC 3464 tillater også Handling: mislyktes med en 4.xx-status etter rapporteringen MTA har forlatt forsøk; en forbigående årsak betyr ikke at originalen forblir i kø.
For din egen rapport, korreler original innlevering, forsøk, utløpsbeslutning og rapportankomst separat. Ikke anta at de illustrative navnene, timingen eller feltene samsvarer med en leverandør. Behold manglende valgfrie felt uten å fylle dem med gjettede verdier.
Korreler før du handler
Match varselet med den opprinnelige konvoluttmottakeren, innsendingstid og tilgjengelige køidentifikatorer. Original-Envelope-Id kan hjelpe korrelasjon når den er tilstede; en returnert meldings-ID er en annen ledetråd i stedet for tilstrekkelig autentisering av selve varselet. Rapporter kan være forfalsket eller forårsaket av forfalsket retur-sti adresser, så en uventet retur må ikke automatisk utløse en avsenderkonfigurasjonsendring.
Bruk pålitelige sendelogger for å fastslå at organisasjonen faktisk sendte meldingen. Unngå å åpne returnerte vedlegg eller følge instruksjoner om påloggingsinformasjon bare fordi meldingen ligner en sprett. Hvis det ikke finnes noen samsvarende innsending, undersøk rapporten som potensielt uønsket eller forfalsket i stedet for å behandle den som bevis på kontokompromittering.
Tilordne korrigeringen til høyre lag
En adresseringsstatus går til postkassen eller kontakteieren. Et rute- eller forbindelsesproblem trenger transportbevis. En autentiseringsdiagnose krever de faktiske relevante meldingsidentitetene og mottaksevaluering. Ta vare på den fullstendige diagnostikken slik at spesialisten kan skille feil som ser lignende ut.
Etter en godkjent korreksjon, korreler ethvert nytt forsøk med sine egne kø- og meldingsidentifikatorer. Ikke overskriv den historiske rapporten med det senere resultatet. Lukk den opprinnelige feilen, reparasjonen og erstatningsleveringen som relaterte, men forskjellige hendelser. Dette bevarer en ærlig tidslinje når en forsinket rapport kommer etter en vellykket gjensending.
Forbered en mottakerspesifikk eskalering
- Korrelasjon: match rapporten med en legitim innsending ved å bruke mottaker-, tids- og købevis.
- Utsteder: behold Reporting-MTA separat fra Remote-MTA og diagnoseutstederen.
- Utfall: bevar handling, status og original diagnosekode uten å tvinge dem til å matche.
- Eier: tilordne det faktiske feillaget, ikke bare avsenderen av returen.
- Personvern: oppgi bare nødvendige rapportfelt; ikke videresend urelatert returnert meldingsinnhold.