Portok, titkosítás és bejelentkezés

Modul 1: Hogyan működik az e-mail · Olvasási idő: 10 perc

Tanulási cél: E lecke után Ön meg tudja mondani, hogy az egyes levelezőportok mire valók, el tudja magyarázni a STARTTLS és a közvetlen TLS közötti különbséget, és meg tudja magyarázni egy tanúsítványüzenet vagy egy elutasított bejelentkezés okát.

Kulcsfogalmak: 25, 587, 465, 993, 995, 143, 110 port, STARTTLS, közvetlen TLS (implicit TLS, RFC 8314), tanúsítvány, szervernév, SMTP-hitelesítés (SMTP AUTH), nyitott relay, a 25-ös port blokkolása, alkalmazásjelszó, OAuth

A port egy ajtó

Egy szervernek egy IP-címe van, de sok ajtaja. Minden szolgáltatás a saját portján figyel, egy számon. Az Ön böngészője a 443-as porton kopog, a levelezőprogramja a 993-as porton a levelek olvasásához, az 587-es vagy 465-ös porton pedig a küldéshez. Ha rossz ajtót választ, senki nem válaszol, vagy valaki, aki más nyelvet beszél. Ez olyan homályos hibaüzeneteket eredményez, mint „nem sikerül kapcsolódni” vagy „a szerver nem válaszol”.

A levelezőportok áttekintése:

Miért nem egyszerűen a 25-ös port a küldéshez?

Korábban a levelezőprogramban a 25-ös portot állították be. Ez két okból a múlté.

Először is: a 25-ös porton egy levelezőszerver bárkitől fogad leveleket, a saját domainjei számára. Nincs bejelentkezés. Azt a szervert, amely a 25-ös porton bárkitől más domainekre is továbbít leveleket, nyitott relaynek (open relay) nevezik, és azt néhány órán belül kihasználják a spammerek. Ezért vált a saját levelek egész világra történő küldése külön szolgáltatássá: ez a submission, az 587-es (és 465-ös) porton, ahol mindig előbb be kell jelentkezni.

Másodszor: sok internetszolgáltató blokkolja az otthoni csatlakozásokról a 25-ös port felé irányuló kimenő forgalmat. Így egy otthoni, fertőzött számítógép nem tud közvetlenül spamet küldeni a levelezőszervereknek. Ennek következménye Önre nézve: ha a levelezőprogramjából a 25-ös porton próbál küldeni, otthon lehet, hogy nem működik, az irodában viszont igen, vagy fordítva.

Jegyezze meg: a levelezőprogramok az 587-es vagy 465-ös porton küldenek, bejelentkezéssel. A 25-ös port a szerverek közötti kommunikációra való.

STARTTLS vagy közvetlen TLS?

Egy levelezési kapcsolat titkosítására két mód van.

Közvetlen TLS (implicit TLS): a kapcsolat már az első bájttól titkosított, ugyanúgy, mint egy https-es weboldal esetén. Ez történik a 465-ös, 993-as és 995-ös porton.

STARTTLS: a kapcsolat titkosítatlanul kezdődik. A szerver közli: „tudok titkosítani”, a kliens a STARTTLS paranccsal válaszol, és ettől a pillanattól kezdve minden titkosított. Ez történik az 587-es (valamint a 25-ös, 143-as és 110-es) porton.

A biztonság szempontjából alig számít a különbség, amíg a programja a STARTTLS-t kötelezővé teszi. A STARTTLS kockázata az elején rejlik: aki Ön és a szerver között áll, eltüntetheti a „tudok titkosítani” ajánlatot. Egy program, amely ezután csendben titkosítatlanul folytatja, az Ön jelszavát olvasható formában küldi át a vonalon. Ezért az RFC 8314 (2018) a levelezőprogramoknak a közvetlen TLS-t (465, 993, 995) ajánlja a STARTTLS helyett. A gyakorlatban az 587-es port STARTTLS-sel és a 465-ös port SSL/TLS-sel egyaránt megfelelő, ha a titkosítást a programjában „kötelezőre” állítja, és nem „ha elérhető” módra.

Gyakori hiba a rossz kombináció: az 587-es port „SSL/TLS”-sel, vagy a 465-ös port „STARTTLS”-sel. Ilyenkor a program mást vár, mint amit a szerver tesz, és a kapcsolat lefagy vagy meghiúsul. Jegyezze meg a párokat: 587 + STARTTLS és 465 + SSL/TLS. A programok a közvetlen TLS-t néha „SSL”-nek, „SSL/TLS”-nek vagy „TLS”-nek nevezik; a STARTTLS-t is hívják néha „TLS”-nek. Ezért a portra érdemes figyelni.

A tanúsítvány és a szervernév

Minden titkosított kapcsolat esetén a szerver megmutat egy tanúsítványt, amely bizonyítja, hogy valóban az, akinek mondja magát. A levelezőprogramja két dolgot ellenőriz: a tanúsítványt megbízható fél adta-e ki, és még érvényes-e, valamint szerepel-e benne az a név, amelyet Ön szerverként megadott.

Leggyakrabban ez utóbbi hibázik el. Ha Ön a mail.example.com nevet adja meg, de a tanúsítványban csak a server12.hosting.example szerepel, akkor olyan üzenetet kap, mint „Nem sikerült ellenőrizni a szerver személyazonosságát” vagy „A cél principal neve helytelen”. Maga a kapcsolat ugyan titkosított, de a programja nem tudja biztosan, hogy valóban az igazi szerverrel beszél.

Egy ilyen üzenetet ne kattintson el. A megoldás egy olyan szervernév megadása, amely valóban szerepel a tanúsítványban (lásd a 2.1 leckét). Osztott szerver esetén ez gyakran a szerver saját neve, amelyet a szolgáltatója ad meg. Egy másik ismert ok: egy vírusirtó, amely „megvizsgálja” a titkosított leveleket, és ehhez beilleszti a saját tanúsítványát. Ilyenkor az üzenetben a „kiállító” mezőnél a vírusirtó neve szerepel.

Bejelentkezés küldéskor

Az 587-es és 465-ös porton be kell jelentkeznie, mielőtt a szerver kiküldené a levelét. Ezt SMTP-hitelesítésnek (SMTP AUTH) nevezik. A programjában ez az opció így jelenhet meg: „a kimenő szerver hitelesítést igényel”, „bejelentkezés szükséges” vagy „hitelesítés: normál jelszó”. Általában ugyanazt a felhasználónevet és jelszót használja, mint az IMAP-hoz.

Ha a hitelesítés ki van kapcsolva, vagy a kimenő szerverhez tartozó felhasználónév üresen maradt, akkor olvasni tud leveleket, de küldeni nem. A szerver ilyenkor olyasmivel válaszol, mint 530 5.7.0 Authentication required vagy 554 5.7.1 Relay access denied. Ez a leggyakoribb oka annak, hogy „a fogadás működik, a küldés nem”.

Egy másik elutasítástípus: 535 5.7.8 Authentication failed. Ekkor a felhasználónév és jelszó kombinációja nem megfelelő. Figyeljen arra, hogy több sikertelen próbálkozás után sok szerver blokkolja azt az IP-címet, ahonnan a próbálkozások érkeznek, a jelszótalálgatás ellen. Egy régi telefon egy elavult jelszóval így az egész irodáját blokkolás alá vonhatja.

Alkalmazásjelszavak és OAuth

A nagy szolgáltatóknál, mint a Google és a Microsoft, egyre ritkábban működik a bejelentkezés önálló levelezőprogramban csupán a szokásos jelszóval. Ők az OAuth-ot használják: a programja elirányítja Önt a szolgáltató bejelentkezési oldalára, ott bejelentkezik (esetleg kétlépcsős azonosítással), és a program jelszó helyett egy kulcsot kap. Azok a programok, amelyek ezt nem támogatják, néha alkalmazásjelszót kapnak: egy külön, hosszú jelszót, amely csak az adott programra érvényes, és önállóan visszavonható.

Egy szokásos, tárhelyszolgáltatónál lévő postafiók esetén általában magának a postafióknak a jelszavával jelentkezik be. Ez teszi még fontosabbá az erős és egyedi jelszó használatát (3.4 lecke).

A gyakorlatban: egy postafiók beállításai

A WebOké egy postafiókja esetén a beállítások a következők: IMAP 993 SSL/TLS-sel, POP3 995 SSL/TLS-sel, küldés 587 STARTTLS-sel vagy 465 SSL/TLS-sel, hitelesítés bekapcsolva, a teljes e-mail címmel és a postafiók jelszavával. Más szolgáltatóknál hasonlóan működik: a portok szinte mindenhol ugyanazok, csak a szervernév különbözik. Hogy melyik szervernevet válassza, azt a 2.1 leckében találja.

Összefoglalás

• A levelezőprogramok az 587-es (STARTTLS) vagy 465-ös (közvetlen TLS) porton küldenek, mindig bejelentkezéssel. A 25-ös port a szerverek közötti kommunikációra való, és otthon gyakran blokkolva van.
• Az olvasás a 993-as (IMAP) vagy 995-ös (POP3) porton történik, mindkettő közvetlen TLS-sel.
• Jól párosítsa őket: 587 + STARTTLS, 465 + SSL/TLS. Állítsa a titkosítást kötelezőre.
• Egy tanúsítványüzenet általában azt jelenti: a megadott szervernév nincs benne a tanúsítványban. Az elkattintás nem megoldás.
• „Az olvasás működik, a küldés nem” szinte mindig azt jelenti: a kimenő szerver hitelesítése ki van kapcsolva vagy üresen maradt.

Kvíz

Feladat

Z1.4 feladat: Egy levelezőszerver portjai és tanúsítványa. Adja meg a bejövő és a kimenő szervernevet, amelyet a saját postafiókjához használ (ha nincs saját postafiókja, használja az imap.gmail.com és smtp.gmail.com neveket). A 993-as (bejövő) és a 465-ös, illetve 587-es (kimenő) portokhoz válassza ki, mit vár: közvetlen TLS-t, STARTTLS-t vagy el nem érhetőt, és adja meg, hogy ön szerint a név szerepel-e a tanúsítványban. A program maga kapcsolódik a három porthoz, és az eredményt az Ön válaszai mellé teszi.

További olvasnivaló

Az ezekben a cikkekben leírt lépések a WebOké paneljeire vonatkoznak; más szolgáltatóknál hasonlóan működik.

• DirectAdmin útmutató 8.1: Minden beállítás egy helyen: szerverek, portok és biztonság
• DirectAdmin útmutató 8.8: Küldés vagy fogadás nem sikerül: így oldja meg
• Tanúsítványhiba az e-mailek letöltésekor
• Nem tudok e-mailt küldeni (a fogadás működik)
• RFC 8314 (közvetlen TLS levelezőprogramokhoz), RFC 6409 (submission), RFC 3207 (STARTTLS), RFC 4954 (SMTP AUTH)