DSN: obvestilo o stanju dostave za e-pošto SMTP

Ugotovite, kako je DSN namenjen uvesti dostavni status v e-pošto SMTP.

Ste se kdaj vprašali, kaj se je zgodilo z e-pošto, ki ste jo poslali?

Tudi le kratek pregled protokola SMTP boste opazili, da poleg običajnega HELO obstaja tudi EHLO, zaradi česar razširjeni SMTP strežnik oglašuje svoje zmogljivosti preko prvotnega standarda. Ena od teh je DSN. DSN? Ali sta DNK in DDT pomanjkljiva?

Da bi trdili, da je e-pošta nezanesljiva, da bi moral nekdo " ... bolje hraniti svoj strežnik, je pojedel mojo pošto ... " ni neobičajen. Delam sam. Vendar ni veliko razlogov za podporo tem sumom.

Dostava S tatus N otifikacijo je od leta RFC 821 (od leta 1982). Takoj ko je DATA del protokola SMTP končan in je strežnik sprejel e-poštno sporočilo za dostavo, je odgovoren za to. Če iz katerega koli razloga ne more priti do prejemnika, ga mora poslati nazaj z obvestilom o napaki prvotnemu pošiljatelju. To je povzročilo nekaj nejasnih e-poštnih sporočil .

Poleg tega je ta stara konvencija pomenila, da imate bodisi sporočilo o napaki ali pa niste dobili ničesar, v tem primeru niste vedeli ničesar : e-pošta je morda prišla ali pa ne. Sporočila o napakah v mnogih primerih so bila prav tako koristna, kot ni sporočil o napakah. Ker postaja e-pošta vedno bolj pomembna, to ni več zadovoljivo (kot če bi bilo prej).

Razširitve DSN v SMTP

RFC 1891 predlaga nekatere razširitve protokola SMTP , ki naj bi imeli za posledico bolj zanesljiv in bolj uporaben sistem DSN. To je niz razširitev za ukaze MAIL in RCPT (če to vam ne pomeni ničesar, preberite, kako SMTP deluje in se nato vrnite.).

Ne EHLO, ne zabava

Najprej moramo zagotoviti, da strežnik podpira DSN. Zato mu moramo reči EHLO in pozorno poslušati. Če se na seznamu funkcij odzove z DSN, lahko predpostavimo, da bo lahko služil našim zahtevam. Če ne, potem ne: lahko poskusimo drug strežnik ali preprosto spet na e-pošto brez DSN. Na primer (moj vnos je modro, strežnik je izpisan v črni barvi):

220 larose.magnet.at ESMTP Sendmail 8.8.6 / 8.8.6; Ned, 24 Avg 1997 18:23:22 +0200
EHLO localhost
250-larose.magnet.at Pozdravljeni lokalni gost [127.0.0.1], veseli me, da smo se spoznali
250-EXPN
250-VERB
250-8BITMIME
250-SIZE
250-DSN
250-ONEX
250-ETRN
250-XUSR
250 POMOČ

Na srečo, med drugim najdemo DSN.

Razširitve pošiljateljev DSN

Naslednji ukaz je ponavadi MAIL FROM :. Z DSN se to ne razlikuje. Obstaja pa še dve dodatni možnosti, ki jih lahko izdate: RET in ENVID.

Možnost RET je bila precej poljubno postavljena v ukaz MAIL, vendar se tukaj prilega in bi bilo drugje. Namen je določiti, koliko prvega sporočila morate vrniti v primeru okvare dostave. Veljavni argumenti so FULL in HDRS. Prva pomeni, da mora biti celotno sporočilo vključeno v sporočilo o napaki, HDRS ukazuje strežniku, da vrne samo glave neuspele pošte. Če RET ni podan, je odvisno od strežnika, kaj storiti. V večini primerov bo privzeta vrednost HDRS.

ENVID resnično pripada pošiljatelju, saj bo ta ali (precej) njen e-poštni odjemalec edini, ki nas bo pripeljal do tega identifikatorja ovojnice . Njen namen je povedati pošiljatelju, ki ustreza e-poštnemu sporočilu, če je morda izdano sporočilo o napaki. Oblika tega ID-ja je v bistvu prepuščena domišljiji pošiljatelja. V našem primeru ne bomo uporabljali ENVID (domišljija!):

POŠILJANJE OD: sender@example.com RET = HDRS
250 sender@example.com ... Pošiljatelj ok

Očitno želimo, da se glave vrnejo nazaj v naš DSN.

Razširitve prejemnikov DSN

RCPT TO: dobi tudi pošten delež razširitev: NOTIFY in ORCPT.

OBVESTILO je resnično srce DSN. Strežniku sporoči, kdaj naj pošlje obvestilo o stanju dostave. Prva možna vrednost je NIKOLI, kar pomeni, da v nobenem primeru DSN ni treba vrniti pošiljatelju. To ni bilo mogoče brez DSN. Potem je na voljo USPEŠNOST, ki vas bo obvestilo, ko bo vaša pošta na cilj. NAPAKA je nasprotna stranka SUCCESS-a (!): DSN bo prišel, če pride do okvare med dostavo. Zadnja možnost je DELAY: vas bo obvestil, če pride do nenavadnega zamika pri dostavi, vendar dejanski rezultat dobave (uspeh ali neuspeh) še ni določen. NIKOLI ne sme biti edini argument, če je naveden, ostala tri se lahko pojavijo na seznamu, ki ga razdeli z vejico. SUCCESS in FAILURE skupaj sestavljata skupino (!), Ki vam pove (skoraj) v vsakem primeru, kaj se je zgodilo z vašo pošto.

Namen ORCPT je, da prevzame prvotni prejemnik e-poštnega sporočila, na primer, če je posredovan na drug naslov. Argument tej možnosti je e-poštni naslov prvotnega prejemnika skupaj z vrsto naslova. Najprej se prikaže naslov naslova, ki mu sledi podpičje in končno naslov. Na primer:

RCPT TO: support@example.com NOTIFY = NAPAK, DELAY ORCPT = rfc822; support@example.com
250 support@example.com ... prejemnik ok (čakalna vrsta)

Temu sledijo podatki, kot jih poznamo, in sčasoma, upajmo, obvestilo o statusu dostave, ki vas o uspehu obvesti.

Ali DSN deluje?

Seveda bo vsa ta lepota in prefinjenost delovala le, če bodo posredniki za pošiljanje pošte od pošiljatelja do prejemnika podpirali DSN. Nekega dne bodo.