Esbrineu com DSN volia introduir l'estat de lliurament a l'adreça electrònica SMTP.
Alguna vegada va preguntar què va passar a un correu electrònic que vau enviar?
Fins i tot simplement un breu cop d'ull al protocol SMTP , us adonareu que, a més de l'HELO habitual, també hi ha EHLO, que fa que el servidor SMTP estès publiqui les seves capacitats més enllà de l'estàndard original. Un d'aquests és DSN. DSN? No són prou ADN i DDT?
Per argumentar que el correu electrònic no és fiable, que algú hauria de " ... alimentar millor el seu servidor, es va menjar el meu correu ... " no és estrany. Ho faig jo mateix. No obstant això, no hi ha moltes raons per recolzar aquestes sospites.
Lliurament de certificats ha estat al voltant des de RFC 821 (des de 1982). Tan aviat com s'hagi acabat la part de DATA del protocol SMTP i el servidor ha acceptat el correu electrònic per al lliurament, és responsable d'això. Si, per qualsevol motiu, no pot accedir al destinatari, haureu d'enviar-lo de nou amb la notificació de l'error al remitent original. Això va resultar en un correu electrònic obscur.
A part d'això, aquesta antiga convenció va significar que ja teníeu un missatge d' error o no teníeu res, en aquest cas no sabeu res : el correu electrònic pot haver arribat o no. Els missatges d'error en molts casos van ser tan útils com cap missatge d'error. Amb el correu electrònic cada vegada més important, això ja no és satisfactori (com abans).
Extensions DSN a SMTP
RFC 1891 proposa algunes extensions al protocol SMTP que haurien de resultar en un sistema DSN més confiable i més usable. Es tracta d'un conjunt d'extensions als comandaments MAIL i RCPT (si això no significa res per a vostè, llegiu com funciona SMTP i torna aquí).
No EHLO, No hi ha diversió
En primer lloc, hem d'assegurar-nos que el servidor admeti DSN. Per tant, hem de dir-li a EHLO i escoltar atentament. Si respon amb DSN en la llista de característiques, podem suposar que podrem atendre les nostres peticions. De lo contrario, no: podem provar un altre servidor o simplement tornar a enviar un correu electrònic sense DSN. Per exemple (la meva entrada és blau, la sortida del servidor negre):
220 larose.magnet.at Sendmail 8.8.6 / 8.8.6 ESMTP; Diumenge, 24 d'agost de 1997 18:23:22 +0200
EHLO localhost
250-larose.magnet.at Hola localhost [127.0.0.1], satisfet de conèixer-te
250-EXPN
250-VERB
250-8BITMIME
TALLA de 250
250-DSN
250-ONEX
250-ETRN
250-XUSR
250 AJUDA
Afortunadament, entre altres coses, trobem DSN.
Extensions de remitents de DSN
La propera ordre normalment és MAIL FROM :. Amb DSN, això no és diferent. Però hi ha dues opcions addicionals que podeu emetre: RET and ENVID.
L'opció RET es va col·locar de forma arbitrària a l'ordre MAIL, però encaixa aquí, així com en qualsevol altre lloc. El propòsit és especificar quina quantitat del vostre missatge original s'hauria de retornar en cas d'error de lliurament. Els arguments vàlids són FULL i HDRS. El primer significa que el missatge complet s'ha d'incloure en el missatge d'error; HDRS indica al servidor que només retorni els encapçalaments del correu fallit. Si no s'especifica RET, és responsabilitat del servidor què fer. En la majoria dels casos HDRS serà el valor predeterminat.
ENVID pertany realment al remitent ja que ella o (més aviat) el seu client de correu electrònic serà l'únic que ens fa d'aquest identificador de sobre . El seu propòsit és informar-li al remitent que correspon a un missatge d'error enviat possiblement per correu electrònic. El format d'aquesta ID es deu bàsicament a la imaginació del remitent. No utilitzarem ENVID en el nostre exemple (imaginació!):
CORREU DE: sender@example.com RET = HDRS
250 sender@example.com ... Sender ok
Pel que sembla, només volem que les capçaleres tornin al nostre DSN.
Extensions de destinataris DSN
El RCPT TO: també rep la seva part justa d'extensions: NOTIFY i ORCPT.
NOTIFICAR és el veritable cor de DSN. Explica al servidor quan enviar una notificació d'estat de lliurament. El primer valor possible mai és NEVER el que significa que en cap cas un DSN s'ha de tornar al remitent. Això no va ser possible sense DSN. A continuació, hi ha ÈXIT, que us avisarà quan el vostre correu es trobi a la vostra destinació. FALLER és la contrapart de SUCCESS (!): Un DSN arribarà si es produeix un error durant el lliurament. L'última opció és DELAY: se us notificarà si hi ha un retard inusual en el lliurament, però el resultat real de l'enviament (èxit o fracàs) encara no s'ha decidit. NOMÉS ha de ser l'únic argument si s'especifica, els altres tres poden aparèixer en una llista, delimitada per una coma. SUCCESS i FAILURE componen un equip força fort (!), Que us indica (gairebé) qualsevol cas del que ha passat al vostre correu.
El propòsit de l'ORCPT és preservar el destinatari original d'un missatge de correu electrònic, per exemple, si es transmet a una altra adreça. L'argument d'aquesta opció és l'adreça de correu electrònic del destinatari original juntament amb el tipus d'adreça. El tipus d'adreça apareix primer, seguit d'un punt i coma i finalment l'adreça. Per exemple:
RCPT A: support@example.com NOTIFICAR = FALLER, RETARDAR ORCPT = rfc822; support@example.com
250 support@example.com ... Receptor ok (farà cua)
A continuació, seguiu els DADES tal com la coneixem i, amb esperança, una notificació d'estat de lliurament que us informa d'un èxit.
Funciona DSN?
Per descomptat, tota aquesta bellesa i enginy només funcionarà si els agents de transport de correu del remitent al suport del destinatari DSN. Alguns dia ho faran.