Modul 1 · 1.1
Cesta e-mailu
Modul 1: Jak funguje e-mail · Doba čtení: 9 minut
Cíl lekce: Po této lekci dokážete krok za krokem popsat, jak se e-mail dostane od odesílatele k příjemci, a u každého kroku určit, který program nebo server danou práci vykonává.
Klíčové pojmy: poštovní program (MUA), odesílací server (MSA, submission), mailový server (MTA), MX záznam, fronta, doručení (MDA), mailbox, vyzvednutí (IMAP/POP3), envelope, hlavičky
E-mail je pošta, ne chatová zpráva
Když posíláte chatovou zprávu, jde přes jednu firmu: aplikace odesílatele a aplikace příjemce komunikují se stejnými servery. E-mail funguje jinak. Odesílatel a příjemce mohou být každý u jiného poskytovatele: jeden u hostingové firmy, druhý u Gmailu, třetí u Microsoft 365 nebo na vlastním firemním serveru. Přesto e-mail dorazí. Funguje to díky tomu, že všechny mailové servery na světě dodržují stejná pravidla.
E-mail se dá dobře přirovnat k poště. Napíšete dopis (zprávu), vložíte ho do obálky s adresou (envelope), odnesete ho do schránky (odesílací server), poštovní firma zjistí, kam adresa patří (vyhledání MX záznamu), přepraví dopis do správného třídicího centra (přijímající mailový server) a ten ho vloží do schránky příjemce (mailbox). Příjemce si ho tam vyzvedne, kdy se mu to hodí.
Stanice v přehledu
Řekněme, že Anna posílá e-mail z anna@example.com na jan@example.net. Proběhne toto:
| Krok | Kdo | Co se děje | Protokol |
|---|---|---|---|
| 1 | Annin poštovní program (MUA, mail user agent) | Anna klikne na Odeslat. Program se přihlásí k odesílacímu serveru jejího poskytovatele a předá mu e-mail. | SMTP-submission, port 587 nebo 465, s přihlášením |
| 2 | Odesílací server domény example.com (MSA, mail submission agent) | Ověří, že Anna je skutečně Anna (uživatelské jméno a heslo), a zařadí e-mail do fronty. | |
| 3 | Odchozí mailový server (MTA, mail transfer agent) | Zeptá se DNS: který server přijímá poštu pro example.net? To jsou MX záznamy. | DNS |
| 4 | Odchozí MTA k přijímajícímu MTA | Naváže spojení se serverem uvedeným v MX záznamu a doručí e-mail. | SMTP, port 25 |
| 5 | Přijímající server domény example.net | Zkontroluje e-mail (spam, viry, SPF, DKIM, DMARC) a uloží ho do Janovy schránky. Tato poslední část se nazývá MDA (mail delivery agent). | |
| 6 | Janův poštovní program nebo webmail | Vyzvedne e-mail nebo ho zobrazí přímo ze serveru. | IMAP (port 993) nebo POP3 (port 995) |
U malých poskytovatelů bývají MSA, MTA a MDA často jeden a tentýž program na jednom serveru. U velkých poskytovatelů jde o samostatné clustery. Pro Vás to mnoho nemění: jsou to role, ne krabičky.
Všimněte si rozdílu mezi krokem 1 a krokem 4. Oba používají SMTP, Simple Mail Transfer Protocol (RFC 5321). V kroku 1 se ale přihlašujete a používáte port 587 nebo 465; tomu se říká submission (RFC 6409). V kroku 4 spolu komunikují dva servery na portu 25, bez přihlašování: přijímající server přijímá poštu pro své vlastní domény od kohokoli. V lekci 1.4 uvidíte, proč toto oddělení existuje.
Krok 3 zblízka: vyhledání MX záznamu
Odesílající server sám o sobě neví, kde doména example.net přijímá poštu. Zeptá se DNS:
example.net. 3600 IN MX 10 mx1.mailprovider.example.
example.net. 3600 IN MX 20 mx2.mailprovider.example.Nižší číslo má přednost. Server zkusí nejprve mx1, a pokud ten neodpovídá, pak mx2. Poté zjistí IP adresu daného jména (A nebo AAAA záznam) a naváže spojení.
Dva zvláštní případy, se kterými se v praxi setkáte:
- Žádný MX záznam. Pak odesílatel zkusí A nebo AAAA záznam samotné domény (takzvaný „implicitní MX“ z RFC 5321, odstavec 5.1). Jde o pozůstatek z dřívější doby a nefunguje spolehlivě; každá doména, která přijímá poštu, by měla mít MX záznam.
- Null MX:
0 .To znamená: „tato doména nikdy nepřijímá poštu“ (RFC 7505). Doménuexample.commá takový záznam. Odesílatel okamžitě vzdá pokus a vrátí chybové hlášení, místo aby to dny zkoušel znovu.
Jak přesně fungují MX záznamy a priority, se dočtete v lekci 4.1 kurzu DNS.
Fronta: e-mailu to může chvíli trvat
E-mail nedorazí vždy během sekundy. Pokud přijímající server neodpoví, nebo řekne „zkuste to později“ (kód začínající na 4), zůstává e-mail ve frontě odesílacího serveru. Ten to zkusí znovu později, pokaždé s trochu delším odstupem. RFC 5321 (odstavec 4.5.4.1) doporučuje alespoň 30 minut mezi pokusy a vzdát se až po 4 až 5 dnech. Mnoho serverů po několika hodinách předem pošle upozornění („delayed“, ještě nedoručeno) a po několika dnech definitivní chybové hlášení.
To je silná stránka e-mailu: pokud je mailový server hodinu nedostupný, žádný e-mail se neztratí. Je to také důvod, proč e-mail někdy dorazí až o hodiny později. V modulu 6 uvidíte, jak takové zpoždění rozpoznat.
Envelope a hlavičky: dvě adresy
Stejně jako u pošty má e-mail dva druhy adres:
- Envelope. To jsou adresy, které servery mezi sebou používají v SMTP komunikaci:
MAIL FROM(odesílatel pro chybová hlášení, později viditelný jako Return-Path) aRCPT TO(příjemce). Servery doručují na základě envelope. - Hlavičky (headers). To je to, co je uvedeno přímo v dopise:
From:,To:,Cc:,Subject:,Date:. Tyto zobrazuje Váš poštovní program.
Většinou jsou shodné, ale ne vždy. Příjemce v BCC je sice uveden v envelope, ale ne v hlavičkách; proto ho ostatní nevidí. Služba pro newslettery jako envelope-odesílatele uvádí svou vlastní adresu, aby chybová hlášení chodila jí, zatímco v From: je uvedena Vaše adresa. A podvodník si do From: může napsat, co chce.
Proč na tom záleží: SPF kontroluje envelope-odesílatele, uživatel vidí From:. Proto existuje DMARC, který tyto dvě hodnoty propojuje (modul 4).
Kde to může selhat
S tímto přehledem si u každého problému můžete položit otázku: u které stanice to selhalo?
- Odeslání se nezdaří (chybové hlášení ihned ve Vašem programu): krok 1 nebo 2. Téměř vždy jde o nastavení: port, přihlášení, heslo (modul 2).
- Dostanete zpět bounce zprávu: krok 4 nebo 5. Přijímající server e-mail odmítl, nebo adresa neexistuje (modul 6).
- E-mail dorazí, ale do spamu: krok 5. Příjemce e-mailu nedůvěřuje (moduly 4 a 5).
- Příjemce nevidí nic a Vy nedostanete žádné chybové hlášení: e-mail možná ještě čeká ve frontě, nebo byl u příjemce tiše odfiltrován. Zde pomohou logy odesílacího serveru (modul 6).
- E-mail vůbec nedorazí na Vaši doménu: krok 3. MX záznamy nejsou v pořádku, například po stěhování (modul 8).
V praxi: jak to vypadá u hostingového balíčku
U hostingového balíčku WebOké vykonává všechny role jeden server na balíček: Váš poštovní program doručí e-mail na tento server (krok 1 a 2), server ho odešle ven (krok 3 a 4) a přijímá poštu pro Vaši doménu (krok 5). V DirectAdmin můžete pomocí E-mailového sledování u jednotlivých zpráv zjistit, zda byly doručeny. U jiných poskytovatelů to funguje podobně; tam se tato funkce nazývá například „sledování zpráv“ nebo „mail log“.
Shrnutí
- E-mail putuje z Vašeho poštovního programu (MUA) přes odesílací server (MSA/MTA) k přijímajícímu serveru (MTA/MDA) a odtud do poštovního programu příjemce.
- Odesílání z Vašeho programu probíhá přes SMTP-submission s přihlášením (587/465); servery mezi sebou komunikují přes SMTP na portu 25; vyzvednutí probíhá přes IMAP nebo POP3.
- Odesílající server zjišťuje MX záznamy domény za zavináčem. Null MX (
0 .) znamená: tato doména nepřijímá poštu. - E-mail, který se nepodaří doručit okamžitě, zůstává ve frontě a doručení se dny opakovaně zkouší.
- Envelope (Return-Path) a hlavičky (From) jsou dva různí odesílatelé. SPF se dívá na první, uživatel na druhý.
Kvíz
Úkol
Úkol Z1.1: Najít první mailový server. Vyhledejte MX záznamy domény gmail.com (nebo Vaší vlastní domény). Zjistěte, který server se zkouší jako první, s jeho číslem priority, a jednu IP adresu (IPv4 nebo IPv6) tohoto serveru. Program si stejné údaje živě vyžádá a zkontroluje je.
Další čtení
Kroky v těchto článcích platí pro panely WebOké; u jiných poskytovatelů to funguje podobně.
- Jak funguje odesílání e-mailů (SMTP)
- Příručka k DirectAdmin 8.7: IMAP nebo POP3: jaký je rozdíl?
- Bezplatný kurz DNS 4.1: MX záznamy a priorita
- RFC 5321 (SMTP), odstavec 5.1 (MX a implicitní MX) a 4.5.4.1 (opakování pokusu); RFC 7505 (null MX)