Zjistěte, jak má služba DSN v úmyslu zavést stav doručení na e-mail SMTP.
Jste někdy uvažovali, co se stalo s e-mailem, který jste poslali?
Dokonce i krátký pohled na protokol SMTP si všimnete, že kromě obvyklého HELO existuje i EHLO, což dělá z rozšířeného SMTP serveru své schopnosti nad rámec původního standardu. Jedním z nich je DSN. DSN? Jsou DNA a DDT nedostatečné?
Chcete-li se domnívat, že e-mail je nespolehlivý, že by někdo měl " ... dát svůj server lépe, jedl mou poštu ... " není neobvyklé. Dělám to sám. Přesto není mnoho důvodů k podpoře těchto podezření.
Dodávací zařízení Oznámení je již 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 z jakéhokoli důvodu to 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ď jste dostali chybové hlášení, nebo jste neměli nic, v jakém případě jste nevěděli nic : e-mail mohl přijít nebo to možná nebude. 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 (pokud to pro vás nic neznamená, přečtěte si, jak funguje SMTP a vraťte se sem).
Žá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 bude odpovídat DSN 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 (můj vstup je modrý, výstupní server je černý):
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 potěšením se s vámi setkávám
250-EXPN
250-VERB
250-8BITMIME
250-SIZE
250-DSN
250-ONEX
250-ETRN
250-XUSR
250 HELP
Naštěstí mimo jiné nalezneme DSN.
Rozšíření odesílatele DSN
Následující příkaz 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, neboť (nebo spíše) její poštovní klient bude jediný, který nás činí tímto identifikátorem 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 (představivost!) Nepoužijeme ENVID:
MAIL FROM: sender@example.com RET = HDRS
250 odesílatel@example.com ... Odesílatel ok
Zdá se, že chceme získat záhlaví pouze v našem DSN.
Přípona rozšíření DSN
RCPT TO: získává také spravedlivý podíl rozšíření: NOTIFY a ORCPT.
NOTIFY je skutečným srdcem DSN. Sděluje serveru, kdy má 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 tu SUCCESS, který vás upozorní, když vaše poštovní zásilka odpovídá vašemu cíli. FAILURE je protějšek SUCCESS (!): DSN dorazí, pokud při dodávce nastane arror. 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 nesmí být jediným argumentem, pokud je zadán, ostatní tři se mohou objevit v seznamu, vymezený čárkou. SUCCESS a FAILURE dohromady vynahradí docela silný tým dohromady (!), Který vám (skoro) řekl, co se stalo s vaší poštou.
Účelem ORCPT je uchování původního 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: support@example.com NOTIFY = FAILURE, DELAY ORCPT = rfc822; support@example.com
250 support@example.com ... 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.
Pracuje služba DSN?
Samozřejmě, tato krása a vtip budou fungovat pouze v případě, že agenti zásilkové dopravy od odesílatele k příjemci podporují DSN. Někdy budou.