Sorry, you need to enable JavaScript to visit this website.

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

Čas nutný k přečtení
14 minut
Již přečteno

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

0 comments
Anglicky
English title: 
The analysis of undelivered electronic mail messages
English abstract: 
<p>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. </p><p>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. </p><p>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. </p><p>The procedures used in both examples could be applied to the analysis of the bounced suspicious mail messages in general. </p>
Autoři: 

Ú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

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


To: San Sanins
From: Postmaster%localdomain
Subject: =?ISO-8859-2?Q?DORU=C8EN=CD_SE_NEZDA=D8ILO=3A_
550_5=2E1=2E1_Sorry=2C_no?=
=?ISO-8859-2?Q?_mailbox_here_by_that_name=2E?=
Date: Mon, 14 Sep 2009 11:16:47 +0200

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

Content-Type: multipart/report; report-type=delivery-status; boundary= "==IFJRGLKFGIR81926UHRUHIHD"

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í

--==IFJRGLKFGIR81926UHRUHIHD

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

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

Stav doručení

--==IFJRGLKFGIR81926UHRUHIHD
Content-Type: message/delivery-status
Reporting-MTA: dns; vse.vse.cz
X-Postfix-Queue-ID: CA40F9C7
X-Postfix-Sender: rfc822; sanins@vse.cz
Arrival-Date: Mon, 14 Sep 2009 11:16:45 +0200 (CEST)

Final-Recipient: rfc822; zal.rez@seznam.cz
Original-Recipient: rfc822; zal.rez@seznam.cz
Action: failed
Status: 5.1.1
Remote-MTA: dns; mx50.seznam.cz
Diagnostic-Code: smtp; 550 5.1.1 Sorry, no mailbox here by that name.

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

--==IFJRGLKFGIR81926UHRUHIHD
Content-Type: message/rfc822

Received: from vse.vse.cz (localhost [127.0.0.1])
by vse.vse.cz (Postfix) with ESMTP id CA40F9C7
for <zal.rez@seznam.cz>; Mon, 14 Sep 2009 11:16:45 +0200 (CEST)
Received: from kotelna.vse.cz (kotelna.vse.cz [146.102.11.4])
by vse.vse.cz (Postfix) with ESMTP id C528D5C
for <zal.rez@seznam.cz>; Mon, 14 Sep 2009 11:16:45 +0200 (CEST)
MIME-Version: 1.0
To: zal.rez@seznam.cz
From: San Sanins

Content-transfer-encoding: quoted-printable
Content-type: text/plain; charset=ISO-8859-2

Ahoj Tom=E1=B9i,

--==IFJRGLKFGIR81926UHRUHIHD-- konec 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

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

1. úsek

Received: from vse.vse.cz ([146.102.16.2])
by cibetka.vse.cz (Lotus Domino Release 6.5.4FP3)
with ESMTP id 2007050220135416-84215 ; Wed, 2 May 2007 20:13:54 +0200

Received: from relay.smtp.cz (relay.smtp.cz [81.95.97.115])
by vse.vse.cz (Postfix) with ESMTP id B14A613482
for <sani@vse.cz>; Wed, 2 May 2007 20:13:41 +0200 (CEST)
Received: from in.smtp.cz (jane.smtp.cz [81.95.97.121])
by relay.smtp.cz (Postfix) with ESMTP id EEFF8DC80CF
for <sani@vse.cz>; Wed, 2 May 2007 19:40:59 +0200 (CEST)
Received: by in.smtp.cz (Postfix)
id C5E5D3001A; Wed, 2 May 2007 19:40:59 +0200 (CEST)

2. úsek

X-Originating-IP: [66.6.5.384]
X-Originating-Email: [uzivx@itrading.cz]
X-Sender: uzivx@itrading.cz
Message-Id: <20070502084101.11906.qmail@L9d16.l.pppool.de>
To: Canadian Doctor Luella <uzivx@itrading.cz>
Subject: =?ISO-8859-2?Q?=3E=3E_tato_zprava___byla_identifikovana_jako_nevyzadana?=
(zkrácený text)
From: Postmaster%localdomain
MIME-Version: 1.0
Importance: High
Date: Wed, 2 May 2007 19:40:59 +0200

3. úsek

Content-Type: multipart/report; report-type=delivery-status; boundary="==IFJRGLKFGIR50610UHRUHIHD"

--==IFJRGLKFGIR50610UHRUHIHD
Content-Type: message/delivery-status

Reporting-MTA: dns; in.smtp.cz
X-Postfix-Queue-ID: D647030018
X-Postfix-Sender: rfc822; sani@vse.cz
Arrival-Date: Wed, 2 May 2007 19:40:57 +0200 (CEST)

Final-Recipient: rfc822; uzivx@itrading.cz
Action: failed
Status: 5.0.0
Diagnostic-Code: X-Postfix; host queen.smtp.cz[81.95.97.107] said: 554 qq
permanent problem (#5.4.7) - from=<sani@vse.cz> to=<uzivx@itrading.cz>
reason
tests=HTML_MESSAGE,?HTML_MIME_NO_HTML_TAG,MIME_HTML_ONLY,URIBL_BLACK,URIBL_OB_SURBL (in reply to end of DATA command)

--==IFJRGLKFGIR50610UHRUHIHD
Content-Type: message/rfc822

Received: from vbmailshield.smtp.cz (jane.smtp.cz [81.95.97.121])
by in.smtp.cz (Postfix) with SMTP id D647030018
for <uzivx@itrading.cz>; Wed, 2 May 2007 19:40:57 +0200 (CEST)
Received: from in.smtp.cz ([81.95.97.125])
by jane.smtp.cz ([81.95.97.121])
with SMTP (gateway) id A018A6D1E0A; Wed, 02 May 2007 19:40:57 +0200
Received: from L9d16.l.pppool.de (L9d16.l.pppool.de [89.48.157.22])
by in.smtp.cz (Postfix) with SMTP id 3E3F0CF985
for <uzivx@itrading.cz>; Wed, 2 May 2007 19:40:57 +0200 (CEST)
Received: (qmail 11904 by uid 438); Wed, 2 May 2007 07:41:01 +0100
X-Originating-IP: [66.6.5.384]
X-Originating-Email: [uzivx@itrading.cz]
X-Sender: uzivx@itrading.cz
Message-Id: <20070502084101.11906.qmail@L9d16.l.pppool.de>
To: <uzivx@itrading.cz>
Subject: RE: MedHelp 0557415
From: Canadian Doctor Luella
MIME-Version: 1.0


<STYLE>
/back/CMA/Tournament/Sherrill/Laura/supporting/xxx/1520/blackberry/live/12/treatment/Tam/receipt/Unfortunately/wa

<a href=>
<img>
</style>
--==IFJRGLKFGIR50610UHRUHIHD-- konec dopisu

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:

X-Postfix-Sender: rfc822; sani@vse.cz

Diagnostic-Code: X-Postfix; host queen.smtp.cz[81.95.97.107] said: 554 qq permanent problem (#5.4.7) - from=<sani @vse.cz> to=uzivx@itrading.cz reason
tests=HTML_MESSAGE,?HTML_MIME_NO_HTML_TAG,MIME_HTML_ONLY,URIBL_BLACK,URIBL_OB_SURBL (in reply to end of DATA command)

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ů.

Použitá literatura:
  1. Klensin, J. (ed.). "Simple Mail Transfer Protocol", RFC 2821, Apr/2001. (Pages=79)(Format=.txt) (Obsoletes RFC 821, RFC 974, RFC 1869) (Updates RFC 1123).
  2. Resnick, P. (ed.). "Internet Message Format", RFC 2822, Apr/2001. (Pages=51) (Format=.txt) (Obsoletes RFC 821).
Hodnocení: 
Průměr: 2 (hlasů: 8)
PINKAS, Otakar. Průzkum nedoručených dopisů elektronické pošty. Ikaros [online]. 2009, ročník 13, číslo 12 [cit. 2024-10-10]. urn:nbn:cz:ik-13290. ISSN 1212-5075. Dostupné z: http://ikaros.cz/node/13290

automaticky generované reklamy
registration login password