Uzziniet, kā DSN mērķis ir ieviest SMTP e-pasta piegādes statusu.
Kādreiz domājuši, kas notika ar jūsu nosūtīto e-pasta ziņojumu?
Pat tikai īsu pārskatu par SMTP protokolu jūs pamanīsiet, ka papildus parastajam HELO ir arī EHLO, kas padara paplašināto SMTP serveri reklamēt savas iespējas pēc sākotnējā standarta. Viens no tiem ir DSN. DSN? Vai DNS un DDT nav pietiekami?
Lai apgalvotu, ka e-pasts ir neuzticams, ka kādam vajadzētu " ... barot viņu serveri labāk, tas ēda manu pastu ... " nav nekas neparasts. Es pats to daru. Tomēr nav pietiekami daudz iemeslu šo aizdomu atbalstam.
Piegādes S tatus N otification ir aptuveni kopš RFC 821 (no 1982). Tiklīdz SMTP protokola DATA daļa ir pabeigta un serveris ir pieņēmis piegādes e-pastu, tas ir par to atbildīgs. Ja kāda iemesla dēļ tas nespēj to nosūtīt saņēmējam, tam jānosūta atpakaļ ar sākotnējā sūtītāja paziņojumu par kļūdu. Rezultātā tika izveidots neskaidrs e-pasts .
Papildus tam šī vecā konvencija nozīmēja, ka vai nu jums ir kļūdas ziņojums, vai arī jums nav nekas , tādā gadījumā jūs neko nezinājāt: e-pasts, iespējams, ir ieradies vai arī tas nav iespējams. Daudzos gadījumos kļūdas ziņojumi bija tikpat noderīgi, kā nav kļūdu ziņojumi. Ar e-pasta kļūst arvien svarīgāka, tas vairs nav apmierinošs (it kā tas bija agrāk).
DSN paplašinājumi uz SMTP
RFC 1891 piedāvā dažus SMTP protokola paplašinājumus, kā rezultātā būtu jānodrošina uzticamāka un lietderīgāka DSN sistēma. Tas ir paplašinājumu kopums pasta un RCPT komandām (ja tas jums neko nedara, izlasiet, kā darbojas SMTP, un pēc tam atgriezieties šeit).
Nē EHLO, nav jautrības
Pirmkārt, mums jāpārliecinās, vai serveris atbalsta DSN. Tādēļ mums ir jāsaka viņam EHLO un uzmanīgi klausies. Ja reizē ar DSN reaģē uz funkciju sarakstā, mēs varam pieņemt, ka tā spēs apkalpot mūsu pieprasījumus. Ja nē, tad nē: mēs varam izmēģināt citu serveri vai vienkārši atgriezties uz e-pastu bez DSN. Piemēram (mana ievade ir zila, servera izeja ir melna):
220 larose.magnet.at ESMTP Sendmail 8.8.6 / 8.8.6; Saule, 24 august 1997 18:23:22 +0200
EHLO lokālais tīkls
250-laraks.magnet.at Labais vietējais host [127.0.0.1], ar prieku satikties ar jums
250-EXPN
250-VERB
250-8BITMIME
250 izmēra
250-DSN
250-ONEX
250-ETRN
250-XUSR
250 PALĪDZĪBA
Par laimi, cita starpā, mēs atrodam DSN.
DSN sūtītāju paplašinājumi
Nākamā komanda parasti ir MAIL FROM :. Ar DSN tas nav atšķirīgs. Bet jums var būt divas papildu iespējas: RET un ENVID.
RET opcija bija diezgan patvaļīgi ievietota POST komandā, bet tā ir piemērota arī šeit, kā arī jebkur citur. Mērķis ir norādīt, cik liela daļa no jūsu sākotnējā ziņojuma būtu jānosūta gadījumā, ja tiek piegādāts neveiksmes. Derīgie argumenti ir FULL un HDRS. Pirmais nozīmē, ka pilnīga ziņa jāiekļauj kļūdas ziņojumā, HDRS uzdod serverim tikai atgriezt neveiksmīgā pasta galvenes. Ja RET nav norādīts, serverim ir jādara viss, ko darīt. Vairumā gadījumu HDRS būs noklusējuma vērtība.
ENVID patiešām pieder sūtītājam, jo viņa vai (drīzāk) viņas e-pasta klients būs vienīgais, kas mūs padara par šī aploksnes identifikatoru . Tās nolūks ir paziņot sūtītājam, kurš e-pasta ziņojums atbilst iespējami izdotajam kļūdas ziņojumam. Šī ID formāts būtībā tiek atstāts uz sūtītāja iztēli. Mēs neizmantosim ENVID mūsu piemērā (iztēle!):
MAIL FROM: sender@example.com RET = HDRS
250 sender@example.com ... sūtītājs ok
Acīmredzot mēs tikai vēlamies iegūt galvenes atpakaļ mūsu DSN.
DSN adresātu paplašinājumi
RCPT TO: saņem arī taisnīgu paplašinājumu daļu: NOTIFY un ORCPT.
PAZIŅOJUMS ir patiesā DSN sirds. Kad serverim tiek nosūtīts piegādes statusa paziņojums. Pirmais iespējamais lielums NAV, kas nozīmē, ka DSN nekādā gadījumā nav jāatdod atpakaļ sūtītājam. Tas nebija iespējams bez DSN. Tad ir veiksme, kas paziņos, kad jūsu pasts tiks nosūtīts galamērķī. NEPĀRTRAUKTS ir SUCCESS partneris (!): DSN ieradīsies, ja piegādes laikā radās kļūda. Pēdējā iespēja ir DELAY: jums tiks paziņots, ja piegāde ir neparasta kavēšanās, bet faktiskās piegādes iznākums (veiksme vai neveiksme) vēl nav pieņemts. NE VAIRĀK ir jābūt vienīgam argumentam, ja tas ir norādīts, pārējie trīs var parādīties sarakstā, kas ir norobežots ar komatu. SUCCESS un FAILURE veido diezgan spēcīgu komandu kopā (!), Kas jums (gandrīz) sakot, kas notika ar jūsu e-pastu.
ORCPT mērķis ir saglabāt sākotnējo e-pasta ziņojuma saņēmēju, piemēram, ja tas tiek pārsūtīts uz citu adresi. Šīs opcijas arguments ir sākotnējā adresāta e-pasta adrese un adreses veids. Vispirms tiek parādīts adreses veids, kam seko semikols un visbeidzot adrese. Piemēram:
RCPT TO: support@example.com NOTIFY = FAILURE, DELAY ORCPT = rfc822; support@example.com
250 support@example.com ... Labuma guvējs (būs rindā)
Pēc tam seko DATI, kā mēs to zinām, un galu galā, cerams, paziņojums par piegādes statusu, paziņojot jums par panākumiem.
Vai DSN darbojas?
Protams, viss šis skaistums un asprātība darbosies tikai tad, ja pasta pārvadātāji no sūtītāja uz adresātu atbalsta DSN. Kādu dienu viņi būs.