Modul 1 · 1.4
Slovenčina
Porty, šifrovanie a prihlasovanie
Modul 1: Ako funguje e-mail · Čas čítania: 10 minút
Cieľ lekcie: Po tejto lekcii dokážete pri každom mailovom porte povedať, na čo slúži, vysvetliť rozdiel medzi STARTTLS a priamym TLS a vysvetliť upozornenie na certifikát alebo zamietnuté prihlásenie.
Kľúčové pojmy: port 25, 587, 465, 993, 995, 143, 110, STARTTLS, priamy TLS (implicit TLS, RFC 8314), certifikát, názov servera, SMTP autentifikácia (SMTP AUTH), open relay, blokovanie portu 25, aplikačné heslo, OAuth
Port je ako dvere
Server má jednu IP adresu, ale veľa dverí. Každá služba počúva na svojom vlastnom porte, teda čísle. Váš webový prehliadač klope na port 443, váš poštový program na port 993, keď číta poštu, a na 587 alebo 465, keď ju odosiela. Ak zvolíte nesprávne dvere, nikto neodpovie, alebo odpovie niekto, kto hovorí iným jazykom. To spôsobuje nejasné chybové hlásenia ako "nedá sa pripojiť" alebo "server neodpovedá".
Prehľad mailových portov:
| Port | Na čo slúži | Šifrovanie | Prihlasovanie |
|---|---|---|---|
| 25 | Servery medzi sebou (doručovanie, lekcia 1.1 krok 4) | STARTTLS, ak to oba vedia | Nie |
| 587 | Odosielanie z poštového programu (submission, RFC 6409) | STARTTLS | Áno, povinné |
| 465 | Odosielanie z poštového programu (submissions) | Priamy TLS | Áno, povinné |
| 993 | Čítanie pošty cez IMAP | Priamy TLS | Áno |
| 995 | Vyzdvihnutie pošty cez POP3 | Priamy TLS | Áno |
| 143 | IMAP, starší | Prípadne STARTTLS | Áno |
| 110 | POP3, starší | Prípadne STARTTLS | Áno |
Prečo nie jednoducho port 25 na odosielanie?
Kedysi ste si v poštovom programe nastavili port 25. To je z dvoch dôvodov minulosťou.
Po prvé: na porte 25 prijíma mailový server poštu od kohokoľvek, pre svoje vlastné domény. Neprebieha žiadne prihlásenie. Server, ktorý na porte 25 preposiela aj poštu od kohokoľvek do iných domén, sa nazýva open relay a ten do pár hodín zneužijú spamári. Preto sa odosielanie vlastnej pošty do celého sveta stalo samostatnou službou: submission na porte 587 (a 465), kde sa vždy najprv prihlasujete.
Po druhé: mnohí poskytovatelia internetu blokujú odchádzajúcu prevádzku na port 25 z domácich pripojení. Infikovaný počítač v obývačke tak nemôže posielať spam priamo na mailové servery. Dôsledok pre vás: ak sa z poštového programu pokúsite odosielať cez port 25, doma to nemusí fungovať a v kancelárii áno, alebo naopak.
Zapamätajte si: poštové programy odosielajú cez 587 alebo 465, vždy s prihlásením. Port 25 je pre servery medzi sebou.
STARTTLS alebo priamy TLS?
Existujú dva spôsoby, ako zašifrovať mailové spojenie.
Priamy TLS (implicit TLS): spojenie je zašifrované od prvého bajtu, podobne ako webová stránka s https. Deje sa to na 465, 993 a 995.
STARTTLS: spojenie začína nešifrované. Server povie "viem šifrovať", klient odpovie STARTTLS a od toho momentu je všetko zašifrované. Deje sa to na 587 (a na 25, 143 a 110).
Z hľadiska bezpečnosti na tom príliš nezáleží, pokiaľ váš program STARTTLS vyžaduje ako povinný. Riziko STARTTLS spočíva v začiatku: niekto, kto je medzi vami a serverom, môže ponuku "viem šifrovať" odstrániť. Program, ktorý v takom prípade potichu pokračuje nezašifrovane, pošle vaše heslo cez linku čitateľne. Preto RFC 8314 (2018) odporúča pre poštové programy priamy TLS (465, 993, 995) pred STARTTLS. V praxi sú 587 s STARTTLS aj 465 s SSL/TLS v poriadku, pokiaľ v programe nastavíte šifrovanie na "povinné" a nie na "ak je dostupné".
Bežnou chybou je nesprávna kombinácia: port 587 s "SSL/TLS" alebo port 465 s "STARTTLS". Program potom očakáva niečo iné, než server robí, a spojenie sa zasekne alebo zlyhá. Zapamätajte si dvojice: 587 + STARTTLS a 465 + SSL/TLS. Programy niekedy nazývajú priamy TLS ako "SSL", "SSL/TLS" alebo "TLS"; STARTTLS sa tiež niekedy nazýva "TLS". Pozerajte sa teda na port.
Certifikát a názov servera
Pri každom zašifrovanom spojení server ukáže certifikát, ktorý dokazuje, že je tým, za koho sa vydáva. Váš poštový program kontroluje dve veci: či certifikát vydala dôveryhodná strana a či je ešte platný, a či sa v ňom nachádza názov, ktorý ste zadali ako server.
Práve to posledné sa najčastejšie pokazí. Zadáte mail.example.com, ale v certifikáte sa nachádza iba server12.hosting.example, dostanete hlásenie ako "Nemožno overiť identitu servera" alebo "Názov principal cieľa je nesprávny". Samotné spojenie je síce zašifrované, ale váš program si nemôže byť istý, že komunikuje so skutočným serverom.
Takéto hlásenie neodklikávajte preč. Riešením je názov servera, ktorý sa v certifikáte skutočne nachádza (pozrite lekciu 2.1). Pri zdieľanom serveri je to často názov samotného servera, ktorý vám uvedie váš poskytovateľ. Ďalšou známou príčinou je antivírusový program, ktorý "skenuje" zašifrovanú poštu a pritom vloží medzi komunikáciu svoj vlastný certifikát. V hlásení sa potom pri položke "vydal" objaví názov skeneru.
Prihlasovanie pri odosielaní
Na portoch 587 a 465 sa musíte prihlásiť skôr, než server bude ochotný poslať vašu poštu von. Volá sa to SMTP autentifikácia (SMTP AUTH). Vo vašom programe sa táto možnosť nazýva "odchádzajúci server vyžaduje overenie", "vyžaduje sa prihlásenie" alebo "autentifikácia: bežné heslo". Zvyčajne používate rovnaké používateľské meno a rovnaké heslo ako pre IMAP.
Ak je overenie vypnuté, alebo ak zostalo používateľské meno pri odchádzajúcom serveri prázdne, viete síce čítať poštu, ale nie ju odosielať. Server potom odpovie niečím ako 530 5.7.0 Authentication required alebo 554 5.7.1 Relay access denied. To je najčastejší dôvod pre "prijímanie funguje, odosielanie nie".
Druhý typ zamietnutia: 535 5.7.8 Authentication failed. Vtedy nesedí kombinácia používateľského mena a hesla. Pozor: po niekoľkých neúspešných pokusoch mnohé servery zablokujú IP adresu, z ktorej tieto pokusy prichádzajú, ako ochranu proti skúšaniu hesiel. Starý telefón so starým heslom tak môže zablokovať celú vašu kanceláriu.
Aplikačné heslá a OAuth
U veľkých poskytovateľov ako Google a Microsoft funguje prihlasovanie iba s obyčajným heslom v samostatnom poštovom programe čoraz menej. Používajú OAuth: váš program vás pošle na prihlasovaciu stránku poskytovateľa, tam sa prihlásite (prípadne s dvojfaktorovým overením) a program namiesto hesla dostane kľúč. Programy, ktoré to nevedia, niekedy dostanú aplikačné heslo: samostatné, dlhé heslo platné iba pre daný konkrétny program, ktoré môžete samostatne odvolať.
Pri bežnej poštovej schránke u hostingovej spoločnosti sa zvyčajne prihlasujete heslom samotnej schránky. To robí silné a jedinečné heslo mimoriadne dôležitým (lekcia 3.4).
V praxi: nastavenia poštovej schránky
Pri schránke od WebOké sú nastavenia: IMAP 993 s SSL/TLS, POP3 995 s SSL/TLS, odosielanie 587 s STARTTLS alebo 465 s SSL/TLS, overenie zapnuté s vaším celým e-mailovým adresou a heslom schránky. U iných poskytovateľov to funguje podobne: porty sú takmer všade rovnaké, líši sa iba názov servera. Ktorý názov servera zvoliť, sa dozviete v lekcii 2.1.
Zhrnutie
- Poštové programy odosielajú cez 587 (STARTTLS) alebo 465 (priamy TLS), vždy s prihlásením. Port 25 je pre servery medzi sebou a doma sa často blokuje.
- Čítanie prebieha cez 993 (IMAP) alebo 995 (POP3), oba s priamym TLS.
- Kombinujte správne: 587 + STARTTLS, 465 + SSL/TLS. Nastavte šifrovanie ako povinné.
- Upozornenie na certifikát väčšinou znamená: názov servera, ktorý ste zadali, sa nenachádza v certifikáte. Odklikanie nie je riešenie.
- "Čítanie funguje, odosielanie nie" je takmer vždy: overenie pre odchádzajúci server je vypnuté alebo prázdne.
Kvíz
Úloha
Úloha Z1.4: Porty a certifikát mailového servera. Zadajte názov prichádzajúceho a odchádzajúceho servera, ktorý používate pre svoju vlastnú poštovú schránku (ak vlastnú schránku nemáte, použite imap.gmail.com a smtp.gmail.com). Pri porte 993 (prichádzajúci) a portoch 465 a 587 (odchádzajúce) zvoľte, čo očakávate: priamy TLS, STARTTLS alebo nedostupné, a doplňte, či si myslíte, že názov je v certifikáte. Program sa sám pripojí na tieto tri porty a výsledok porovná s vašimi odpoveďami.
Ďalšie čítanie
Kroky v týchto článkoch platia pre panely WebOké; u iných poskytovateľov to funguje podobne.
- Návod na DirectAdmin 8.1: Všetky nastavenia na jednom mieste: servery, porty a zabezpečenie
- Návod na DirectAdmin 8.8: Odosielanie alebo prijímanie pošty nefunguje: ako to vyriešiť
- Chybové hlásenie certifikátu pri sťahovaní pošty
- Nemôžem odosielať e-maily (prijímanie funguje)
- RFC 8314 (priamy TLS pre poštové programy), RFC 6409 (submission), RFC 3207 (STARTTLS), RFC 4954 (SMTP AUTH)
