Úvod

Tento příspěvek navazuje na dva předchozí uveřejněné v časopisu Ikaros (Zabezpečení v systému elektronické pošty a Textová povaha elektronické pošty v Internetu). Je zaměřen na příjem elektronické pošty, zvláště na zprávu o nedoručeném dopisu. Nejčastějším důvodem pro zaslání zprávy o nedoručení jsou zkomolené (neexistující) jméno adresáta (nenalezená schránka), přeplněná schránka a odmítnutí dopisu z bezpečnostních důvodů.

Uživatel elektronické pošty v grafickém prostředí obvykle najde informace, jak správně vyhodnotit zprávu o nedoručení dopisu a správně jednat. Ve složitějších případech a v případě zájmu o mechanismus odesílání a příjmu elektronické pošty je nutné provést rozbor průvodních informací, které vytvářejí poštovní servery, a ověřovat skutečnosti, které se týkají přenosu a doručení celého dopisu.

Na dvou příkladech jsou rozebrány zprávy o nedoručení na základě textové podoby dopisů. V prvním odesilatel uvedl nesprávnou adresu příjemce a poštovní server proto zaslal původnímu odesílateli zprávu o nenalezení schránky. V příkladu jsou ukázána důležitá pole hlavičky Received, úplný výčet jejích polí a jejich správných a ověřitelných hodnot a také návaznost hlaviček přidávaných poštovními servery během přenosu zprávy k cíli.

Druhý příklad představuje rizikový dopis, který odeslal někdo jiný než příjemce zprávy o nedoručení. Cílem rozboru je určení nesprávných hodnot v hlavičkách vráceného dopisu a posouzení jeho obecné správnosti, včetně obsahu těla dopisu. Protože příjemce nedoručené zprávy dopis sám nikdy neodeslal, směřuje pátrání ke skutečnému odesílateli a poštovním serverům, které se na přenosu rizikového dopisu podílely.

Skutečné hodnoty v adresách elektronické pošty jsou z bezpečnostních důvodů nahrazeny hodnotami fiktivními.

Závazný tvar dopisu a pravidla chování poštovních programů

Přesné určení tvaru dopisu je obsaženo v dokumentu RFC 2822. Pravidla komunikace mezi poštovními servery, tj. klientem SMTP a serverem SMTP, jsou obsažena v dokumentu RFC 2821. Zde uvádíme jen vybrané pojmy a pravidla, která pomáhají určovat formální správnost dopisu a odlišovat pravé dopisy od falšovaných.

Elektronický dopis vyhovující RFC 2822 a RFC 2821 se skládá z obálky, hlaviček a těla. Obálka slouží k dialogu dvou SMTP serverů. Příjemci se nedopravuje, ale hodnoty z příkazů MAIL FROM a RCPT TO se uvádějí v hlavičce Received. Hodnota z MAIL FROM se objevuje v hlavičce Return-Path, kterou přidává poštovní server ukládající dopis do poštovní schránky.

Protokol SMTP nepředepisuje přísnou kontrolu hodnot v příkazu MAIL FROM. Ten určuje adresu odesílatele. Právě adresa odesílatele bývá někdy podvržena nebo smyšlena, aby nebylo možno zjistit skutečného původce zprávy, obvykle v případech, kdy odesílatel rozšiřuje hromadné reklamní zprávy, když se snaží zahltit schránku příjemce nebo když prostě zasílá nevyžádané zprávy.

Hlavičky Received jsou přidávány každým poštovním serverem, který dopis přijal a poslal dále (nebo uložil do schránky příjemce). Hlavička Received se skládá z těchto polí (podle RFC 2822 povinných):

• From – doménové jméno odesílajícího serveru,
• By – doménové jméno přijímacího serveru,
• With – označení poštovního protokolu,
• Id – jedinečné označení zprávy na určitém serveru,
• For – adresa příjemce zprávy,
• Datum a čas – doba přijetí zprávy.

Hodnotu pole „from“ přebírá SMTP server z příkazu HOST. V poli „for“ je uvedena hodnota z příkazu RCPT TO. V příkazu HOST mohou být uvedeny podvržené nebo smyšlené hodnoty, které jsou převzaty do pole „from“.

V polích Received se mohou obecně nacházet údaje v kulatých závorkách. Ty přidává přijímající server pro upřesnění na základě TCP komunikace, proto mají vyšší spolehlivost a důvěryhodnost.

Komunikace mezi klientem SMTP a serverem SMTP je řízena odpověďmi SMTP serveru (SMTP replies). Jsou to zprávy složené z třímístných číselných kódů sloužících strojovému zpracování a jim odpovídajících textů určených člověku. Skupina 5yz představuje trvale negativní odpověď na požadovanou činnost. Žádost o provedení příkazu nebyla přijata a požadovaná akce nebyla provedena. SMTP server v roli klienta nemá stejný příkaz ve stejném pořadí znovu opakovat.

Pro naše úvahy a praktické potřeby jsou důležité následující odpovědi SMTP serveru [1, s. 45] ze skupiny 5xx. Dostanou se až ke koncovému uživateli elektronické pošty. Ten musí mít alespoň minimální znalost angličtiny; pro usnadnění uvádíme vlastní překlad.

Vybrané SMTP odpovědi skupiny 5xx s překladem:

550 Requested action not taken: mailbox unavailable (e.g., mailbox not found, no access, or command rejected for policy reasons)
551 User not local; please try (See section 3.4)
552 Requested mailaction aborted: exceeded storage allocation
553 Requested action not taken: mailbox name not allowed (e.g., mailbox syntax incorrect)
554 Transaction failed (Or, in the case of a connection-opening response, "No SMTP service here")

550 Požadovaná akce neprovedena: schránka nedostupná (např. nebyla nalezena, není přístupná nebo byl příkaz zamítnut na základě konfiguračních pravidel)
551 Uživatel nemá místní konto …
552 Požadovaná poštovní akce přerušena: překročení přidělené paměti.
553 Požadovaná akce neprovedena: nepovolené jméno schránky (např. nesprávná syntaxe v názvu schránky)
554 Selhání transakce (nebo v případě navazování spojení „Zde není žádná služba SMTP“)

Oznámení o neúspěšném doručení zprávy bez rozboru

Doručené a pozdržené zprávy

Obyčejné zprávy se správným určením adresy příjemce a s nezávadným obsahem jsou obvykle bezpečně dopraveny příjemci. Odesílatel dostane od cílového serveru zprávu jen v případě, že nemůže být doručena, nebo je-li odmítnuta. Nepřijde-li tedy zpráva o neúspěšném doručení, byla zpráva skutečně doručena (s výjimkou případů, kdy některý ze serverů, který zprávu přijal, není schopen odeslat jakékoliv maily na jiný server). Existuje i možnost, aby si odesílatel od poštovního systému vyžádal zprávu o doručení.

V případě, že je cílový poštovní server mimo provoz (např. výpadek) nebo není po nějakou dobu dosažitelný, dostane odesílatel ze svého odesílajícího serveru průběžnou zprávu. Ta obsahuje sdělení, že se odesílajícímu serveru nepodařilo během několika hodin zprávu doručit a že se bude opakovaně snažit, nejdéle x dnů, o doručení zprávy. Jedná se tedy o pozdrženou zprávu.

Taková zpráva může mít např. tuto podobu (část zprávy):

message/disposition-notification
Subject: Delayed Mail (still being retried)
Your message could not be delivered for 8.0 hours.
It will be retried until it is 5.0 days old.

Může obsahovat oznámení, že jde jen o varování a že původní zprávu není nutné znovu odeslat.

Zaplněná schránka

Správce poštovního serveru vytvoří uživateli poštovního systému účet. Jeho součástí je rovněž vyhrazení velikosti diskového prostoru pro poštovní schránku. V systému Postfix se velikost prostoru schránky a největší velikost dopisu stanoví v souboru main.cf pomocí dvou řádek, např.:

mailbox_size_limit = 51200000
message_size_limit = 10240000

V příkladu je max. velikost schránky nastavena na 50 MB a velikost zprávy na max. 10 MB.

Jestliže přijímající server dostane dopis, jehož velikost překročí limit velikosti schránky, dopis neuloží a vyšle příjemci zprávu o neúspěšném uložení. Její součástí je chybový kód a také původní zpráva odesilatele.

Příklady

V prvním příkladu uvádíme jen položku speciální uživatelské složky v systému Lotus Notes.

Obr. 1: 552 - plná schránka - položka poštovní složky uživatele

V druhém příkladu vyjímáme část ze správy o neúspěšném doručení dopisu na adresu v doméně seznam.cz. Příčinou neúspěšného doručení bylo překročení diskového prostoru schránky.

Hi. This is the qmail-send program at mxh.seznam.cz.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.


>:
Quota for user 'xxxxxxxx' was exceeded. Mailbox is full.

Nenalezená schránka příjemce

Níže je uveden mírně upravený automaticky vytvořený dopis poštovního systému. Sděluje odesílateli, že příjemce nebyl na cílovém serveru nalezen.

Dopis má složitější členění:

• hlavičky dopisu místního poštovního serveru,
• návod v češtině (představen obrázkem),
• zpráva o stavu doručení,
• původní (vrácený) dopis s hlavičkami.

Řádky začínající --==IFJR . . . jsou oddělovače vícedílného dopisu.

Začátek dopisu místního poštovního serveru

Správce poštovního serveru sděluje odesilateli zprávy San Sanins z domény vse.cz, že jeho dopis nebyl doručen. Následuje vícedílná zpráva o doručení a vrácený původní dopis.

Stav doručení a původní dopis

Tato část zprávy je vícedílná. První díl obsahuje návod na opětovné odeslání dopisu: textová zpráva je v kódování UTF-8 a pro přenos je ještě použito kódování base64 (nahrazena obrázkem). Druhý vyjadřuje stav doručení dopisu. Třetí cituje původní dopis spolu s řídicími hlavičkami. Jednotlivé díly jsou odděleny řetězcem znaků (vesměs velká písmena) definovaným v klíčovém slovu „boundary“ (mez).

Návod na opakované odeslání

Obr. 2: Zpráva o neúspěšném doručení

Stav doručení

Server vse.vse.cz sděluje, že zpráva s ID CA40F9C7 došlá 14. 9. 2009 od odesílatele sanins@vse.cz a s koncovým i původním příjemcem zal.rez@seznam.cz nebyla podle serveru mx50.seznam.cz vložena do poštovní schránky cílového serveru, protože tam taková schránka neexistuje. Číslo 550 charakterizuje selhání a 5.1.1 blíže určuje příčinu neúspěchu.

Citace původního (vráceného) dopisu

Rozbor hlaviček Received a jejich zvýrazněných polí from, by, with, id a for a sledování času vede k závěru, že hodnoty v polích jsou skutečné. Žádné pole nechybí a každá hodnota je pravá. Nesprávná je pouze adresa příjemce v poli for. Existenci doménových jmen a vztah mezi adresami IP a doménovými jmény ověříme pomocí programu nslookup.

Pořadí hlaviček Received odpovídá skutečnosti, tj. zpráva byla nejdříve v rámci domény vse.cz odeslána z vnitřního (kotelna.vse.cz) na hlavní poštovní server (vse.vse.cz). Ten v doméně vse.cz přednostně odpovídá za odesílání a přijímání zpráv do/z cizích domén internetu.

V poli with se u obou serverů objevuje zkratka ESMTP, která označuje rozšíření jednoduchého poštovního protokolu. Toto rozšíření zahrnuje funkci ověření totožnosti uživatele. Uživatel sanins se před odesláním dopisu musel nejdříve přihlásit na server kotelna.vse.cz. Tím je sníženo riziko neoprávněného zasílání zpráv.

Hodnoty pole id odpovídají svým tvarem hodnotám obvykle přidělovaným programem Postfix.

Pokusy s ručním odesláním dopisu z počítače v místní síti školy mimo doménu vse.cz se nezdařily, takže lze stěží z této sítě odesílat dopisy s falšovaným jménem odesilatele.

Nedoručený dopis s bezpečnostními riziky

Obr. 3: Zpráva o zamítnutí - nevyžádaná zpráva

1. úsek

…

2. úsek

3. úsek

Rozbor rizikového dopisu

Z obr. 3 je vidět, že dopis příjemci uzivx@itrading.cz nebyl doručen, protože obsahuje bezpečnostní rizika. Zpráva o nedoručení dopisu příjemci z domény itrading.cz byla doručena příjemci sani z domény vse.cz. Jednotlivé úseky vyhodnotíme samostatně.

První úsek

V prvním úseku dopisu je nejnižší hlavička Received nestandardní: neobsahuje ani údaje from (odesílající počítač), ani for (příjemce), jen doménové jméno serveru, který dopis přijal.

Následující hlavička Received je standardní: obsahuje from, by a for. Hodnotou for je náhle příjemce sani@vse.cz, kterou předchozí server neuvedl. Proč ji však přidal server relay.smtp.cz?

Řetěz poštovních serverů zahrnuje: in.smtp.cz, relay.smtp.cz a vse.vse.cz.

Druhý úsek

V něm se nacházejí dvě pochybné hlavičky:

X-Originating-IP: [66.6.5.384] – součást 384 v IP adrese je nesprávná, max. hodnota je 255.

To: Canadian Doctor Luella - řetězec Canadian Doctor Luella spojený s adresou uzivx@itrading.cz je velmi nepravděpodobný.

Název počítače L9d16.l.pppool.de [89.48.157.22] jako součást řetězce Message-Id odpovídá i v současné době na žádosti o odezvu a dvojice doménové jméno a IP adresa si odpovídají.

Třetí úsek

Obsahuje dvě dílčí zprávy od referujícího serveru in.smtp.cz: stav doručení (message/delivery-status) a původní dopis (message/rfc822).

V části message/delivery-status jsou důležité dvě hlavičky:

Je otázkou, kde se najednou vzala hodnota sani@vse.cz v nestandardní hlavičce (X-Postfix). Diagnostický kód je složitější. Je základem pro hodnocení stránky jako rizikové (reason). Hodnota pole from s hodnotou <sani @vse.cz> náhle uvádí jako odesílatele adresu, která nepatří ani do domény itrading.cz, ani do domény smtp.cz, ani do domény pppool.de.

Hodnocení stránky HTML obsažené v těle rizikového dopisu je oprávněné. Dílčí testované položky jsou uvedeny za slovem „tests“. Ačkoli je zpráva prohlášena za typ HTML, neobsahuje značku <HTML>. V těle dopisu značka <STYLE> obsahuje textový balast a tři nesourodé značky (viz výše). Jeden z odkazů vede na podivnou spiritualistickou stránku a druhý na prodej módních tašek (nezobrazeno).

V části message/rfc822 je dnes neplatné doménové jméno vbmailshield.smtp.cz, ale údaje v závorce za ním platné jsou. Pole From: a To: obsahují stejnou hodnotu, tedy adresa odesílatele a příjemce jsou shodné, což je zvláštní.

Vyhodnocení rizikového dopisu

Dopis obsahuje nesprávné (např. IP adresa) nebo velmi nepravděpodobné hodnoty (Doctor Luella). V hlavičkách Received někdy chybějí důležitá pole (from, for) s hodnotami. Uživatel z domény itrading.cz posílá dopis sám sobě. Poštovní přenosy provádějí pro doménu itrading.cz poštovní servery z domény smtp.cz. Dopis je předáván řetězem serverů domény smtp.cz, a v tomto prostředí se náhle objevuje jako odesílatel poštovní adresa z domény vse.cz.

Odeslání padělaného dopisu z domény vse.cz bylo v r. 2007 nepravděpodobné vzhledem k vnitřním opatřením (autentizace odesílatelů). Naproti tomu si ve stejné době někteří uživatelé stěžují na otevřené předávání dopisů (open frame relay) na serveru relay.smtp.cz.

Uvedený dopis je podvržený. Příjemce z domény vse.cz dostal dopis o nedoručení, aniž by kdy nějaký dopis do domény itrading.cz (resp. smtp.cz) odeslal. Zpráva o neúspěšném doručení dopisu nesprávnému příjemci je určitou formou nevyžádané pošty. Na obsahu dopisu přitom vůbec nezáleží. Vyhledání skutečného původce dopisu je v tomto případě prakticky nemožné.

Závěry

Pečlivý rozbor vráceného dopisu na základě hlaviček Received a jejich polí, hodnot v nich obsažených, návaznosti těchto hlaviček i hlaviček specifických a s přihlédnutím k celkovému kontextu odesílání a přijímání zpráv elektronické pošty umožní ve složitějších případech blíže určit příčiny nedoručení dopisu, rozhodnout o jeho pravosti, prověřit identitu a chování zúčastněných SMTP serverů.