Dokonce i krátký pohled na protokol SMTP si všimnete, že vedle obvyklého HELO je také EHLO, což činí Rozšířené SMTP server propaguje své schopnosti nad rámec původního standardu. Jedním z nich je DSN. DSN? Jsou DNA a DDT nedostatečné?
Chcete-li tvrdit, že e-mail je nespolehlivý, měl by někdo " … jejich server lépe; jedla mou poštu … "není neobvyklé. Přesto není mnoho důvodů k podpoře těchto podezření.
dodávka S tatus N Oznámení bylo kolem od RFC 821 (od roku 1982). Jakmile je DATA část protokolu SMTP dokončena a server přijal e-mail na doručení, je odpovědný za to. Pokud se z jakéhokoli důvodu nemůže dostat až k příjemci, musí je odeslat zpět s oznámením chyby původnímu odesílateli. To vedlo k nějakému obskurnímu e-mailu.
Kromě toho tato stará konvence znamenala, že buď máte chybovou zprávu, nebo máte nic v takovém případě jste to věděli nic : e-mail může přišel nebo nemusí. Chybová hlášení byla v mnoha případech stejně užitečná jako žádná chybová hlášení. S tím, že e-mail bude čím dál důležitější, toto již není uspokojivé (jako kdyby to bylo dříve).
DSN rozšíření na SMTP
RFC 1891 navrhuje některé rozšíření protokolu SMTP, které by měly vést k spolehlivějšímu a použitelnějšímu systému DSN. Jedná se o sadu rozšíření příkazů MAIL a RCPT.
Žádný EHLO, žádná zábava
Nejprve se musíme ujistit, že server podporuje službu DSN. Musíme mu tedy říct EHLO a pozorně poslouchat. Pokud reaguje s DSN někde v seznamu funkcí, můžeme předpokládat, že bude schopen vyhovět našim požadavkům. Pokud ne, pak ne: můžeme zkusit jiný server nebo prostě jít zpět na e-mail bez DSN. Napří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 potěšením se s vámi setkávám250-EXPN250-VERB250-8BITMIME250-SIZE250-DSN250-ONEX250-ETRN250-XUSR250 HELP Naštěstí mimo jiné nalezneme DSN. Dalším příkazem je obvykle MAIL FROM. S DSN to není nijak odlišné. Existují však ještě dvě další možnosti, které můžete vydat: RET a ENVID. Možnost RET byla spíše libovolně umístěna v příkazu MAIL, ale hodí se zde stejně jako kdekoli jinde. Účelem je určit, kolik z původní zprávy byste měli vrátit v případě selhání doručení. Platné argumenty jsou FULL a HDRS. První znamená, že kompletní zpráva by měla být zahrnutá do chybové zprávy, HDRS instruuje server pouze vrátit záhlaví neúspěšné pošty. Pokud RET není zadán, je na serveru co dělat. Ve většině případů bude výchozí hodnota HDRS. ENVID skutečně patří odesílateli, protože ji nebo její poštovní klient bude jediný, kdo to využije identifikátor obálky . Jeho účelem je informovat odesílatele, kterému e-mailu odpovídá pravděpodobně vydaná chybová zpráva. Formát tohoto ID je v podstatě ponechán na představivost odesílatele. V našem příkladu nepoužijeme ENVID: MAIL FROM: [email protected] RET = HDRS250 odesí[email protected] … Odesílatel ok Zdá se, že chceme získat záhlaví pouze v našem DSN. RCPT TO: získává také spravedlivý podíl rozšíření: NOTIFY a ORCPT. NOTIFY je skutečným srdcem DSN. Říká to serveru když odeslat oznámení o stavu doručení. První možná hodnota je NIKDY, což znamená, že DSN se za žádných okolností nesmí vrátit odesílateli. To nebylo možné bez DSN. Pak je tam SUCCESS, který vás upozorní, když vaše poštovní zásilka dorazí na místo určení. FAILURE je protějšek SUCCESS: pokud dojde k chybě během doručení, přijde DSN. Poslední možností je DELAY: Budete upozorněni v případě neobvyklého zpoždění v doručení, ale skutečný výsledek doručení (úspěch nebo neúspěch) ještě nebylo rozhodnuto. NIKDY musí být jediným argumentem, pokud je uvedeno, ostatní tři se mohou objevit v seznamu vymezených čárkou. SUCCESS a FAILURE dohromady tvoří silný tým dohromady a řeknou vám (téměř) o každém případu, co se stalo s vaší poštou. Účelem ORCPT je zachovat originál příjemce e-mailové zprávy, například pokud je přesměrován na jinou adresu. Argumentem této možnosti je e-mailová adresa původního příjemce spolu s typem adresy. Typ adresy přijde nejprve, následovaný středníkem a nakonec adresa. Například: RCPT TO: [email protected] NOTIFY = FAILURE, DELAY ORCPT = rfc822; [email protected]250 [email protected] … Příjemce ok (bude fronta) Následuje DATA, jak ji známe, a nakonec, doufejme, oznámení o stavu doručení, které vás upozorní na úspěch. Samozřejmě, všechny tyto krásy a to bude fungovat pouze v případě, že agenti zásilkové dopravy od odesílatele k příjemci podporu DSN. Někdy to udělají. Rozšíření odesílatele DSN
Přípona rozšíření DSN
Pracuje služba DSN?
