Tudi kratek pregled protokola SMTP boste opazili, da poleg običajnega HELO obstaja tudi EHLO, zaradi česar je Razširjeno 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 " … hranijo svoje strežnike bolje; je pojedel mojo pošto … "ni neobičajno. Vendar ni veliko razlogov za podporo tem sumom.
Dostava S tatus N od leta 2002 je 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 ga iz kakršnega 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 imate nič v tem primeru ste vedeli nič : e-poštno sporočilo je morda prišlo 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.
Ne EHLO, ne zabava
Najprej moramo zagotoviti, da strežnik podpira DSN. Zato mu moramo reči EHLO in pozorno poslušati. Če se z DSN-om odzove nekje na seznamu funkcij, 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:
220 larose.magnet.at ESMTP Sendmail 8.8.6 / 8.8.6; Ned, 24 Avg 1997 18:23:22 +0200EHLO localhost250-larose.magnet.at Pozdravljeni lokalni gost 127.0.0.1, veseli me, da smo se spoznali250-EXPN250-VERB250-8BITMIME250-SIZE250-DSN250-ONEX250-ETRN250-XUSR250 POMOČ Na srečo, med drugim najdemo 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 (pre) njen e-poštni odjemalec edini, ki to izkorišča identifikator 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: POŠILJANJE OD: [email protected] RET = HDRS250 [email protected] … Pošiljatelj ok Očitno želimo, da se glave vrnejo nazaj v naš DSN. RCPT TO: dobi tudi pošten delež razširitev: NOTIFY in ORCPT. OBVESTILO je resnično srce DSN. To pove strežniku kdaj da pošljete 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 SUCCESS, ki vas bo obvestil, ko bo vaša pošta prispela na cilj. NAPAKA je nasprotna stran SUCCESS-a: DSN bo prišel, če bi med dostavo prišlo do napake. 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 moraš je edini argument, če je naveden, ostala tri se lahko pojavijo na seznamu, ki ga razdeli z vejico. SUCCESS in FAILURE skupaj sestavljata zelo močno ekipo, ki vam pove (skoraj) v vsakem primeru, kaj se je zgodilo z vašo pošto. Namen ORCPT je ohraniti original prejemnika 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: [email protected] NOTIFY = NAPAK, DELAY ORCPT = rfc822; [email protected]250 [email protected] … prejemnik ok (čakalna vrsta) Temu sledijo podatki, kot jih poznamo, in sčasoma, upajmo, obvestilo o statusu dostave, ki vas o uspehu obvesti. Seveda bo vsa ta lepota delovala le, če bodo posredniki za pošiljanje pošte od pošiljatelja do prejemnika podpirali DSN. Nekega dne bodo. Razširitve pošiljateljev DSN
Razširitve prejemnikov DSN
Ali DSN deluje?
