Finndu út hvernig DSN miðar að því að kynna sendingarstöðu til SMTP tölvupósts.
Ever wondered hvað varð um tölvupóst sem þú sendir?
Jafnvel bara stuttur líta á SMTP siðareglur mun hafa þig eftir því að fyrir utan venjulega HELO, þá er líka EHLO, sem gerir SMTP framreiðslumaðurinn kleift að auglýsa getu sína fyrir utan upprunalegu staðalinn. Einn af þessum er DSN. DSN? Eru DNA og DDT ekki nóg?
Til að halda því fram að tölvupósturinn sé óáreiðanlegur, að einhver ætti að " ... fæða netþjóninn betur, það át póstinn minn ... " er ekki óalgengt. Ég geri það sjálfur. Samt er ekki mikið ástæða til að styðja þessar grunsemdir.
Afhending S tatus N otification hefur verið í kringum RFC 821 (frá 1982). Um leið og DATA hluti SMTP siðareglunnar er lokið og þjónninn hefur samþykkt tölvupóstinn til afhendingar er hann ábyrgur fyrir því. Ef það af einhverri ástæðu er ekki hægt að komast í gegnum viðtakandann verður það að senda það aftur með tilkynningu um villuna til upprunalegu sendanda. Þetta leiddi til einhvers hylja tölvupósts .
Burtséð frá því átti þetta gamla samkomulag að annað hvort þú fékkst villuboð eða þú fékkst ekkert í því tilviki sem þú vissir ekkert : Netfangið kann að hafa komið eða það gæti það ekki. Villa skilaboðin í mörgum tilvikum voru alveg eins gagnlegar og engar villuboð. Með tölvupósti verða mikilvægari er þetta ekki lengur fullnægjandi (eins og það var áður).
DSN Eftirnafn til SMTP
RFC 1891 leggur til nokkrar viðbætur við SMTP siðareglur sem ætti að leiða til áreiðanlegri og meira nothæft DSN kerfi. Það er sett viðbót við MAIL og RCPT skipanirnar (ef þetta þýðir ekkert fyrir þig, lesðu hvernig SMTP virkar og farðu aftur hér.).
Nei EHLO, ekkert gaman
Í fyrsta lagi verðum við að ganga úr skugga um að þjónninn styður DSN. Þannig verðum við að segja EHLO við hann og hlusta vandlega. Ef það bregst við DSN einhvers staðar í aðgerðalistanum getum við gert ráð fyrir að það geti þjónað beiðnum okkar. Ef ekki, þá ekki: við getum reynt aðra miðlara eða einfaldlega fallið aftur í tölvupóst án DSN. Til dæmis (inntak mín er blár, framleiðsla miðlara er svartur):
220 larose.magnet.at ESMTP Sendmail 8.8.6 / 8.8.6; Sunnudagur, 24. ágúst 1997 18:23:22 +0200
EHLO localhost
250-larose.magnet.at Halló localhost [127.0.0.1], ánægð að hitta þig
250-EXPN
250-VERB
250-8BITMIME
250-Stærð
250-DSN
250-ONEX
250-ETRN
250-XUSR
250 Hjálparstarf
Til allrar hamingju, meðal annars finnum við DSN.
DSN Sending Eftirnafn
Næsta skipun er venjulega póstur frá :. Með DSN er þetta ekkert öðruvísi. En það eru tveir viðbótarvalkostir sem þú getur gefið út: RET og ENVID.
The RET valkostur var frekar geðþótta sett í MAIL stjórn, en það passar hér eins og heilbrigður eins og það myndi annars staðar. Tilgangurinn er að tilgreina hversu mikið af upprunalegu skilaboðum þínum ber að skila ef verslunarbilun er fyrir hendi. Gildir rök eru FULL og HDRS. Fyrr þýðir að heill skilaboðin ætti að vera innifalinn í villuboðinu, HDRS gefur til kynna að þjónninn skili einungis hausnum sem mistókst póstur. Ef RET er ekki tilgreint, er það allt að þjóninum hvað á að gera. Í flestum tilvikum er HDRS sjálfgefið gildi.
ENVID tilheyrir raunverulega sendanda eins og hún eða (frekar) tölvupóstþjónninn hennar verður sá eini sem gerir okkur að þessum umslagseinkenni . Tilgangurinn er að segja sendanda hvaða tölvupósti sem líklega er gefin út villandi skilaboð svarar til. Snið þessa auðkenni er í grundvallaratriðum skilið eftir ímyndunarafl sendanda. Við munum ekki nota ENVID í fordæmi okkar (ímyndunarafl!):
Póstur frá: sendanda@example.com RET = HDRS
250 sendandi@example.com ... Sendandi í lagi
Apparently, við viljum aðeins að fá hausinn aftur í DSN okkar.
DSN Viðtakandi Eftirnafn
The RCPT TO: fær einnig sanngjarnan hlut í viðbótum: NOTIFY og ORCPT.
NOTIFY er raunverulegt hjarta DSN. Það segir miðlara hvenær á að senda tilkynningu um afhendingu. Fyrsta mögulega gildi er ALDRI sem þýðir að DSN verður aldrei skilað til sendanda. Þetta var ekki mögulegt án DSN. Þá er SUCCESS, sem mun tilkynna þér þegar pósturinn þinn er arraved á áfangastað. Misskilningur er mótspyrnaþáttur (!): DSN mun koma ef refsing átti sér stað við afhendingu. Síðasti kosturinn er DELAY: þú verður tilkynnt ef óvenjulegt tafir eru á afhendingu, en niðurstaða raunverulegs fæðingar (árangur eða bilun) er ekki enn ákveðið. ALDRI verður að vera eina rökin ef hún er tilgreind, hinir þrír geta birst á lista, afmarkað með kommu. SUCCESS og FAILURE gera saman fyrir nokkuð sterkt lið saman (!) Og segja þér (næstum) hvað sem gerðist með póstinn þinn.
Tilgangur ORCPT er að varðveita upphaflega viðtakanda tölvupóstskeyta, til dæmis ef hún er send á annað heimilisfang. Rökin við þennan möguleika eru netfangið upprunalega viðtakandann ásamt heimilisfanginu. Upplýsingategundin kemur fyrst og síðan með hálfkvísl og loks heimilisfangið. Til dæmis:
RCPT TO: support@example.com NOTIFY = FAILURE, DELAY ORCPT = rfc822; stuðningur@example.com
250 support@example.com ... Viðtakandi í lagi (verður biðröð)
Þetta er fylgt eftir með DATA eins og við þekkjum það og að lokum, vonandi, tilkynning um afhendingartilkynningu sem tilkynnir þér um árangur.
Virkar DSN?
Auðvitað mun allt þetta fegurð og vitsmuni aðeins virka ef póstflutningsaðilar frá sendanda til viðtakanda styðja DSN. Einhver dagur sem þeir vilja.