Chiar și o scurtă privire la protocolul SMTP vă va face să observați că pe lângă HELO obișnuit, există și EHLO, ceea ce face ca Extins Serverul SMTP își face 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 " … hrănesc serverul lor mai bine; mi-a mâncat poșta … "nu este ceva neobișnuit, dar nu există prea multe motive pentru a susține aceste suspiciuni.
Livrare S Tatus N otificare a fost în jurul valorii de 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 ajunge la destinatar, trebuie să-l 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ă ai primit-o nimic caz în care ați știut nimic : este posibil ca e-mailul să fi sosit 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.
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 undeva în lista de caracteristici, putem presupune că va putea să ne satisfacă cererile. Dacă nu, atunci nu: putem încerca un alt server sau pur și simplu să ne întoarcem la e-mail fără DSN. De exemplu:
220 larose.magnet.at ESMTP Sendmail 8.8.6 / 8.8.6; Dum, 24 Aug 1997 18:23:22 +0200EHLO localhost250-larose.magnet.at Bună ziua localhost 127.0.0.1, cu plăcere să te cunosc250-EXPN250-VERB250-8BITMIME250 SIZE250-DSN250-ONEX250-ETRN250-XUSR250 AJUTOR Din fericire, printre altele, găsim 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 folosește acest lucru identificator 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: MAIL FROM: [email protected] RET = HDRS250 [email protected] … Expeditor ok Se pare că nu vrem decât să scoatem antetele în DSN. RCPT TO: își asumă și o parte echitabilă de extensii: NOTIFY și ORCPT. NOTIFICARE este adevărata inimă a DSN. Se spune serverului cand pentru a trimite 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 când e-mailul dvs. a ajuns la destinație. FAILURE este contrapartea SUCCESS: un DSN va sosi dacă a apărut o eroare în timpul livrării. 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. NU trebuie sa fi singurul argument în cazul în care a specificat, celelalte trei pot apărea într-o listă, delimitată de o virgulă. SUCCESUL și neajunsul 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 original destinatar 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: [email protected] NOTIFY = FAILURE, DELAY ORCPT = rfc822; [email protected]250 [email protected] … 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. Desigur, toată această frumusețe și va funcționa numai dacă agenții de transport de mail de la expeditor la destinatar acceptă DSN. Într-o zi o vor face. Extensiile expeditorilor DSN
Extensiile destinatarilor DSN
Functioneaza DSN?
