Gjeni se si DSN kishte për qëllim të futë statusin e dërgimit në emailin SMTP.
Ever Wondered Çfarë ndodhi me një email ju dërgoi?
Edhe vetëm një vështrim i shkurtër në protokollin SMTP do të keni vërejtur se përveç HELO-s të zakonshëm, ekziston edhe EHLO, që e bën serverin e zgjeruar SMTP të reklamojë aftësitë e tij përtej standardit origjinal. Një nga këto është DSN. DSN? A nuk mjafton ADN-ja dhe DDT-ja?
Për të argumentuar se e-mail nuk është i besueshëm, dikush duhet të " ... ushqyer serverin e tyre më të mirë, hëngri postën time ... " nuk është e pazakontë. Unë bëj atë vetë. Megjithatë, nuk ka shumë arsye për të mbështetur këto dyshime.
Dorëzimi i S tatus N otification ka qenë rreth e rrotull që nga RFC 821 (nga viti 1982). Sapo të përfundojë pjesa e DATA e protokollit SMTP dhe serveri e ka pranuar postën për dërgim, është përgjegjës për të. Nëse, për ndonjë arsye, ajo nuk mund ta marrë atë tek marrësi, duhet ta dërgojë atë me njoftimin e gabimit tek dërguesi origjinal. Kjo rezultoi në disa email të panjohur.
Përveç kësaj, kjo konventë e vjetër do të thotë që ose keni një mesazh gabimi ose nuk keni asgjë në të cilin rast nuk dinit asgjë : emaili mund të ketë ardhur ose mund të mos jetë. Mesazhet e gabimit në shumë raste ishin po aq të dobishme sa nuk kishte mesazhe gabimi. Me postë elektronike bëhet gjithnjë e më e rëndësishme kjo nuk është më e kënaqshme (sikur të ishte më parë).
Extensions DSN te SMTP
RFC 1891 propozon disa zgjatje të protokollit SMTP që duhet të rezultojë në një sistem DSN më të besueshëm dhe më të përdorshëm. Është një grup zgjerimi i komandave MAIL dhe RCPT (nëse kjo nuk do të thotë asgjë për ju, lexoni se si punon SMTP dhe pastaj kthehet këtu.).
Asnjë EHLO, Jo Fun
Së pari, duhet të sigurohemi që serveri të mbështetë DSN-në. Kështu, duhet t'i themi EHLO atij dhe të dëgjojmë me kujdes. Nëse përgjigjet me DSN-në në listën e veçorive, ne mund të supozojmë se do të jetë në gjendje t'u shërbejë kërkesave tona. Nëse jo, atëherë jo: mund të provojmë një server tjetër ose thjesht të bien në email pa DSN. Për shembull (hyrja ime është blu, rezultati i serverit është i zi):
220 larose.magnet.at ESMTP Sendmail 8.8.6 / 8.8.6; Sun, 24 Aug 1997 18:23:22 +0200
EHLO localhost
250-larose.magnet.at Përshëndetni localhost [127.0.0.1], i kënaqur që u njohëm
250-EXPN
250-VERB
250-8BITMIME
250-SIZE
250-DSN
250-ONEX
250-ETRN
250-XUSR
250 HELP
Për fat të mirë, ndër të tjera gjejmë DSN.
Zgjerimet e dërguesit të DSN-së
Komanda tjetër zakonisht është MAIL FROM :. Me DSN, kjo nuk është ndryshe. Por ka dy mundësi shtesë që mund të lëshoni: RET and ENVID.
Opsioni RET u vendos në mënyrë arbitrare në komandën MAIL, por kjo përshtatet këtu, ashtu si do të ishte kudo tjetër. Qëllimi është të specifikoni se sa nga mesazhi juaj origjinal duhet të kthehet në rast të dështimit të dërgimit. Argumentet e vlefshme janë FULL dhe HDRS. E para do të thotë se mesazhi i plotë duhet të përfshihet në mesazhin e gabimit, HDRS udhëzon serverin që vetëm të kthejë kokën e dështimit të postës. Nëse RET nuk është e specifikuar, është deri tek serveri çfarë të bëjë. Në shumicën e rasteve HDRS do të jetë vlera e paracaktuar.
ENVID i takon vërtet dërguesit pasi ajo ose (në vend të kësaj) klienti i saj i emailit do të jetë i vetmi që na bën këtë identifikues të zarfit . Qëllimi i tij është të tregojë dërguesin që i dërgon email një mesazhi të gabuar të lëshuar gabimisht. Formati i kësaj ID-je në thelb i lihet imagjinatës së dërguesit. Ne nuk do të përdorim ENVID në shembullin tonë (imagjinatë!):
MAIL NGA: sender@example.com RET = HDRS
250 sender@example.com ... Dërguesi ok
Me sa duket, ne vetëm duam të marrim përsëri headers në DSN tonë.
Zgjerimet e Marrësit DSN
RCPT TO: merr edhe pjesën e saj të drejtë të zgjerimeve: NOTIFY dhe ORCPT.
Njoftoni është zemra e vërtetë e DSN. Tregon serverin kur duhet të dërgojë një njoftim për statusin e shpërndarjes. Vlera e parë e mundshme nuk është kurrë që do të thotë se në asnjë rrethanë DSN duhet t'i kthehet dërguesit. Kjo nuk ishte e mundur pa DSN. Pastaj nuk ka sukses, i cili do t'ju njoftojë kur postimi juaj si i arrave në destinacionin e tij. FAILURE është homologu i SUCCESS (!): Një DSN do të arrijë nëse një mbërritje ndodhi gjatë dorëzimit. Opsioni i fundit është DELAY: do të njoftoheni nëse ka një vonesë të pazakontë në dorëzim, por rezultati i dorëzimit aktual (suksesi apo dështimi) ende nuk është vendosur. ASNJËSHTË duhet të jetë argumenti i vetëm nëse përcaktohet, tre të tjerat mund të shfaqen në një listë, të kufizuar nga një presje. SUKSESi dhe DËSHTIMI përbëjnë një skuadër mjaft të fortë së bashku (!), Duke ju thënë (pothuajse) çdo rast se çfarë ka ndodhur me postën tuaj.
Qëllimi i ORCPT është që të ruajë marrësin origjinal të një mesazhi PE, për shembull nëse përcillet në një adresë tjetër. Argumenti për këtë opsion është adresa e emailit e marrësit origjinal së bashku me llojin e adresës. Lloji i adresës vjen së pari, pasuar nga një pikëpresje dhe më në fund adresa. Për shembull:
RCPT TO: support@example.com Njoftoni = Dështim, vonesë ORCPT = rfc822; support@example.com
250 support@example.com ... Marrësi ok (do të radhë)
Kjo pasohet nga DATA si ne e njohim dhe përfundimisht, me shpresë, një njoftim për statusin e shpërndarjes që ju njofton për një sukses.
A punon DSN?
Natyrisht, gjithë kjo bukuri dhe zgjuarsi do të funksionojë vetëm nëse agjentët e transportit të postës nga dërguesi tek marrësi mbështesin DSN-në. Një ditë ata do.