Oznámení o stavu doručení (DSN) existuje již od RFC 821 (1982). Jakmile je DATA část protokolu SMTP hotová a server přijme e-mail k doručení, je za něj odpovědná společnost DSN. Pokud se z nějakého důvodu e-mail nemůže dostat k příjemci, musí jej DSN odeslat zpět původnímu odesílateli s oznámením chyby. Tato stará konvence buď znamenala, že jste obdrželi chybovou zprávu, nebo jste neobdrželi nic. E-mail možná dorazil nebo možná nedorazil. Chybové zprávy byly v mnoha případech stejně užitečné jako žádné chybové zprávy.
Rozšíření DSN na SMTP
RFC 1891 navrhuje některá rozšíření protokolu SMTP, která by měla vyústit ve spolehlivější a použitelnější systém DSN. Jedná se o sadu rozšíření příkazů MAIL a RCPT.
Žádné EHLO, žádná zábava
Nejprve se ujistěte, že server podporuje DSN – tj. Řekněte mu EHLO a pozorně poslouchejte. Pokud odpoví s DSN někde v seznamu funkcí, bude schopen vyhovět požadavkům. Pokud ne, zkuste jiný server nebo se přepněte zpět na e-mail bez DSN. Například: 220 larose.magnet.at ESMTP Sendmail 8.8.6 / 8.8.6; Ne, 24. srpna 1997 18:23:22 +0200
EHLO localhost
250-larose.magnet.at Dobrý den, localhost [127.0.0.1], rád vás poznávám
250-EXPN
250 slov
250-8 BITMIME
250-VELIKOST
250-DSN
250-ONEX
250 ETRN
250 XUSR
250 NÁPOVĚDA
Rozšíření odesílatele DSN
Dalším příkazem je obvykle MAIL FROM. U DSN se to nijak neliší. Můžete ale vydat dvě další možnosti: RET a ENVID. Možnost RET byla libovolně umístěna do příkazu MAIL, ale hodí se sem stejně jako kamkoli jinde. Účelem je určit, kolik z původní zprávy má být vráceno v případě selhání doručení. Platné argumenty jsou FULL a HDRS. FULL znamená, že do chybové zprávy by měla být zahrnuta úplná zpráva. HDRS dává serveru pokyn, aby vrátil pouze záhlaví vadné pošty. Pokud není zadán RET, je na serveru, co má dělat. Ve většině případů je výchozí hodnotou HDRS. ENVID patří odesílateli jako odesílatel nebo (spíše) e-mailový klient odesílatele bude jediný, kdo používá tento identifikátor obálky. Jeho účelem je sdělit odesílateli, kterému e-mailu odpovídá případně vydaná chybová zpráva. Formát tohoto ID je ponechán na představivosti odesílatele. V tomto příkladu se nepoužívá ENVID: MAIL FROM: [email protected] RET = HDRS
250 [email protected] … Odesílatel je v pořádku
Rozšíření příjemců DSN
RCPT TO má také svůj spravedlivý podíl na rozšířeních: NOTIFY a ORCPT. NOTIFY je jádrem DSN. Říká serveru, kdy má odeslat oznámení o stavu doručení. Možnosti zahrnují:
- NIKDY neznamená, že za žádných okolností nesmí být DSN vráceno odesílateli. Bez DSN to nebylo možné.
- ÚSPĚCH upozorní, když pošta dorazí na místo určení.
- FAILURE doručí DSN, pokud během doručení došlo k chybě.
- DELAY odešle oznámení, pokud dojde k neobvyklému zpoždění dodávky, ale o skutečném výsledku dodávky (úspěch nebo neúspěch) ještě není rozhodnuto.
NIKDY nesmí být jediným argumentem, pokud je uveden. Ostatní tři se mohou objevit v seznamu odděleném čárkou. Účelem ORCPT je zachovat původního příjemce e-mailové zprávy, například pokud je předána na jinou adresu. Argumentem pro tuto možnost je e-mailová adresa původního příjemce spolu s typem adresy. Typ adresy je na prvním místě, následuje středník a nakonec adresa. Například: RCPT TO: [email protected] NOTIFY = FAILURE, DELAY ORCPT = rfc822; [email protected]
250 [email protected] … Příjemce v pořádku (bude ve frontě) Poté následují DATA a oznámení o stavu doručení úspěchu.
Funguje DSN?
DSN funguje pouze v případě, že agenti přenosu pošty od odesílatele k příjemci podporují DSN.