Prievadai, šifravimas ir prisijungimas

1 modulis: Kaip veikia el. paštas · Skaitymo trukmė: 10 min.

Tikslas: Po šios pamokos galėsite paaiškinti, kam skirtas kiekvienas pašto prievadas, nurodyti skirtumą tarp STARTTLS ir tiesioginio TLS, ir paaiškinti sertifikato pranešimą arba atmestą prisijungimą.

Pagrindinės sąvokos: prievadas 25, 587, 465, 993, 995, 143, 110, STARTTLS, tiesioginis TLS (implicit TLS, RFC 8314), sertifikatas, serverio vardas, SMTP autentifikacija (SMTP AUTH), atviras retransliatorius (open relay), prievado 25 blokavimas, programėlės slaptažodis, OAuth

Prievadas yra durys

Serveris turi vieną IP adresą, bet daug durų. Kiekviena paslauga klausosi savo prievado, tam tikro numerio. Jūsų naršyklė beldžiasi į prievadą 443, pašto programa į prievadą 993, kad perskaitytų paštą, ir į 587 arba 465, kad jį išsiųstų. Pasirinkus netinkamas duris, niekas neatsiliepia arba atsiliepia kažkas, kuris kalba kita kalba. Dėl to atsiranda neaiškūs klaidų pranešimai, pavyzdžiui, „nepavyko prisijungti“ arba „serveris neatsako“.

Pašto prievadai sąraše:

Kodėl ne paprasčiausiai prievadas 25 siuntimui?

Anksčiau pašto programoje būdavo nustatomas prievadas 25. Tai jau praeitis dėl dviejų priežasčių.

Pirma: per prievadą 25 pašto serveris priima paštą iš visų, skirtą savo domenams. Čia prisijungti nereikia. Serveris, kuris per prievadą 25 taip pat persiunčia bet kieno paštą į kitus domenus, vadinamas atviru retransliatoriumi (open relay), ir per kelias valandas juo pasinaudoja šlamšto siuntėjai. Todėl savo pašto siuntimas visam pasauliui tapo atskira paslauga: submission per prievadą 587 (ir 465), kur visada pirmiausia reikia prisijungti.

Antra: daugelis interneto paslaugų teikėjų blokuoja išeinantį srautą į prievadą 25 iš namų prisijungimų. Taip užkrėstas kompiuteris svetainėje negali tiesiogiai siųsti šlamšto pašto serveriams. Jums tai reiškia: jei bandote siųsti iš pašto programos per prievadą 25, namuose gali neveikti, o biure veiks, arba atvirkščiai.

Atminkite: pašto programos siunčia per 587 arba 465, visada prisijungus. Prievadas 25 skirtas serveriams tarpusavyje.

STARTTLS ar tiesioginis TLS?

Yra du būdai šifruoti pašto ryšį.

Tiesioginis TLS (implicit TLS): ryšys šifruojamas nuo pirmojo baito, kaip ir svetainė su https. Tai vyksta per 465, 993 ir 995.

STARTTLS: ryšys prasideda nešifruotas. Serveris praneša „galiu šifruoti“, klientas atsako STARTTLS, ir nuo to momento viskas šifruojama. Tai vyksta per 587 (bei per 25, 143 ir 110).

Saugumui tai mažai ką keičia, jei Jūsų programa STARTTLS laiko privalomu. STARTTLS rizika slypi pradžioje: kažkas, esantis tarp Jūsų ir serverio, gali pašalinti pasiūlymą „galiu šifruoti“. Programa, kuri tuomet tyliai tęsia nešifruotą ryšį, siunčia Jūsų slaptažodį linija skaitomu pavidalu. Todėl RFC 8314 (2018) rekomenduoja pašto programoms tiesioginį TLS (465, 993, 995) vietoje STARTTLS. Praktikoje ir 587 su STARTTLS, ir 465 su SSL/TLS yra geri sprendimai, jei Jūsų programoje šifravimas nustatytas kaip „privalomas“, o ne „jei įmanoma“.

Dažna klaida yra netinkamas derinys: prievadas 587 su „SSL/TLS“, arba prievadas 465 su „STARTTLS“. Tuomet programa tikisi kitokio elgesio nei vykdo serveris, ir ryšys užstringa arba nepavyksta. Atminkite poras: 587 + STARTTLS ir 465 + SSL/TLS. Programos kartais tiesioginį TLS vadina „SSL“, „SSL/TLS“ arba „TLS“; STARTTLS kartais taip pat vadinamas „TLS“. Todėl žiūrėkite į prievadą.

Sertifikatas ir serverio vardas

Kiekvieno šifruoto ryšio metu serveris pateikia sertifikatą, kuris įrodo, kad jis yra tas, kuo sakosi esąs. Jūsų pašto programa patikrina dvi dalykus: ar sertifikatą išdavė patikima institucija ir ar jis dar galioja, bei ar jame nurodytas vardas, kurį Jūs įvedėte kaip serverį.

Pastaroji dalis dažniausiai ir sukelia problemų. Jei įvedate mail.example.com, bet sertifikate nurodytas tik server12.hosting.example, gausite pranešimą, pavyzdžiui, „Nepavyko patikrinti serverio tapatybės“ arba „Tikslo pagrindinis vardas neteisingas“. Pats ryšys tuomet yra šifruotas, tačiau Jūsų programa negali būti tikra, kad bendrauja su tikruoju serveriu.

Tokio pranešimo neuždarykite tiesiog ignoruodami. Sprendimas yra naudoti serverio vardą, kuris yra nurodytas sertifikate (žr. 2.1 pamoką). Bendrame serveryje tai dažnai yra paties serverio vardas, kurį nurodo Jūsų paslaugų teikėjas. Dar viena žinoma priežastis: antivirusinė programa, kuri „tikrina“ šifruotą paštą ir tam įterpia savo paties sertifikatą. Tokiu atveju pranešime ties „išdavė“ bus nurodytas antivirusinės programos pavadinimas.

Prisijungimas siunčiant

Per prievadus 587 ir 465 reikia prisijungti, kol serveris sutiks išsiųsti Jūsų paštą į išorę. Tai vadinama SMTP autentifikacija (SMTP AUTH). Jūsų programoje ši parinktis gali vadintis „išeinantis serveris reikalauja tapatybės patvirtinimo“, „reikalinga autentifikacija“ arba „autentifikacija: paprastas slaptažodis“. Dažniausiai naudojamas tas pats vartotojo vardas ir slaptažodis, kaip ir IMAP.

Jei autentifikacija išjungta arba vartotojo vardas prie išeinančio serverio liko tuščias, paštą galėsite skaityti, bet ne siųsti. Tuomet serveris atsakys kažkuo panašiu į 530 5.7.0 Authentication required arba 554 5.7.1 Relay access denied. Tai dažniausia priežastis, kodėl „gavimas veikia, siuntimas ne“.

Antras atmetimo tipas: 535 5.7.8 Authentication failed. Tuomet vartotojo vardo ir slaptažodžio derinys neteisingas. Atkreipkite dėmesį: po kelių nesėkmingų bandymų daugelis serverių blokuoja IP adresą, iš kurio tie bandymai daromi, siekdami apsisaugoti nuo slaptažodžių spėjimo. Senas telefonas su pasenusiu slaptažodžiu gali taip užblokuoti visą Jūsų biurą.

Programėlių slaptažodžiai ir OAuth

Didesni teikėjai, tokie kaip Google ir Microsoft, vis rečiau leidžia prisijungti vien tik su įprastu slaptažodžiu atskiroje pašto programoje. Jie naudoja OAuth: Jūsų programa nukreipia Jus į teikėjo prisijungimo puslapį, ten prisijungiate (prireikus su dviejų veiksnių patvirtinimu), o programa gauna raktą vietoje slaptažodžio. Programos, kurios to negali, kartais gauna programėlės slaptažodį: atskirą, ilgą slaptažodį, galiojantį tik tai vienai programai, ir kurį galima atskirai atšaukti.

Įprastoje pašto dėžutėje pas prieglobos paslaugų teikėją dažniausiai prisijungiama su pačios pašto dėžutės slaptažodžiu. Todėl ypač svarbu turėti stiprų ir unikalų slaptažodį (3.4 pamoka).

Praktikoje: pašto dėžutės nustatymai

WebOké pašto dėžutės nustatymai yra tokie: IMAP 993 su SSL/TLS, POP3 995 su SSL/TLS, siuntimas per 587 su STARTTLS arba 465 su SSL/TLS, autentifikacija įjungta su visu Jūsų el. pašto adresu ir pašto dėžutės slaptažodžiu. Pas kitus teikėjus veikimas panašus: prievadai beveik visur tie patys, skiriasi tik serverio vardas. Kaip pasirinkti tinkamą serverio vardą, sužinosite 2.1 pamokoje.

Santrauka

• Pašto programos siunčia per 587 (STARTTLS) arba 465 (tiesioginis TLS), visada prisijungus. Prievadas 25 skirtas serveriams tarpusavyje ir namuose dažnai blokuojamas.
• Skaitymas vyksta per 993 (IMAP) arba 995 (POP3), abu su tiesioginiu TLS.
• Derinkite teisingai: 587 + STARTTLS, 465 + SSL/TLS. Šifravimą nustatykite kaip privalomą.
• Sertifikato pranešimas dažniausiai reiškia: Jūsų įvestas serverio vardas nesutampa su sertifikate nurodytu vardu. Pranešimo ignoravimas nėra sprendimas.
• „Skaitymas veikia, siuntimas ne“ beveik visada reiškia: autentifikacija išeinančiam serveriui yra išjungta arba neįvesta.

Testas

Užduotis

Užduotis Z1.4: Pašto serverio prievadai ir sertifikatas. Įveskite gaunamojo ir siunčiamojo serverio vardus, kuriuos naudojate savo pašto dėžutei (jei neturite savos pašto dėžutės, naudokite imap.gmail.com ir smtp.gmail.com). Pasirinkite prievadui 993 (gaunamasis) ir prievadams 465 bei 587 (siunčiamasis), ko tikitės: tiesioginio TLS, STARTTLS ar nepasiekiamo ryšio, ir nurodykite, ar manote, kad vardas yra sertifikate. Programa pati prisijungs prie trijų prievadų ir pateiks rezultatą šalia Jūsų atsakymų.

Platesniam skaitymui

Šiuose straipsniuose aprašyti veiksmai galioja WebOké valdymo skydeliams; pas kitus teikėjus veikimas panašus.

• DirectAdmin vadovas 8.1: Visi nustatymai vienoje vietoje: serveriai, prievadai ir saugumas
• DirectAdmin vadovas 8.8: Siųsti arba gauti nepavyksta: kaip tai išspręsti
• Sertifikato klaidos pranešimas gaunant laiškus
• Negaliu išsiųsti el. laiško (gavimas veikia)
• RFC 8314 (tiesioginis TLS pašto programoms), RFC 6409 (submission), RFC 3207 (STARTTLS), RFC 4954 (SMTP AUTH)