Průzkum nedoručených dopisů elektronické pošty

0 comments

Anglicky

English title:

The analysis of undelivered electronic mail messages

English abstract:

The electronic mail message protocols include rules guaranteeing reliable message delivery. In case of failures caused by incorrect receiver‘s name entry, by an e-mail box overflow, etc. or security risks, the mail systems procure message originator with a SMTP error message reply. In most situations, the user is capable to re-act properly using information from graphical user interface. In complex cases, such as forged messages, the appropriate analysis of delivery status notifications is needed. It is based on the exploration of the fields in the headers called Received:, on their contents and the sequence of particular Received headers. The contents of a message body should be taken into account. Two different mail messages were subject to analysis. The first one matches mailing rules and serves as a positive example. The second one contains some suspicious or incorrect values in X-headers, in some fields in “received” headers and even in the mail body. The undertaken analysis confirms the justified rejection by the SMTP server. Nevertheless, the notification report was directed to an innocent receiver. The responsible SMTP server was not considered (in the year 2007) as a fully safe one. The rejected mail was a forged one. Unfortunately, its issuer cannot be reliably identified. The procedures used in both examples could be applied to the analysis of the bounced suspicious mail messages in general.

Autoři:

Pinkas, Otakar [1]

Vydání:

2009, ročník 13, číslo 12 [2]

Rubrika:

Informační technologie a elektronická komunikace [3]

Úvod

Tento příspěvek navazuje na dva předchozí uveřejněné v časopisu Ikaros (Zabezpečení v systému elektronické pošty [4] a Textová povaha elektronické pošty v Internetu [5]). 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.

[6]

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.