Vind uit hoe DSN daarop gemik was om leweringstatus aan SMTP-e-pos in te voer.
Al ooit gewonder wat gebeur het met 'n e-pos wat jy gestuur het?
Selfs net 'n kort oorsig van die SMTP-protokol sal u sien dat behalwe die gewone HELO, daar ook EHLO is, wat die Uitgebreide SMTP-bediener adverteer om sy vermoëns te verby die oorspronklike standaard. Een hiervan is DSN. DSN? Is DNA en DDT nie genoeg nie?
Om te argumenteer dat die e-pos onbetroubaar is, moet iemand " ... hul bediener beter voed, dit het my pos geëet ... " nie ongewoon nie. Ek doen dit self. Tog, daar is nie veel rede om hierdie vermoedens te ondersteun nie.
Delivery S tatus N otification is al sedert RFC 821 (vanaf 1982). Sodra die DATA-deel van die SMTP- protokol klaar is en die bediener die e-pos vir aflewering aanvaar het, is dit verantwoordelik. As dit om die een of ander rede nie deur die ontvanger kan word nie, moet dit terug gestuur word met kennisgewing van die fout aan die oorspronklike sender. Dit het gelei tot 'n paar duidelike e-pos .
Daarbenewens het hierdie ou konvensie beteken dat jy óf 'n foutboodskap gehad het óf jy het niks gehad nie. In daardie geval het jy niks geweet nie : die e-pos het dalk aangebreek of dit mag nie. Die foutboodskappe was in baie gevalle net so behulpsaam as geen foutboodskappe nie. As e-pos meer en meer belangrik word, is dit nie meer bevredigend nie (asof dit voorheen was).
DSN uitbreidings na SMTP
RFC 1891 bied 'n paar uitbreidings aan die SMTP- protokol wat tot 'n betroubare en meer bruikbare DSN-stelsel behoort te lei. Dit is 'n stel uitbreidings aan die MAIL- en RCPT-opdragte (as dit vir jou niks beteken nie, lees hoe SMTP werk en kom dan hier terug.).
Geen EHLO, Geen Pret
Eerstens moet ons seker maak dat die bediener DSN ondersteun. Dus, ons moet EHLO vir hom sê en luister aandagtig. As dit reageer met DSN iewers in die funksie lys, kan ons aanvaar dat dit ons versoeke kan dien. Indien nie, dan nie: ons kan 'n ander bediener probeer of eenvoudig terugval om te e-pos sonder DSN. Byvoorbeeld (my invoer is blou, die bediener se uitset swart):
220 larose.magnet.at ESMTP Send Mail 8.8.6 / 8.8.6; So, 24 Aug 1997 18:23:22 +0200
EHLO localhost
250-larose.magnet.at Hallo localhost [127.0.0.1], is bly om jou te ontmoet
250-EXPN
250-WERKWOORD
250-8BITMIME
250-SIZE
250-DSN
250-Onex
250-ETRN
250-XUSR
250 HULP
Gelukkig vind ons onder meer DSN.
DSN Sender Uitbreidings
Die volgende opdrag is tipies MAIL FROM :. Met DSN is dit nie anders nie. Maar daar is nog twee opsies wat jy mag uitreik: RET en ENVID.
Die RET-opsie is eerder arbitrêr in die MAIL-opdrag geplaas, maar dit pas hier sowel as dit nêrens anders nie. Die doel is om te spesifiseer hoeveel u oorspronklike boodskap teruggestuur moet word in die geval van 'n afleweringsfout. Geldige argumente is VOL en HDRS. Die voormalige beteken dat die volledige boodskap in die foutboodskap ingesluit moet word. HDRS gee opdrag aan die bediener om slegs die koptekste van die mislukte pos terug te gee. As RET nie gespesifiseer word nie, is dit aan die bediener wat om te doen. In die meeste gevalle sal HDRS die verstekwaarde wees.
ENVID behoort regtig aan die sender omdat sy of haar e-pos kliënt die enigste een is wat ons van hierdie koevert identifiseerder maak . Die doel is om die sender te vertel watter e-pos 'n moontlik gemaakte foutboodskap ooreenstem. Die formaat van hierdie ID word basies aan die verbeelding van die sender oorgelaat. Ons sal nie ENVID gebruik in ons voorbeeld (verbeelding!):
POS VANAF: sender@example.com RET = HDRS
250 sender@example.com ... Sender ok
Klaarblyklik wil ons net die opskrifte terug in ons DSN kry.
DSN Ontvanger Uitbreidings
Die RCPT TO: kry ook sy billike deel van uitbreidings: NOTIFY and ORCPT.
NOTIFY is die ware hart van DSN. Dit vertel die bediener wanneer 'n leweringstatus kennisgewing moet gestuur word. Die eerste moontlike waarde is GEEN wat beteken dat 'n DSN onder geen omstandighede aan die sender terugbesorg moet word nie. Dit was nie moontlik sonder DSN nie. Dan is daar SUCCESS, wat jou sal in kennis stel as jou pos op sy bestemming gegraveer word. FOUT is SUCCESS se eweknie (!): 'N DSN sal aankom as daar tydens die aflewering opgetree het. Die laaste opsie is DELAY: u sal in kennis gestel word indien daar 'n ongewone vertraging in aflewering is, maar die uitkoms van die werklike aflewering (sukses of mislukking) is nog nie bepaal nie. Moet nooit die enigste argument wees as dit gespesifiseer word nie. Die ander drie mag in 'n lys verskyn, geskei deur 'n komma. SUCCESS and FAILURE maak saam vir 'n mooi sterk span (!), En vertel jou (byna) enige geval wat met jou pos gebeur het.
Die doel van ORCPT is om die oorspronklike ontvanger van 'n e-posboodskap te behou, byvoorbeeld as dit na 'n ander adres gestuur word. Die argument vir hierdie opsie is die e-posadres van die oorspronklike ontvanger tesame met die adres tipe. Die adres tipe kom eerste, gevolg deur 'n semikolon en uiteindelik die adres. Byvoorbeeld:
RCPT AAN: support@example.com NOTIFY = FOUT, DELAY ORCPT = rfc822; support@example.com
250 support@example.com ... Ontvanger ok (sal wag)
Dit word gevolg deur die DATA soos ons dit ken en uiteindelik, hopelik, 'n afleweringsstatuskennisgewing wat u van 'n sukses in kennis stel.
Werk DSN?
Natuurlik sal al hierdie skoonheid en wit werk net as die posvervoeragente van sender na ontvanger DSN ondersteun. Somtyds sal hulle.