Modul 1 · 1.4
Porty, šifrování a přihlašování
Modul 1: Jak funguje e-mail · Doba čtení: 10 minut
Cíl lekce: Po této lekci dokážete u každého mailového portu říct, k čemu slouží, vysvětlit rozdíl mezi STARTTLS a přímým TLS a vysvětlit hlášení o certifikátu nebo odmítnuté přihlášení.
Klíčové pojmy: port 25, 587, 465, 993, 995, 143, 110, STARTTLS, přímé TLS (implicit TLS, RFC 8314), certifikát, název serveru, SMTP autentizace (SMTP AUTH), open relay, blokování portu 25, aplikační heslo, OAuth
Port je dveře
Server má jednu IP adresu, ale mnoho dveří. Každá služba naslouchá na svém vlastním portu, tedy čísle. Váš webový prohlížeč klepe na port 443, váš poštovní program na port 993, když čte poštu, a na 587 nebo 465, když ji odesílá. Pokud zvolíte špatné dveře, nikdo neodpoví, nebo odpoví někdo, kdo mluví jiným jazykem. To způsobuje nejasná chybová hlášení typu "nelze navázat spojení" nebo "server neodpovídá".
Přehled mailových portů:
| Port | K čemu slouží | Šifrování | Přihlašování |
|---|---|---|---|
| 25 | Servery mezi sebou (doručování, lekce 1.1 krok 4) | STARTTLS, pokud to umí obě strany | Ne |
| 587 | Odesílání z Vašeho poštovního programu (submission, RFC 6409) | STARTTLS | Ano, povinné |
| 465 | Odesílání z Vašeho poštovního programu (submissions) | Přímé TLS | Ano, povinné |
| 993 | Čtení pošty přes IMAP | Přímé TLS | Ano |
| 995 | Stahování pošty přes POP3 | Přímé TLS | Ano |
| 143 | IMAP, starší | Případně STARTTLS | Ano |
| 110 | POP3, starší | Případně STARTTLS | Ano |
Proč ne jednoduše port 25 pro odesílání?
Dříve jste si v poštovním programu nastavili port 25. To je už minulost, a to ze dvou důvodů.
Za prvé: na portu 25 mailový server přijímá poštu od kohokoli, pro své vlastní domény. Nepřihlašuje se. Server, který na portu 25 navíc přeposílá poštu od kohokoli i do jiných domén, se nazývá open relay, a ten zneužijí spammeři během pár hodin. Proto se odesílání vlastní pošty do celého světa stalo samostatnou službou: submission na portu 587 (a 465), kde se vždy nejprve přihlašujete.
Za druhé: mnoho poskytovatelů internetu blokuje odchozí provoz na port 25 z domácích připojení. Infikovaný počítač v obývacím pokoji pak nemůže posílat spam přímo na mailové servery. Důsledek pro Vás: pokud se z poštovního programu pokusíte odesílat přes port 25, může Vám to doma nefungovat a v kanceláři ano, nebo naopak.
Zapamatujte si: poštovní programy odesílají přes 587 nebo 465, vždy s přihlášením. Port 25 je pro servery mezi sebou.
STARTTLS, nebo přímé TLS?
Existují dva způsoby, jak zašifrovat mailové spojení.
Přímé TLS (implicit TLS): spojení je šifrované už od prvního bajtu, podobně jako web s https. To se děje na portech 465, 993 a 995.
STARTTLS: spojení začíná nešifrovaně. Server řekne "umím šifrovat", klient odpoví STARTTLS, a od toho okamžiku je vše šifrované. To se děje na portu 587 (a na 25, 143 a 110).
Pro bezpečnost na tom příliš nezáleží, pokud Váš program STARTTLS vyžaduje jako povinné. Riziko STARTTLS spočívá v začátku: někdo, kdo je mezi Vámi a serverem, může nabídku "umím šifrovat" odstranit. Program, který pak tiše pokračuje nešifrovaně, pošle Vaše heslo po lince čitelně. Proto RFC 8314 (2018) doporučuje pro poštovní programy přímé TLS (465, 993, 995) před STARTTLS. V praxi jsou 587 se STARTTLS i 465 se SSL/TLS v pořádku, pokud máte v programu šifrování nastavené na "povinné" a ne na "pokud je dostupné".
Častou chybou je nesprávná kombinace: port 587 s "SSL/TLS", nebo port 465 se "STARTTLS". Program pak očekává něco jiného, než server dělá, a spojení se zasekne nebo selže. Zapamatujte si dvojice: 587 + STARTTLS a 465 + SSL/TLS. Programy někdy nazývají přímé TLS jako "SSL", "SSL/TLS" nebo "TLS"; STARTTLS se někdy také nazývá "TLS". Dívejte se tedy na port.
Certifikát a název serveru
Při každém šifrovaném spojení server ukáže certifikát, který dokazuje, že je tím, za koho se vydává. Váš poštovní program kontroluje dvě věci: zda certifikát vydala důvěryhodná strana a zda je stále platný, a zda v něm je název, který jste zadali jako server.
Právě to poslední se nejčastěji pokazí. Pokud zadáte mail.example.com, ale v certifikátu je pouze server12.hosting.example, zobrazí se hlášení jako "Nelze ověřit identitu serveru" nebo "Jméno hlavního subjektu cíle je nesprávné". Samotné spojení je přitom šifrované, ale program si nemůže být jistý, že komunikuje se skutečným serverem.
Takové hlášení neodklikávejte. Řešením je použít název serveru, který v certifikátu skutečně je (viz lekce 2.1). U sdíleného serveru to bývá přímo název serveru, který uvádí Váš poskytovatel. Další známá příčina: antivirový program, který šifrovanou poštu "skenuje" a vkládá do spojení vlastní certifikát. V hlášení je pak u "vydáno kým" uveden název skeneru.
Přihlašování při odesílání
Na portech 587 a 465 se musíte přihlásit dříve, než server bude ochoten odeslat Vaši poštu ven. To se nazývá SMTP autentizace (SMTP AUTH). Ve Vašem programu se tato volba nazývá "odchozí server vyžaduje ověření", "vyžadovat přihlášení" nebo "autentizace: běžné heslo". Obvykle používáte stejné uživatelské jméno a heslo jako pro IMAP.
Pokud je ověřování vypnuté, nebo pokud zůstalo uživatelské jméno u odchozího serveru prázdné, můžete poštu číst, ale ne odesílat. Server pak odpoví něčím jako 530 5.7.0 Authentication required nebo 554 5.7.1 Relay access denied. To je nejčastější důvod situace "přijímání funguje, odesílání ne".
Druhý typ odmítnutí: 535 5.7.8 Authentication failed. Pak nesedí kombinace uživatelského jména a hesla. Pozor: po několika neúspěšných pokusech řada serverů blokuje IP adresu, ze které tyto pokusy přicházejí, jako ochranu proti hádání hesel. Starý telefon se starým heslem tak může způsobit zablokování celé Vaší kanceláře.
Aplikační hesla a OAuth
U velkých poskytovatelů, jako jsou Google a Microsoft, funguje přihlašování pomocí pouhého běžného hesla v samostatném poštovním programu čím dál méně. Používají OAuth: program Vás přesměruje na přihlašovací stránku poskytovatele, tam se přihlásíte (případně s dvoufázovým ověřením) a program místo hesla získá klíč. Programy, které to neumí, dostávají někdy aplikační heslo: samostatné, dlouhé heslo, které platí pouze pro daný program a které lze samostatně zrušit.
U běžné schránky u hostingové společnosti se obvykle přihlašujete heslem samotné schránky. To činí silné a jedinečné heslo ještě důležitějším (lekce 3.4).
V praxi: nastavení schránky
U schránky od WebOké jsou nastavení následující: IMAP 993 se SSL/TLS, POP3 995 se SSL/TLS, odesílání 587 se STARTTLS nebo 465 se SSL/TLS, ověřování zapnuté s Vaší kompletní e-mailovou adresou a heslem schránky. U jiných poskytovatelů to funguje obdobně: porty jsou téměř všude stejné, liší se pouze název serveru. Jaký název serveru zvolit, zjistíte v lekci 2.1.
Shrnutí
- Poštovní programy odesílají přes 587 (STARTTLS) nebo 465 (přímé TLS), vždy s přihlášením. Port 25 je pro servery mezi sebou a doma bývá často blokovaný.
- Čtení probíhá přes 993 (IMAP) nebo 995 (POP3), oba s přímým TLS.
- Správně kombinujte: 587 + STARTTLS, 465 + SSL/TLS. Nastavte šifrování jako povinné.
- Hlášení o certifikátu obvykle znamená: název serveru, který jste zadali, není v certifikátu uveden. Odklepnutí problém nevyřeší.
- "Čtení funguje, odesílání ne" znamená téměř vždy: ověřování pro odchozí server je vypnuté nebo prázdné.
Kvíz
Úkol
Úkol Z1.4: Porty a certifikát mailového serveru. Zadejte název příchozího a odchozího serveru, který používáte pro svou vlastní schránku (pokud vlastní schránku nemáte, použijte imap.gmail.com a smtp.gmail.com). U portu 993 (příchozí) a portů 465 a 587 (odchozí) zvolte, co očekáváte: přímé TLS, STARTTLS nebo nedostupné, a uveďte, zda si myslíte, že daný název je uveden v certifikátu. Program se sám připojí ke všem třem portům a výsledek postaví vedle Vašich odpovědí.
Další čtení
Kroky v těchto článcích platí pro panely WebOké; u jiných poskytovatelů to funguje obdobně.
- Příručka k DirectAdmin 8.1: Všechna nastavení přehledně: servery, porty a zabezpečení
- Příručka k DirectAdmin 8.8: Odesílání nebo přijímání e-mailů nefunguje: jak to vyřešit
- Chybové hlášení o certifikátu při stahování pošty
- Nemohu odesílat e-maily (přijímání funguje)
- RFC 8314 (přímé TLS pro poštovní programy), RFC 6409 (submission), RFC 3207 (STARTTLS), RFC 4954 (SMTP AUTH)
