Porti, šifrēšana un pieslēgšanās

1. modulis: Kā darbojas e-pasts · Lasīšanas laiks: 10 minūtes

Mērķis: Pēc šīs nodarbības Jūs varēsiet par katru pasta portu pateikt, kādam nolūkam tas kalpo, izskaidrot atšķirību starp STARTTLS un tiešo TLS, kā arī paskaidrot sertifikāta brīdinājumu vai noraidītu pieslēgšanos.

Pamatjēdzieni: ports 25, 587, 465, 993, 995, 143, 110, STARTTLS, tiešais TLS (implicit TLS, RFC 8314), sertifikāts, servera nosaukums, SMTP autentifikācija (SMTP AUTH), atvērts relejs (open relay), porta 25 bloķēšana, lietotnes parole, OAuth

Ports ir durvis

Serverim ir viena IP adrese, taču daudzas durvis. Katrs pakalpojums klausās savā portā, kas ir numurs. Jūsu tīmekļa pārlūks klauvē pie porta 443, Jūsu pasta programma pie porta 993, lai lasītu pastu, un pie 587 vai 465, lai to nosūtītu. Ja izvēlaties nepareizās durvis, neviens neatbild, vai arī atbild kāds, kas runā citā valodā. Tas rada neskaidrus kļūdu paziņojumus, piemēram, "nevar izveidot savienojumu" vai "serveris neatbild".

Pasta porti pārskatā:

Kāpēc gan neizmantot parasti portu 25 nosūtīšanai?

Agrāk pasta programmā iestatīja portu 25. Tas ir pagātne divu iemeslu dēļ.

Pirmkārt, portā 25 pasta serveris pieņem pastu no ikviena, saviem domēniem. Pieslēgšanās nenotiek. Serveri, kas portā 25 pārsūta pastu no ikviena arī uz citiem domēniem, sauc par atvērtu releju (open relay), un to spamotāji izmanto ļaunprātīgi dažu stundu laikā. Tāpēc savas pašas pasta nosūtīšana uz visu pasauli ir kļuvusi par atsevišķu pakalpojumu: submission portā 587 (un 465), kur Jūs vienmēr vispirms piesakāties.

Otrkārt, daudzi interneta pakalpojumu sniedzēji bloķē izejošo trafiku uz portu 25 no mājas pieslēgumiem. Inficēts dators mājās tādējādi nevar tiešā veidā sūtīt spamu uz pasta serveriem. Sekas Jums: ja mēģināsiet nosūtīt pastu no savas pasta programmas, izmantojot portu 25, tas var nestrādāt mājās, bet strādāt birojā, vai otrādi.

Atcerieties: pasta programmas sūta pastu, izmantojot 587 vai 465, ar pieslēgšanos. Ports 25 ir paredzēts serveru savstarpējai saziņai.

STARTTLS vai tiešais TLS?

Pastāv divi veidi, kā šifrēt pasta savienojumu.

Tiešais TLS (implicit TLS): savienojums ir šifrēts jau no pirmā baita, tāpat kā vietne ar https. Tas notiek portos 465, 993 un 995.

STARTTLS: savienojums sākas nešifrēts. Serveris saka "es varu šifrēt", klients atbild ar STARTTLS, un no tā brīža viss notiek šifrēti. Tas notiek portā 587 (kā arī 25, 143 un 110).

Drošības ziņā starpība ir neliela, ja vien Jūsu programma STARTTLS padara obligātu. STARTTLS risks slēpjas sākumā: kāds, kas atrodas starp Jums un serveri, var noņemt piedāvājumu "es varu šifrēt". Programma, kas šādā gadījumā klusi turpina nešifrēti, nosūta Jūsu paroli pa līniju salasāmā veidā. Tāpēc RFC 8314 (2018) pasta programmām iesaka tiešo TLS (465, 993, 995) nevis STARTTLS. Praksē 587 ar STARTTLS un 465 ar SSL/TLS ir abi labi risinājumi, ja Jūs programmā šifrēšanu iestatāt uz "obligāta", nevis "ja pieejama".

Bieži sastopama kļūda ir nepareiza kombinācija: ports 587 ar "SSL/TLS" vai ports 465 ar "STARTTLS". Programma tad sagaida kaut ko citu, nekā serveris faktiski dara, un savienojums iekaras vai neizdodas. Atcerieties pārus: 587 + STARTTLS un 465 + SSL/TLS. Programmas tiešo TLS dažreiz dēvē par "SSL", "SSL/TLS" vai "TLS"; STARTTLS dažkārt arī sauc par "TLS". Tāpēc skatieties uz portu.

Sertifikāts un servera nosaukums

Katrā šifrētā savienojumā serveris uzrāda sertifikātu, kas pierāda, ka tas ir tas, par ko uzdodas. Jūsu pasta programma pārbauda divas lietas: vai sertifikātu izdevusi uzticama puse un vai tas vēl ir derīgs, un vai tajā ir nosaukums, ko Jūs norādījāt kā serveri.

Pēdējā parasti sagādā problēmas. Ja ievadāt mail.example.com, bet sertifikātā norādīts tikai server12.hosting.example, Jūs saņemsiet paziņojumu, piemēram, "Nevar pārbaudīt servera identitāti" vai "Mērķa principal name ir nepareizs". Savienojums pats par sevi gan ir šifrēts, taču Jūsu programma nevar droši zināt, ka tā sazinās ar īsto serveri.

Neaizveriet šādu paziņojumu nepamanītu. Risinājums ir servera nosaukums, kas tiešām ir ietverts sertifikātā (skatiet nodarbību 2.1). Koplietotā serverī tas bieži ir servera paša nosaukums, ko norāda Jūsu pakalpojumu sniedzējs. Vēl viens zināms cēlonis: vīrusu skeneris, kas "skenē" šifrētu pastu un šim nolūkam starpā ieliek savu sertifikātu. Tad paziņojumā pie "izdevis" būs redzams skenera nosaukums.

Pieslēgšanās, nosūtot pastu

Portos 587 un 465 Jums jāpiesakās, pirms serveris piekrīt nosūtīt Jūsu pastu uz āru. To sauc par SMTP autentifikāciju (SMTP AUTH). Jūsu programmā šī opcija saucas "izejošajam serverim nepieciešama autentifikācija", "nepieciešama pieteikšanās" vai "autentifikācija: parasta parole". Parasti izmantojat to pašu lietotājvārdu un paroli, ko IMAP.

Ja autentifikācija ir izslēgta vai izejošā servera lietotājvārds ir palicis tukšs, Jūs varēsiet lasīt pastu, bet ne sūtīt to. Serveris tad atbild ar kaut ko tādu kā 530 5.7.0 Authentication required vai 554 5.7.1 Relay access denied. Tas ir visbiežākais iemesls situācijai "saņemšana strādā, nosūtīšana ne".

Vēl viens noraidījuma veids: 535 5.7.8 Authentication failed. Tad lietotājvārda un paroles kombinācija nav pareiza. Ņemiet vērā, ka pēc vairākiem neveiksmīgiem mēģinājumiem daudzi serveri bloķē IP adresi, no kuras šie mēģinājumi nāk, lai pasargātos no paroļu minēšanas. Vecs tālrunis ar novecojušu paroli šādi var izraisīt visa Jūsu biroja bloķēšanu.

Lietotnes paroles un OAuth

Lielo pakalpojumu sniedzēju, piemēram, Google un Microsoft, gadījumā pieslēgšanās ar vienkāršu parasto paroli atsevišķā pasta programmā strādā arvien retāk. Viņi izmanto OAuth: Jūsu programma Jūs novirza uz pakalpojumu sniedzēja pieteikšanās lapu, Jūs tur piesakāties (iespējams, ar divpakāpju autentifikāciju), un programma parole vietā saņem atslēgu. Programmas, kas to neatbalsta, dažreiz saņem lietotnes paroli: atsevišķu, garu paroli, kas derīga tikai šai vienai programmai un ko var atsevišķi atsaukt.

Parastā pastkastē pie hostinga uzņēmuma Jūs parasti piesakāties ar pašas pastkastes paroli. Tāpēc stipras un unikālas paroles izvēle ir īpaši svarīga (nodarbība 3.4).

Praksē: pastkastes iestatījumi

WebOké pastkastei iestatījumi ir šādi: IMAP 993 ar SSL/TLS, POP3 995 ar SSL/TLS, nosūtīšana 587 ar STARTTLS vai 465 ar SSL/TLS, autentifikācija ieslēgta, izmantojot Jūsu pilnu e-pasta adresi un pastkastes paroli. Citiem pakalpojumu sniedzējiem tas darbojas līdzīgi: porti gandrīz visur ir vienādi, atšķiras tikai servera nosaukums. Kuru servera nosaukumu izvēlēties, skatiet nodarbībā 2.1.

Kopsavilkums

• Pasta programmas sūta pastu, izmantojot 587 (STARTTLS) vai 465 (tiešais TLS), vienmēr ar pieslēgšanos. Ports 25 ir paredzēts serveru savstarpējai saziņai un mājās bieži tiek bloķēts.
• Lasīšana notiek, izmantojot 993 (IMAP) vai 995 (POP3), abi ar tiešo TLS.
• Kombinējiet pareizi: 587 + STARTTLS, 465 + SSL/TLS. Iestatiet šifrēšanu kā obligātu.
• Sertifikāta paziņojums parasti nozīmē: ievadītais servera nosaukums nav norādīts sertifikātā. Paziņojuma aizvēršana nepamanot nav risinājums.
• "Lasīšana strādā, nosūtīšana ne" gandrīz vienmēr nozīmē: izejošā servera autentifikācija ir izslēgta vai tukša.

Tests

Uzdevums

Uzdevums Z1.4: Pasta servera porti un sertifikāts. Ievadiet ienākošā un izejošā servera nosaukumu, ko izmantojat savai pastkastei (ja Jums nav savas pastkastes, izmantojiet imap.gmail.com un smtp.gmail.com). Portam 993 (ienākošais) un portiem 465 un 587 (izejošie) norādiet, ko sagaidāt: tiešo TLS, STARTTLS vai nesasniedzams, kā arī atzīmējiet, vai, Jūsuprāt, nosaukums ir ietverts sertifikātā. Programma pati izveido savienojumu ar visiem trim portiem un pretstata rezultātu Jūsu atbildēm.

Papildu lasāmviela

Šajos rakstos aprakstītie soļi attiecas uz WebOké paneļiem; pie citiem pakalpojumu sniedzējiem tas darbojas līdzīgi.

• DirectAdmin rokasgrāmata 8.1: Visi iestatījumi pārskatāmi: serveri, porti un drošība
• DirectAdmin rokasgrāmata 8.8: Sūtīšana vai saņemšana neizdodas: kā to atrisināt
• Es nevaru nosūtīt e-pastu (saņemšana darbojas)
• RFC 8314 (tiešais TLS pasta programmām), RFC 6409 (submission), RFC 3207 (STARTTLS), RFC 4954 (SMTP AUTH)
• Kļūdu ziņojumi atrisināti 1.3: Kļūdas kods 535: autentifikācija neizdevās (arī tīmekļa pastā)
• Kļūdu ziņojumi atrisināti 1.7: Relaying denied: Jūsu e-pasta programma nepiesakās serverī
• Kļūdu ziņojumi atrisināti 1.9: Sertifikāta paziņojums Jūsu e-pasta programmā