Sužinokite, kaip DSN siekia pristatyti SMTP el. Pašto pristatymo būseną.
Kada domėjosi, kas atsitiko jūsų išsiųstam el. Paštu?
Net tik trumpai pažvelgus į SMTP protokolą , jūs pastebėsite, kad be įprasto HELO taip pat yra EHLO, todėl Extended SMTP serveris reklamuoja savo galimybes ne tik pagal pradinį standartą. Vienas iš jų - DSN. DSN? Ar DNR ir DDT nepakanka?
Norėdami teigti, kad el. Paštas yra nepatikimas, kad kažkas turėtų " ... geresnį pašarų savo serverį, jis valgė mano paštą ... " nėra neįprasta. Aš pats tai darau. Tačiau nėra pagrindo remtis šiais įtarimais.
Pristatymas S tatus N otification buvo maždaug nuo RFC 821 (nuo 1982 m.). Kai tik SMTP protokolo DATA dalis yra baigta ir serveris priėmė el. Laišką pristatymui, jis yra atsakingas už tai. Jei dėl kokių nors priežasčių jis negali jį pasiekti gavėjui, jis turi grąžinti jį originaliam pranešėjui, pranešdamas apie klaidą. Tai sukėlė neaiškų el . Laišką .
Be to, ši senoji konvencija reiškia, kad arba jūs gavote klaidos pranešimą, ar jūs neturite nieko , tokiu atveju jūs nieko nežinojote: el. Laiškas galėjo būti atvykęs arba ne. Daugeliu atvejų klaidos pranešimai buvo tokie pat naudingi, kaip ir klaidų pranešimai. Kai elektroninis paštas tampa vis svarbesnis, tai jau nebėra patenkinamas (tarsi anksčiau).
DSN plėtiniai SMTP
RFC 1891 siūlo tam tikrus SMTP protokolo išplėtimus, dėl kurių turėtų būti sukurta patikimesnė ir labiau naudojama DSN sistema. Tai rinkinys išplėtimų į MAIL ir RCPT komandas (jei tai nieko nereiškia jums, skaitykite, kaip veikia SMTP, tada grįžkite čia).
Nr EHLO, nėra linksma
Pirma, turime įsitikinti, kad serveris palaiko DSN. Taigi, mes turime pasakyti jam EHLO ir atidžiai klausytis. Jei atsakymas į DSN tam tikruose funkcijų sąraše, galime manyti, kad jis galės pateikti mūsų užklausas. Jei ne, tada ne: mes galime išbandyti kitą serverį arba tiesiog grįžti į el. Laišką be DSN. Pavyzdžiui (mano įvestis yra mėlyna, serverio išvestis juoda):
220 larose.magnet.at ESMTP Sendmail 8.8.6 / 8.8.6; Sun, 24 Aug 1997 18:23:22 +0200
EHLO vietinis serveris
250-large.magnet.at Sveiki, localhost [127.0.0.1], malonu susipažinti su jumis
250-EXPN
250-VERB
250-8BITMIME
250 dydis
250-DSN
250-ONEX
250-ETRN
250-XUSR
250 PAGALBA
Laimei, be kitų dalykų, mes randame DSN.
DSN siuntėjo plėtiniai
Kita komanda paprastai yra MAIL FROM :. Naudodamiesi DSN, tai nesiskiria. Tačiau yra dvi papildomos galimybės, kurias galite išduoti: RET ir ENVID.
RET variantas buvo savavališkai įtrauktas į MAIL komandą, bet čia taip pat tinka ir kur nors kitur. Tikslas yra nurodyti, kiek jūsų pradinio pranešimo turėtų būti grąžinta, jei įvyko tiekimo nepakankamumas. Tinkami argumentai yra FULL ir HDRS. Pirmasis reiškia, kad visa žinutė turi būti įtraukta į klaidos pranešimą, o HDRS nurodė serveriui tik sugrąžinti nesėkmingo el. Pašto antraštes. Jei RET nėra nurodytas, serveris turi ką daryti. Dažniausiai HDRS bus numatytoji reikšmė.
"ENVID" tikrai priklauso siuntėjui, nes ji (arba) (jos) elektroninio pašto klientas bus vienintelis, kuris padaro mus iš šio voko identifikatoriaus . Jo paskirtis - pasakyti siuntėjui, kokiu el. Laišku pateikiamas galimas klaidos pranešimas. Šio ID formatas iš esmės paliekamas siuntėjo vaizduotei. Mes nenaudosime ENVID mūsų pavyzdyje (vaizduotėje!):
MAIL FROM: sender@example.com RET = HDRS
250 sender@example.com ... Siuntėjas gerai
Matyt, mes tik norime gauti antraštes atgal į mūsų DSN.
DSN gavėjų plėtiniai
RCPT TO: taip pat gauna teisingą pratęsimų dalį: NOTIFY ir ORCPT.
PRANEŠIMAS yra tikra DSN širdis. Jis praneša serveriui, kada siųsti pranešimą apie pristatymo būseną. Pirmoji galima vertė NĖRA, kas jokiu būdu nereiškia, kad DSN turi būti grąžintas siuntėjui. Tai nebuvo įmanoma be DSN. Tada yra "SUCCESS", kuris jus informuos, kai jūsų el. Pašto adresas bus nurodytas jo paskirties vietoje. FAILAS yra SUCCESS kolega (!): DSN atvyks, jei pristatymo metu įvyko klaida. Paskutinis variantas yra "DELAY": jums bus pranešta, jei yra neįprasta uždelsimo pristatyti, tačiau faktinio pristatymo rezultatas (sėkmė ar nesėkmė) dar nėra nuspręsta. Niekada negali būti vienintelis argumentas, jei jis nurodytas, kiti trys gali būti rodomi sąraše, kuris yra atskirtas kableliu. "SUCCESS" ir "FAILURE" sudaro gana stiprią komandą kartu (!), Tariant (beveik) bet kokiu atveju, kas atsitiko su jūsų el. Paštu.
ORCPT tikslas yra išsaugoti pirminį el. Pašto žinutės gavėją, pavyzdžiui, jei jis persiunčiamas į kitą adresą. Šio pasirinkimo argumentas yra originalaus gavėjo el. Pašto adresas kartu su adreso tipu. Pirmiausia įvyksta adreso tipas, paskui kabliataškis ir galiausiai adresas. Pavyzdžiui:
RCPT TO: support@example.com NOTIFY = FAILURE, DELAY ORCPT = rfc822; support@example.com
250 support@example.com ... Recipient ok (bus eilėje)
Toliau pateikiami DATA, kaip mes tai žinome, ir galiausiai, tikimės, pranešimas apie pristatymo būseną, pranešantis apie sėkmę.
Ar DSN veikia?
Žinoma, visas šis grožis ir protas veiks tik tuo atveju, jei pašto siuntimo agentai iš siuntėjo į gavėją palaiko DSN. Vieną dieną jie bus.