Vrata, šifriranje in prijava

Modul 1: Kako deluje e-pošta · Čas branja: 10 minut

Cilj lekcije: Po tej lekciji boste znali za vsaka poštna vrata povedati, čemu so namenjena, razložiti razliko med STARTTLS in neposrednim TLS ter pojasniti obvestilo o certifikatu ali zavrnjeno prijavo.

Ključni pojmi: vrata 25, 587, 465, 993, 995, 143, 110, STARTTLS, neposredni TLS (implicit TLS, RFC 8314), certifikat, ime strežnika, SMTP-avtentikacija (SMTP AUTH), odprti relay, blokada vrat 25, geslo za aplikacijo, OAuth

Vrata so vrata

Strežnik ima en IP-naslov, vendar veliko vrat. Vsaka storitev posluša na svojih vratih, številki. Vaš spletni brskalnik potrka na vrata 443, Vaš poštni program na vrata 993 za branje pošte in na 587 ali 465 za pošiljanje. Če izberete napačna vrata, se Vam nihče ne odzove, ali pa se odzove nekdo, ki govori drug jezik. To povzroči nejasna sporočila o napaki, kot sta "ni mogoče vzpostaviti povezave" ali "strežnik se ne odziva".

Poštna vrata na pregleden način:

Zakaj ne kar vrata 25 za pošiljanje?

Nekoč ste v poštnem programu nastavili vrata 25. To je iz dveh razlogov preteklost.

Prvič: na vratih 25 poštni strežnik sprejema pošto od vseh, za svoje lastne domene. Prijava se pri tem ne zahteva. Strežnik, ki na vratih 25 prav tako posreduje pošto od vseh naprej na druge domene, se imenuje odprti relay, in takega v nekaj urah zlorabijo pošiljatelji neželene pošte. Zato je pošiljanje Vaše lastne pošte po vsem svetu postalo ločena storitev: submission na vratih 587 (in 465), kjer se vedno najprej prijavite.

Drugič: številni internetni ponudniki blokirajo odhodni promet na vrata 25 z domačih priključkov. Okužen računalnik v dnevni sobi tako ne more pošiljati neželene pošte neposredno na poštne strežnike. Posledica za Vas: če poskušate iz poštnega programa pošiljati prek vrat 25, se lahko zgodi, da doma to ne deluje, v pisarni pa deluje, ali obratno.

Zapomnite si: poštni programi pošiljajo prek 587 ali 465, s prijavo. Vrata 25 so namenjena strežnikom med seboj.

STARTTLS ali neposredni TLS?

Obstajata dva načina za šifriranje poštne povezave.

Neposredni TLS (implicit TLS): povezava je šifrirana že od prvega bajta naprej, podobno kot spletno mesto z https. To se dogaja na vratih 465, 993 in 995.

STARTTLS: povezava se začne nešifrirana. Strežnik sporoči "lahko šifriram", odjemalec odgovori STARTTLS, in od takrat naprej je vse šifrirano. To se dogaja na vratih 587 (ter na 25, 143 in 110).

Za varnost ni bistvene razlike, dokler Vaš program STARTTLS zahteva kot obvezno. Tveganje pri STARTTLS je na samem začetku: nekdo, ki je med Vami in strežnikom, lahko sporočilo "lahko šifriram" odstrani. Program, ki nato tiho nadaljuje nešifrirano, Vaše geslo pošlje po liniji v berljivi obliki. Zato RFC 8314 (2018) za poštne programe priporoča neposredni TLS (465, 993, 995) namesto STARTTLS. V praksi sta 587 s STARTTLS in 465 s SSL/TLS oba dobra, če v programu šifriranje nastavite na "obvezno" in ne na "če je na voljo".

Pogosta napaka je napačna kombinacija: vrata 587 z "SSL/TLS" ali vrata 465 s "STARTTLS". Program nato pričakuje nekaj drugega, kot strežnik dejansko počne, zato se povezava zatakne ali ne uspe. Zapomnite si pare: 587 + STARTTLS in 465 + SSL/TLS. Programi neposredni TLS včasih imenujejo "SSL", "SSL/TLS" ali "TLS"; STARTTLS se včasih prav tako imenuje "TLS". Zato bodite pozorni na vrata.

Certifikat in ime strežnika

Pri vsaki šifrirani povezavi strežnik pokaže certifikat, ki dokazuje, da je res tisti, za kogar se izdaja. Vaš poštni program preveri dve stvari: ali je certifikat izdala zaupanja vredna stranka in ali je še veljaven, ter ali vsebuje ime, ki ste ga vnesli kot strežnik.

Prav slednje najpogosteje povzroča težave. Če vnesete mail.example.com, v certifikatu pa je naveden samo server12.hosting.example, prejmete obvestilo, kot je "Identitete strežnika ni mogoče preveriti" ali "Ime ciljnega principala je napačno". Povezava sama je takrat sicer šifrirana, vendar Vaš program ne more biti prepričan, da komunicira z resničnim strežnikom.

Takega obvestila ne zavrzite kar tako. Rešitev je vnos imena strežnika, ki je navedeno v certifikatu (glejte lekcijo 2.1). Pri skupnem strežniku je to pogosto ime samega strežnika, ki ga navede Vaš ponudnik. Še en znan vzrok: protivirusni program, ki "skenira" šifrirano pošto in pri tem vstavi svoj lastni certifikat. V obvestilu je takrat pri "izdal" navedeno ime tega programa.

Prijava pri pošiljanju

Na vratih 587 in 465 se morate prijaviti, preden strežnik Vašo pošto pošlje naprej. Temu pravimo SMTP-avtentikacija (SMTP AUTH). V Vašem programu se ta možnost imenuje "odhodni strežnik zahteva preverjanje pristnosti", "potrebna je prijava" ali "avtentikacija: navadno geslo". Običajno uporabite isto uporabniško ime in isto geslo kot za IMAP.

Če je preverjanje pristnosti izključeno, ali če je uporabniško ime pri odhodnem strežniku ostalo prazno, lahko pošto berete, ne morete pa je pošiljati. Strežnik se nato odzove z nečim, kot je 530 5.7.0 Authentication required ali 554 5.7.1 Relay access denied. To je najpogostejši razlog za "prejemanje deluje, pošiljanje pa ne".

Druga vrsta zavrnitve je: 535 5.7.8 Authentication failed. Takrat kombinacija uporabniškega imena in gesla ni pravilna. Bodite pozorni: po določenem številu neuspešnih poskusov številni strežniki blokirajo IP-naslov, s katerega ti poskusi prihajajo, da bi preprečili ugibanje gesel. Star telefon s starim geslom lahko tako povzroči blokado cele Vaše pisarne.

Gesla za aplikacije in OAuth

Pri velikih ponudnikih, kot sta Google in Microsoft, prijava zgolj z navadnim geslom v ločenem poštnem programu deluje vse redkeje. Ti ponudniki uporabljajo OAuth: Vaš program Vas preusmeri na prijavno stran ponudnika, kjer se prijavite (po potrebi z dvostopenjskim preverjanjem), program pa namesto gesla dobi ključ. Programi, ki tega ne zmorejo, včasih dobijo geslo za aplikacijo: posebno, dolgo geslo, ki velja samo za ta en program in ga lahko ločeno prekličete.

Pri navadnem poštnem predalu pri ponudniku gostovanja se običajno prijavite z geslom samega poštnega predala. Zato je močno in edinstveno geslo še toliko bolj pomembno (lekcija 3.4).

V praksi: nastavitve poštnega predala

Pri poštnem predalu WebOké so nastavitve naslednje: IMAP 993 s SSL/TLS, POP3 995 s SSL/TLS, pošiljanje 587 s STARTTLS ali 465 s SSL/TLS, preverjanje pristnosti vklopljeno, z Vašim celotnim e-poštnim naslovom in geslom poštnega predala. Pri drugih ponudnikih deluje podobno: vrata so skoraj povsod enaka, razlikuje se le ime strežnika. Katero ime strežnika izbrati, je razloženo v lekciji 2.1.

Povzetek

• Poštni programi pošiljajo prek 587 (STARTTLS) ali 465 (neposredni TLS), vedno s prijavo. Vrata 25 so namenjena strežnikom med seboj in so doma pogosto blokirana.
• Branje poteka prek 993 (IMAP) ali 995 (POP3), oba z neposrednim TLS.
• Pravilno kombinirajte: 587 + STARTTLS, 465 + SSL/TLS. Šifriranje nastavite na obvezno.
• Obvestilo o certifikatu običajno pomeni: vneseno ime strežnika ni navedeno v certifikatu. Zavračanje obvestila ni rešitev.
• "Branje deluje, pošiljanje pa ne" je skoraj vedno posledica tega, da je preverjanje pristnosti za odhodni strežnik izključeno ali ni izpolnjeno.

Kviz

Naloga

Naloga Z1.4: Vrata in certifikat poštnega strežnika. Vnesite ime dohodnega in odhodnega strežnika, ki ga uporabljate za svoj lastni poštni predal (če nimate lastnega poštnega predala, uporabite imap.gmail.com in smtp.gmail.com). Za vrata 993 (dohodna) ter vrata 465 in 587 (odhodna) izberite, kaj pričakujete: neposredni TLS, STARTTLS ali nedosegljivo, in vnesite, ali menite, da je ime navedeno v certifikatu. Program sam vzpostavi povezavo s tremi vrati in rezultat postavi ob Vaše odgovore.

Za nadaljnje branje

Koraki v teh člankih veljajo za nadzorne plošče WebOké; pri drugih ponudnikih deluje podobno.

• Priročnik DirectAdmin 8.1: Vse nastavitve na enem mestu: strežniki, vrata in varnost
• Priročnik DirectAdmin 8.8: Pošiljanje ali prejemanje e-pošte ne deluje: tako to odpravite
• Opozorilo o certifikatu pri prejemanju pošte
• Ne morem poslati e-pošte (prejemanje deluje)
• RFC 8314 (neposredni TLS za poštne programe), RFC 6409 (submission), RFC 3207 (STARTTLS), RFC 4954 (SMTP AUTH)