DSN: SMTP-e-posti saatmise olekuteade

Uurige, kuidas DSNi eesmärk on SMTP-e-posti saatmisstaatus.

Kunagi mõelnud, mis juhtus teie saadetud e-kirjaga?

Isegi SMTP-protokolli lühikirjelduse abil saate märkida, et lisaks tavapärasele HELO-le on olemas ka EHLO, mis muudab laiendatud SMTP-serveri reklaami oma võimalused, mis jäävad väljapoole esialgset standardit. Üks neist on DSN. DSN? Kas DNA ja DDT pole piisavalt?

Et väita, et e-post on ebausaldusväärne, peaks keegi " ... oma serveri paremaks tooma, see sõitis minu posti ... " ei ole haruldane. Ma teen seda ise. Kuid nende kahtluste toetamiseks pole palju põhjust.

Saatmistehnoloogia on olnud umbes alates RFC 821 (alates 1982. aastast). Niipea, kui SMTP- protokolli DATA osa on lõpetatud ja server on vastu võtnud kättetoimetatava e-kirja, vastutab ta selle eest. Kui mingil põhjusel ei saa see saajale seda läbi saata, peab ta selle saatjale tagasi saatma, teate vea kohta. Selle tulemuseks oli mõni varjatud e-posti aadress .

Lisaks sellele tähendas see vana konventsioon, et kas sul on tõrketeade või et sul pole midagi , mille puhul sa ei teadnud midagi : email võib olla saabunud või mitte. Veateated paljudel juhtudel olid sama kasulikud, kui puudusid veateated. E-posti muutumine üha olulisemaks ei ole see enam rahuldav (nagu varemgi).

DSNi laiendused SMTP-le

RFC 1891 pakub mõningaid SMTP- protokolli laiendeid, mis peaksid tagama usaldusväärsema ja kasutatavama DSN-süsteemi. See on laienduste komplekt MAILi ja RCPT-i käskude jaoks (kui see ei tähenda teile midagi, lugege, kuidas SMTP töötab ja seejärel naase siia).

Ei EHLO, pole lõbus

Esiteks peame tagama, et server toetab DSN-i. Seega peame EHLO talle öelda ja hoolikalt kuulama. Kui see funktsiooni loeb mõnevõrra DSN-i reageerides, võime eeldada, et see suudab meie päringuid teenindada. Kui ei, siis mitte: võime proovida teist serverit või lihtsalt saata e-posti ilma DSN-iga. Näiteks (minu sisend on sinine, serveri väljund must):

220 larose.magnet.at ESMTP Sendmail 8.8.6 / 8.8.6; P 24.09.1998 18:23:22 +0200
EHLO kohalik hobune
250-larose.magnet.at Tere, localhost [127.0.0.1], hea meel teile kohtuda
250-EXPN
250-VERB
250-8BITMIME
250-suurune
250-DSN
250-ONEX
250-ETRN
250-XUSR
250 HELP

Õnneks leiame muu hulgas DSN.

DSN-saatja laiendused

Järgmine käsk on tavaliselt POST FROM :. DSN-iga pole see erinev. Kuid teil on kaks täiendavat võimalust: RET ja ENVID.

RET-valik suleti meelevaldselt MAIL-i käsule, kuid see sobib nii siin kui ka kuskil mujal. Eesmärk on täpsustada, kui palju teie esialgset sõnumit tuleks saatmise ebaõnnestumise korral tagastada. Kehtivad argumendid on FULL ja HDRS. Esimene tähendab, et veateade peab sisaldama täielikku sõnumit, HDRS-i juhendab serverit tagastama ainult ebaõnnestunud kirja päised. Kui RET ei ole täpsustatud, on serveri ülesanne, mida teha. Enamasti on HDRS vaikimisi väärtus.

ENVID kuulub tõepoolest saatjale, kuna tema (või pigem) tema e-posti klient on ainus, mis muudab meid selle ümbriku identifikaatoriks . Selle eesmärk on öelda saatjale, milline e-posti aadress vastab tõenäoliselt välja antud veateatele. Selle ID vorming puudutab põhimõtteliselt saatja kujutlust. Me ei kasuta ENVIDi meie näites (kujutlusvõime!):

MAIL FROM: sender@example.com RET = HDRS
250 sender@example.com ... saatja ok

Tundub, et me tahame alles päiste tagasi meie DSN-is.

DSN-i saaja laiendid

RCPT TO: saab ka õiglast laiendusi: NOTIFY ja ORCPT.

TEATAKSE on DSNi tõeline süda. See ütleb serverile, kui saata tarneoleku märguanne. Esimene võimalik väärtus ei ole NÕUE, mis tähendab, et mingil juhul ei tohi DSN saatjale tagastada. See ei olnud DSN-i korral võimalik. Siis on SUCCESS, mis teavitab teid, kui teie postitus on teie sihtkohta saadetud. RIKKIMINE on SUCCESSi vastane (!): DSN saabub, kui tarnimise ajal tekkis viga. Viimane võimalus on DELAY: teid teavitatakse, kui kohaletoimetamise ajal on ebatavaline viivitus, kuid tegeliku kohaletoimetamise tulemust (edu või ebaedu) pole veel otsustanud. Kui see on täpsustatud, ei tohi see kunagi olla ainsaks, ülejäänud kolm võivad ilmuda loendis, mis on komaga piiratud. EDU ja FAILURE moodustavad üsna tugeva meeskonna koos (!), Mis ütleb sulle (peaaegu) igal juhul, mis teie kirjaga juhtus.

ORCPT-i eesmärk on säilitada e-kirja esialgne saaja, näiteks kui see edastatakse teisele aadressile. Selle variandi argumendiks on algse saaja e-posti aadress koos aadressi tüübiga. Esmalt tuleb aadressi tüüp, millele järgneb semikoolon ja lõpuks aadress. Näiteks:

RCPT TO: support@example.com NOTIFY = FAILURE, DELAY ORCPT = rfc822; support@example.com
250 support@example.com ... Saaja okei (järjekorras)

Sellele järgneb DATA, nagu me seda teame, ja lõpuks, loodetavasti edastus oleku teade, mis teavitab teid edukalt.

Kas DSN töötab?

Muidugi, kõik see ilu ja vaim töötab ainult siis, kui postitranspordivahendid saatjalt adressaadile toetavad DSN-i. Mõni päev nad saavad.