Aflați cum DSN vizează introducerea statutului de livrare în e-mail SMTP.
V-ați întrebat vreodată ce sa întâmplat cu un e-mail pe care l-ați trimis?
Chiar și o scurtă privire la protocolul SMTP vă va da seama că, în afară de HELO obișnuit, există și EHLO, ceea ce face ca serverul SMTP extins să își facă publice capabilitățile dincolo de standardul original. Unul dintre acestea este DSN. DSN? Nu sunt ADN și DDT suficiente?
Pentru a susține că e-mailul este nesigur, că cineva ar trebui "să-și hrănească serverul mai bine, mi-a mâncat poșta ... " nu este neobișnuit. Fac eu însumi. Totuși, nu există prea multe motive pentru a susține aceste suspiciuni.
S tatusul de livrare N otificarea a fost în jur de la RFC 821 (din 1982). De îndată ce partea DATA a protocolului SMTP este terminată și serverul a acceptat e-mailul pentru livrare, este responsabil pentru aceasta. Dacă, din orice motiv, nu poate să o primească către destinatar, trebuie să o trimită înapoi cu notificarea erorii către expeditorul original. Acest lucru a dus la unele e-mailuri obscure.
În afară de aceasta, această convenție veche înseamnă că fie că ai primit un mesaj de eroare, fie că nu ai nimic, caz în care nu știai nimic : e-mailul ar fi putut sosi sau nu. Mesajele de eroare în multe cazuri au fost la fel de utile ca și mesajele de eroare. Cu e-mail-ul devine din ce în ce mai important, acest lucru nu mai este satisfăcător (ca și cum înainte).
DSN Extensii la SMTP
RFC 1891 propune câteva extensii la protocolul SMTP care ar trebui să aibă ca rezultat un sistem DSN mai fiabil și mai ușor de utilizat. Este un set de extensii la comenzile MAIL și RCPT (dacă acest lucru nu înseamnă nimic pentru dvs., citiți cum funcționează SMTP și apoi reveniți aici).
Nu EHLO, nu amuzant
În primul rând, trebuie să ne asigurăm că serverul acceptă DSN. Astfel, trebuie să-i spunem lui EHLO și să ascultăm cu atenție. Dacă răspunde cu DSN într-o anumită listă de funcții, putem presupune că va fi capabil să răspundă solicitărilor noastre. Dacă nu, atunci nu: putem încerca un alt server sau pur și simplu să ne întoarcem la e-mail fără DSN. De exemplu (intrarea mea fiind albastră, ieșirea serverului negru):
220 larose.magnet.at ESMTP Sendmail 8.8.6 / 8.8.6; Dum, 24 Aug 1997 18:23:22 +0200
EHLO localhost
250-larose.magnet.at Bună ziua localhost [127.0.0.1], cu plăcere să te cunosc
250-EXPN
250-VERB
250-8BITMIME
250 SIZE
250-DSN
250-ONEX
250-ETRN
250-XUSR
250 AJUTOR
Din fericire, printre altele, găsim DSN.
Extensiile expeditorilor DSN
Următoarea comandă este, de obicei, MAIL FROM :. Cu DSN, acest lucru nu este diferit. Dar există două opțiuni suplimentare pe care le puteți emite: RET și ENVID.
Opțiunea RET a fost pusă în mod arbitrar în comanda MAIL, dar se potrivește aici, precum și oriunde altundeva. Scopul este de a specifica cât de mult din mesajul inițial ar trebui să fie returnat în caz de eșec de livrare. Argumentele valide sunt FULL și HDRS. Primul înseamnă că mesajul complet trebuie inclus în mesajul de eroare, HDRS instruiește serverul să returneze doar anteturile e-mailului eșuat. Dacă RET nu este specificat, depinde de server ce să facă. În cele mai multe cazuri, HDRS va fi valoarea implicită.
ENVID aparține într-adevăr expeditorului, deoarece ea sau (mai degrabă) clientul său de e-mail va fi singurul care ne face să identificăm acest plic . Scopul său este de a comunica expeditorului care e-mail un mesaj de eroare care ar putea să apară. Formatul acestui ID este, în esență, lăsat la imaginația expeditorului. Nu vom folosi ENVID în exemplul nostru (imaginație!):
MAIL FROM: sender@example.com RET = HDRS
250 sender@example.com ... Expeditor ok
Se pare că nu vrem decât să scoatem antetele în DSN.
Extensiile destinatarilor DSN
RCPT TO: își asumă și o parte echitabilă de extensii: NOTIFY și ORCPT.
NOTIFICARE este adevărata inimă a DSN. Acesta îi spune serverului când trebuie să trimită o notificare privind starea livrării. Prima valoare posibilă NICIODATĂ nu înseamnă că, în nici un caz, un DSN nu trebuie returnat expeditorului. Acest lucru nu a fost posibil fără DSN. Apoi, există SUCCES, care vă va anunța atunci când e-mailul dvs. este îndeplinit la destinație. FAILURE este contrapartida SUCCESS (!): Un DSN va sosi daca un arror a aparut in timpul livrarii. Ultima opțiune este DELAY: veți fi anunțat (ă) dacă există o întârziere neobișnuită în livrare, dar rezultatul real al livrării (succes sau eșec) nu este încă decis. NICIODATĂ trebuie să fie singurul argument în cazul în care acesta este specificat, celelalte trei pot apărea într-o listă, delimitată de o virgulă. SUCCESUL și Eșecul fac o echipă destul de puternică împreună (!), Spunându-vă în (aproape) orice caz ce sa întâmplat cu poșta ta.
Scopul ORCPT este de a păstra destinatarul inițial al unui mesaj de e-mail, de exemplu dacă este redirecționat către o altă adresă. Argumentul pentru această opțiune este adresa de e-mail a destinatarului inițial, împreună cu tipul de adresă. Primul tip de adresă este primul, urmat de punct și virgulă și, în final, adresa. De exemplu:
RCPT LA: support@example.com NOTIFY = FAILURE, DELAY ORCPT = rfc822; support@example.com
250 support@example.com ... Destinatar ok (va coada)
Acest lucru este urmat de DATA după cum îl cunoaștem și, eventual, sperăm, o notificare privind starea livrării care vă anunță un succes.
Functioneaza DSN?
Desigur, toată această frumusețe și inteligență vor funcționa numai dacă agenții de transport de mail de la expeditor la destinatar acceptă DSN. Într-o zi o vor face.