Zistite, ako sa služba DSN snaží vložiť stav doručenia na e-mail SMTP.
Stále ste sa čudovali, čo sa stalo s e-mailom, ktorý ste poslali?
Dokonca aj krátky pohľad na protokol SMTP si všimnete, že okrem obvyklého HELO je aj EHLO, čo robí rozšírený SMTP server propagovať jeho schopnosti nad rámec pôvodného štandardu. Jedným z nich je DSN. DSN? Sú DNA a DDT nedostatočné?
Ak chcete tvrdiť, že e-mail je nespoľahlivý, že by mal niekto " ... lepšie podávať svoj server, jedol moju poštu ... " nie je nezvyčajné. Robím to sám. Napriek tomu nie je veľa dôvodov na podporu týchto podozrení.
Dodávacie zariadenie Oznámenie bolo odvtedy od RFC 821 (od roku 1982). Akonáhle je časť protokolu SMTP dokončená a server prijal e-mail na doručenie, zodpovedá za to. Ak z nejakého dôvodu nemôže prejsť cez príjemcu, musí ju odoslať späť s oznámením chyby pôvodnému odosielateľovi. To viedlo k nejakému nejasnému e-mailu .
Okrem toho táto stará konvencia znamenala, že buď dostanete chybové hlásenie, alebo nemáte nič, v takom prípade ste nevedeli nič : e-mail mohol prišiel alebo nemusí. Chybové správy boli v mnohých prípadoch rovnako užitočné ako žiadne chybové hlásenia. Keď sa e-mail stáva čoraz dôležitejším, toto už nie je uspokojivé (ako keby to bolo predtým).
DSN Rozšírenia na SMTP
RFC 1891 navrhuje niektoré rozšírenia protokolu SMTP, ktoré by mali viesť k spoľahlivejšiemu a použiteľnejšiemu systému DSN. Ide o sadu rozšírení príkazov MAIL a RCPT (ak to pre vás nič neznamená, prečítajte si, ako funguje SMTP a potom sa sem vráťte).
Nie EHLO, žiadna zábava
Po prvé, musíme sa uistiť, že server podporuje DSN. Musíme mu teda povedať EHLO a pozorne počúvať. Ak bude DSN odpovedať na niektorom zo zoznamov funkcií, môžeme predpokladať, že bude môcť vyhovieť našim požiadavkám. Ak nie, potom nie: môžeme skúsiť iný server alebo jednoducho späť na e-mail bez DSN. Napríklad (môj vstup je modrý, výstup na serveri je čierny):
220 larose.magnet.at ESMTP Sendmail 8.8.6 / 8.8.6; Ne, 24 Aug 1997 18:23:22 +0200
EHLO localhost
250-larose.magnet.at Ahoj localhost [127.0.0.1], s potešením vás spoznávam
250 EXPN
250-sloveso
250-8BITMIME
250-SIZE
250 DSN
250 ONEX
250 ETRN
250 XUSR
250 HELP
Našťastie okrem iného nájdeme DSN.
Rozšírenia odosielateľa DSN
Ďalší príkaz je zvyčajne MAIL FROM :. Pri DSN to nie je iné. Existujú však dve ďalšie možnosti, ktoré môžete vydať: RET a ENVID.
Možnosť RET bola pomerne ľubovoľne umiestnená do príkazu MAIL, ale je tu rovnako ako kdekoľvek inde. Účelom je určiť, koľko pôvodnej správy sa má vrátiť v prípade výpadku dodávky. Platné argumenty sú FULL a HDRS. Prvý znamená, že kompletná správa by mala byť zahrnutá do chybového hlásenia, HDRS pokyn serveru len vrátiť záhlavia neúspešnej pošty. Ak RET nie je zadané, je na serveri, čo má robiť. Vo väčšine prípadov bude predvolená hodnota HDRS.
ENVID skutočne patrí odosielateľovi, pretože ona alebo (skôr) jej e-mailový klient bude jediný, ktorý nám robí tento identifikátor obálky . Jeho účelom je oznámiť odosielateľovi, ktorému e-mailu možno odpovedať chybové hlásenie. Formát tohto ID je v podstate ponechaný na predstavivosť odosielateľa. Nepoužívame ENVID v našom príklade (predstavivosť!):
MAIL FROM: sender@example.com RET = HDRS
250 odosielateľ@example.com ... odosielateľ ok
Zrejme chceme len vrátiť hlavičky späť do nášho DSN.
DSN Príjemcovia rozšírenia
RCPT TO: získal aj spravodlivý podiel rozšírení: NOTIFY a ORCPT.
NOTIFY je skutočným srdcom DSN. Informuje server, kedy má odoslať upozornenie na stav doručenia. Prvá možná hodnota NIKDY neznamená, že DSN sa za žiadnych okolností nesmie vrátiť odosielateľovi. Toto nebolo možné bez DSN. Potom je tu SUCCESS, ktorý vás upozorní, keď vaša pošta zodpovedá vášmu cieľu. FAILURE je náprotivok SUCCESS (!): DSN príde, ak sa vyskytne počas dodávky arror. Poslednou možnosťou je DELAY: Budete upozornení, ak nastane nezvyčajné oneskorenie v doručení, ale skutočný výsledok doručenia (úspech alebo neúspech) ešte nie je rozhodnuté. NIKDY nesmie byť jediným argumentom, ak je zadaný, ďalšie tri sa môžu objaviť v zozname vymedzenom čiarkou. Úspech a neúspech dokážu dohromady dosť silný tím (!), Ktorý vám (takmer) povedal, čo sa stalo s vašou poštou.
Účelom ORCPT je zachovať pôvodného príjemcu e-mailovej správy, napríklad ak je presmerovaný na inú adresu. Argument pre túto možnosť je e-mailová adresa pôvodného príjemcu spolu s typom adresy. Typ adresy prichádza prvý, nasleduje bodkočiarka a nakoniec adresa. Napríklad:
RCPT TO: support@example.com NOTIFY = ZLYHANIE, DELAY ORCPT = rfc822; support@example.com
250 support@example.com ... Príjemca ok (bude fronta)
Po ňom nasleduje DATA, ako ju poznáme, a nakoniec, dúfajme, oznámenie stavu doručenia, ktoré vás upozorní na úspech.
Pracuje služba DSN?
Samozrejme, všetka táto krása a vtip bude fungovať len vtedy, ak poštové zásielky od odosielateľa k príjemcovi podporujú DSN. Niektorý deň to urobia.