Darganfyddwch sut roedd DSN yn anelu at gyflwyno statws cyflwyno i e-bost SMTP.
Ydych chi erioed wedi ystyried beth ddigwyddodd i e-bost a anfonwyd gennych?
Hyd yn oed dim ond edrychiad byr ar y protocol SMTP a wnewch chi sylwi, ar wahân i'r HELO arferol, mae EHLO hefyd, sy'n golygu bod y gweinydd SMTP Estynedig yn hysbysebu ei alluoedd y tu hwnt i'r safon wreiddiol. Un o'r rhain yw DSN. DSN? A yw DNA a DDT ddim yn ddigon?
I ddadlau bod yr e-bost yn annibynadwy, y dylai rhywun " ... fwydo eu gweinydd yn well; mae'n bwyta fy post ... " yn anghyffredin. Rwy'n gwneud hynny fy hun. Eto i gyd, nid oes llawer o reswm dros gefnogi'r amheuon hyn.
Cyflawniad Tatus N mae'r otodiad wedi bod o gwmpas ers RFC 821 (o 1982). Cyn gynted â bod rhan DATA y protocol SMTP wedi'i orffen ac mae'r gweinydd wedi derbyn yr e-bost i'w gyflwyno, mae'n gyfrifol amdano. Os, am unrhyw reswm, na all ei gyrraedd i'r derbynnydd rhaid iddo ei hanfon yn ôl gyda hysbysiad o'r gwall i'r anfonwr gwreiddiol. Arweiniodd hyn at e-bost aneglur.
Ar wahân i hynny, roedd yr hen gonfensiwn hon yn golygu bod naill ai gennych neges gwall neu os na wnaethoch ddim dim, ac os nad oeddech chi'n gwybod dim : efallai y bydd yr e-bost wedi cyrraedd neu efallai na fydd. Roedd y negeseuon gwall mewn sawl achos yr un mor ddefnyddiol ag unrhyw negeseuon gwall. Gyda e-bost yn dod yn fwy a mwy pwysig, nid yw hyn yn foddhaol bellach (fel pe bai o'r blaen).
Estyniadau DSN i SMTP
Mae RFC 1891 yn cynnig rhai estyniadau i'r protocol SMTP a ddylai arwain at system DSN fwy dibynadwy a mwy defnyddiadwy. Mae'n set o estyniadau i'r gorchmynion MAIL a RCPT (os yw hyn yn golygu dim i chi, darllenwch sut mae SMTP yn gweithio ac yna'n dychwelyd yma.).
Dim EHLO, Dim Hwyl
Yn gyntaf, rhaid inni sicrhau bod y gweinydd yn cefnogi DSN. Felly, mae'n rhaid inni ddweud EHLO iddo a gwrando'n ofalus. Os yw'n ymateb gyda rhywfaint DSN yn y rhestr nodweddion, gallwn dybio y bydd yn gallu gwasanaethu ein ceisiadau. Os na, yna nid: gallwn ni roi cynnig ar weinyddwr arall neu ddim ond yn syrthio'n ôl i e-bost heb DSN. Er enghraifft (fy nghyfraniad yn las, allbwn y gweinydd du):
220 larose.magnet.at ESMTP Sendmail 8.8.6 / 8.8.6; Dydd Sul, 24 Awst 1997 18:23:22 +0200
EHLO localhost
250-larose.magnet.at Helo localhost [127.0.0.1], yn falch o'ch cyfarfod
250-EXPN
250-VERB
250-8 BITMIME
250-MAINT
250-DSN
250-ONEX
250-ETRN
250-XUSR
250 HELP
Yn ffodus, ymhlith pethau eraill, rydym yn dod o hyd i DSN.
Estyniadau Estynwr DSN
Mae'r gorchymyn nesaf fel arfer yn BOST ODDI :. Gyda DSN, nid yw hyn yn wahanol. Ond mae dau opsiwn ychwanegol y gallech eu cyhoeddi: RET a ENVID.
Roedd yr opsiwn RET yn hytrach yn cael ei osod yn anghyffredin yn y gorchymyn MAIL, ond mae'n cyd-fynd yma yn ogystal ag y byddai'n unrhyw le arall. Y pwrpas yw nodi faint o'ch neges wreiddiol ddylai gael ei ddychwelyd rhag ofn methiant cyflwyno. Mae dadleuon dilys yn LLAWN a HDRS. Mae'r cyntaf yn golygu y dylid cynnwys y neges gyflawn yn y neges gwall, mae HDRS yn cyfarwyddo'r gweinydd i ddychwelyd penawdau'r post a fethwyd yn unig. Os nad yw RET wedi'i phenodi, mae'n rhaid i'r gweinydd wneud yr hyn i'w wneud. Yn y rhan fwyaf o achosion, HDRS fydd y gwerth diofyn.
Mae ENVID mewn gwirionedd yn perthyn i'r anfonwr gan ei bod hi (neu yn hytrach) ei chleient e-bost fydd yr unig un sy'n ein gwneud ni o'r dynodwr amlen hwn. Ei bwrpas yw dweud wrth yr anfonwr sy'n anfon neges e-bost at neges gwall a gyhoeddwyd o bosibl. Yn y bôn, mae fformat yr ID hwn yn cael ei adael i ddychymyg yr anfonwr. Ni fyddwn yn defnyddio ENVID yn ein hesiampl (dychymyg!):
BOST ODDI: sender@example.com RET = HDRS
250 sender@example.com ... Yr anfonwr yn iawn
Mae'n debyg, yr ydym am gael y penawdau yn ôl yn ein DSN yn unig.
Estyniadau Derbynwyr DSN
Mae'r RCPT TO: yn cael ei gyfran deg o estyniadau hefyd: NODWCH a ORCPT.
NODWCH yw calon go iawn DSN. Mae'n dweud wrth y gweinydd pryd i anfon hysbysiad statws cyflenwi. Y gwerth posibl cyntaf yw BYDD sy'n golygu na ddylai DSN gael ei ddychwelyd i'r anfonwr dan unrhyw amgylchiadau. Nid oedd hyn yn bosibl heb DSN. Yna mae LLWYDDIANT, a fydd yn eich hysbysu pan fydd eich post wedi'i groenio yn ei gyrchfan. CYFRWYDDOG LLWYDDIANT LLWYDDIANT (!): Bydd DSN yn cyrraedd pe bai arbryn yn digwydd yn ystod ei gyflwyno. Yr opsiwn olaf yw DELAY: byddwch yn cael gwybod os oes oedi anarferol wrth gyflwyno, ond nid yw canlyniad y cyflwyniad (llwyddiant neu fethiant) yn cael ei benderfynu eto. Dylech BEIDIO fod yr unig ddadl pe bai wedi'i bennu, mae'n bosib y bydd y tri arall yn ymddangos mewn rhestr, wedi'i ddileu gan goma. Mae LLWYDDIANT a LLYFODU yn ffurfio tīm eithaf cryf gyda'i gilydd (!), Gan ddweud wrthych mewn (bron) unrhyw achos a ddigwyddodd i'ch post.
Pwrpas ORCPT yw cynorthwyo neges derfynol neges e-bost, er enghraifft os caiff ei anfon ymlaen at gyfeiriad arall. Y ddadl i'r opsiwn hwn yw cyfeiriad e-bost y derbynnydd gwreiddiol ynghyd â'r math o gyfeiriad. Daw'r math o gyfeiriad yn gyntaf, ac yna un pen-dōn ac yn olaf y cyfeiriad. Er enghraifft:
RCPT TO: support@example.com NOTIFY = FAILURE, DELAY ORCPT = rfc822; support@example.com
250 support@example.com ... Derbynnydd yn iawn (bydd ciw)
Dilynir hyn gan y DATA fel y gwyddom ni ac yn y pen draw, gobeithio, hysbysiad statws cyflwyno sy'n rhoi gwybod i chi am lwyddiant.
A yw DSN yn gweithio?
Wrth gwrs, dim ond os bydd yr asiantau trafnidiaeth post o'r anfonwr i'r gefnogaeth derbynnydd DSN yn gweithio ar yr holl harddwch a wit. Rhyw ddiwrnod y byddant.