Dokonca len krátky pohľad na protokol SMTP si všimnete, že okrem obvyklého HELO je aj EHLO, čo robí predĺžený SMTP server propaguje svoje schopnosti nad rámec pôvodného štandardu. Jedným z nich je DSN. DSN? Sú DNA a DDT nedostatočné?
Aby sme tvrdili, že e-mail je nespoľahlivý, že by niekto mal " … kŕmiť ich server lepšie; jedol moju poštu … "nie je nezvyčajné, ale nie je veľa dôvodov na podporu týchto podozrení.
dodávka S tatus N ohlásenie bolo okolo 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 sa z nejakého dôvodu nemôže dostať 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 tento starý koncept znamenal, že buď máte chybové hlásenie, alebo máte nič v takom prípade ste to vedeli 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.
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 odpovie DSN niekde v zozname 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:
220 larose.magnet.at ESMTP Sendmail 8.8.6 / 8.8.6; Ne, 24 Aug 1997 18:23:22 +0200EHLO localhost250-larose.magnet.at Ahoj localhost 127.0.0.1, s potešením vás spoznávam250 EXPN250-sloveso250-8BITMIME250-SIZE250 DSN250 ONEX250 ETRN250 XUSR250 HELP Našťastie okrem iného nájdeme 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ý, kto to využije 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: MAIL FROM: [email protected] RET = HDRS250 odosielateľ@example.com … odosielateľ ok Zrejme chceme len vrátiť hlavičky späť do nášho DSN. RCPT TO: získal aj spravodlivý podiel rozšírení: NOTIFY a ORCPT. NOTIFY je skutočným srdcom DSN. Povie to serveru kedy 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 dorazí na miesto určenia. FAILURE je protipól úspory: DSN príde, ak sa vyskytne chyba počas doručenia. 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 musieť byť jediným argumentom, ak je špecifikovaný, ď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ť originál príjemca 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: [email protected] NOTIFY = ZLYHANIE, DELAY ORCPT = rfc822; [email protected]250 [email protected] … 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. Samozrejme, všetka táto krása a bude fungovať len vtedy, ak poštové zásielky od odosielateľa k príjemcovi podporujú DSN. Jedného dňa to urobia. Rozšírenia odosielateľa DSN
DSN Príjemcovia rozšírenia
Pracuje služba DSN?
