Portit, salaus ja sisäänkirjautuminen

Moduuli 1: Näin sähköposti toimii · Lukuaika: 10 minuuttia

Oppimistavoite: Tämän oppitunnin jälkeen osaat kertoa jokaisen sähköpostiportin käyttötarkoituksen, selittää eron STARTTLS:n ja suoran TLS:n välillä sekä selittää varmenneilmoituksen tai evätyn kirjautumisen syyn.

Keskeiset käsitteet: portti 25, 587, 465, 993, 995, 143, 110, STARTTLS, suora TLS (implicit TLS, RFC 8314), varmenne, palvelimen nimi, SMTP-tunnistautuminen (SMTP AUTH), avoin relay, portin 25 esto, sovelluskohtainen salasana, OAuth

Portti on ovi

Palvelimella on yksi IP-osoite, mutta useita ovia. Jokainen palvelu kuuntelee omassa portissaan, eli numerossa. Verkkoselaimesi koputtaa porttiin 443, sähköpostiohjelmasi porttiin 993 lukeakseen postia ja porttiin 587 tai 465 lähettääkseen postia. Jos valitset väärän oven, kukaan ei vastaa, tai joku vastaa eri kielellä. Tästä syntyy epämääräisiä virheilmoituksia kuten "yhteyttä ei voi muodostaa" tai "palvelin ei vastaa".

Sähköpostiportit listattuna:

Miksi ei vain porttia 25 lähetykseen?

Ennen sähköpostiohjelmaan asetettiin portti 25. Se on kahdesta syystä mennyttä aikaa.

Ensinnäkin: portissa 25 sähköpostipalvelin ottaa vastaan postia keneltä tahansa, mutta vain omiin verkkotunnuksiinsa. Sisäänkirjautumista ei vaadita. Palvelinta, joka portissa 25 välittää postia myös muihin verkkotunnuksiin keneltä tahansa, kutsutaan avoimeksi relayksi, ja se joutuu spämmäreiden väärinkäytön kohteeksi muutamassa tunnissa. Siksi oman postin lähettämisestä koko maailmaan on tehty erillinen palvelu: submission portissa 587 (ja 465), jossa kirjaudutaan aina ensin sisään.

Toiseksi: monet internetoperaattorit estävät lähtevän liikenteen porttiin 25 kotiliittymistä. Näin tartunnan saanut kotitietokone ei voi lähettää roskapostia suoraan sähköpostipalvelimille. Seuraus sinulle: jos yrität lähettää sähköpostiohjelmasta portin 25 kautta, se ei välttämättä toimi kotona mutta toimii toimistolla, tai päinvastoin.

Muista: sähköpostiohjelmat lähettävät portin 587 tai 465 kautta, aina kirjautuen sisään. Portti 25 on palvelinten välistä liikennettä varten.

STARTTLS vai suora TLS?

Sähköpostiyhteyden voi salata kahdella tavalla.

Suora TLS (implicit TLS): yhteys on salattu ensimmäisestä tavusta alkaen, aivan kuten https-verkkosivu. Tämä tapahtuu porteissa 465, 993 ja 995.

STARTTLS: yhteys alkaa salaamattomana. Palvelin sanoo "pystyn salaamaan", asiakasohjelma vastaa STARTTLS, ja siitä hetkestä lähtien kaikki on salattua. Tämä tapahtuu portissa 587 (sekä porteissa 25, 143 ja 110).

Turvallisuuden kannalta eroa ei juuri ole, kunhan ohjelmasi vaatii STARTTLS:n pakolliseksi. STARTTLS:n riski on alussa: joku, joka on sinun ja palvelimen välissä, voi poistaa viestin "pystyn salaamaan". Ohjelma, joka tällöin jatkaa hiljaa salaamattomana, lähettää salasanasi luettavana linjan yli. Siksi RFC 8314 (2018) suosittelee sähköpostiohjelmille suoraa TLS:ää (465, 993, 995) STARTTLS:n sijaan. Käytännössä sekä 587 STARTTLS:n kanssa että 465 SSL/TLS:n kanssa toimivat hyvin, kunhan asetat ohjelmassasi salauksen tilaan "pakollinen" etkä "jos mahdollista".

Yleinen virhe on väärä yhdistelmä: portti 587 asetuksella "SSL/TLS", tai portti 465 asetuksella "STARTTLS". Tällöin ohjelma odottaa jotain muuta kuin mitä palvelin tekee, ja yhteys jää roikkumaan tai epäonnistuu. Muista parit: 587 + STARTTLS ja 465 + SSL/TLS. Ohjelmat kutsuvat suoraa TLS:ää joskus nimillä "SSL", "SSL/TLS" tai "TLS"; STARTTLS:ää kutsutaan joskus myös nimellä "TLS". Katso siis porttia.

Varmenne ja palvelimen nimi

Jokaisessa salatussa yhteydessä palvelin näyttää varmenteen, joka todistaa, että se on se, mikä se väittää olevansa. Sähköpostiohjelmasi tarkistaa kaksi asiaa: onko varmenteen myöntänyt luotettu taho ja onko se yhä voimassa, sekä löytyykö siitä nimi, jonka syötit palvelimeksi.

Jälkimmäinen menee useimmin pieleen. Jos syötät mail.example.com, mutta varmenteessa on vain server12.hosting.example, saat ilmoituksen kuten "Palvelimen identiteettiä ei voida vahvistaa" tai "Kohteen principal-nimi on virheellinen". Yhteys itsessään on silti salattu, mutta ohjelmasi ei voi olla varma, että se keskustelee oikean palvelimen kanssa.

Älä klikkaa tällaista ilmoitusta pois. Ratkaisu on syöttää palvelimen nimi, joka todella löytyy varmenteesta (katso oppitunti 2.1). Jaetulla palvelimella tämä on usein palvelimen oma nimi, jonka palveluntarjoajasi ilmoittaa. Toinen tunnettu syy: virustorjuntaohjelma, joka "skannaa" salattua postia ja lisää sitä varten oman varmenteensa väliin. Ilmoituksessa näkyy tällöin skannerin nimi kohdassa "myöntäjä".

Sisäänkirjautuminen lähetettäessä

Porteissa 587 ja 465 täytyy kirjautua sisään ennen kuin palvelin suostuu lähettämään postisi ulos. Tätä kutsutaan SMTP-tunnistautumiseksi (SMTP AUTH). Ohjelmassasi vaihtoehto voi olla nimeltään "lähtevä palvelin vaatii todennusta", "kirjautuminen vaaditaan" tai "tunnistautuminen: tavallinen salasana". Yleensä käytät samaa käyttäjätunnusta ja salasanaa kuin IMAP:ssa.

Jos tunnistautuminen on pois päältä, tai lähtevän palvelimen käyttäjätunnus on jäänyt tyhjäksi, voit lukea postia mutta et lähettää sitä. Palvelin vastaa tällöin jotain kuten 530 5.7.0 Authentication required tai 554 5.7.1 Relay access denied. Tämä on yleisin syy tilanteeseen "vastaanotto toimii, lähetys ei".

Toinen hylkäyksen tyyppi: 535 5.7.8 Authentication failed. Tällöin käyttäjätunnuksen ja salasanan yhdistelmä on väärä. Huomaa: useiden epäonnistuneiden yritysten jälkeen monet palvelimet estävät IP-osoitteen, josta yritykset tulevat, salasanojen arvaamista vastaan. Vanha puhelin vanhalla salasanalla voi näin estää koko toimistosi.

Sovelluskohtaiset salasanat ja OAuth

Suurilla palveluntarjoajilla kuten Googlella ja Microsoftilla sisäänkirjautuminen pelkällä tavallisella salasanalla erillisessä sähköpostiohjelmassa toimii yhä harvemmin. Ne käyttävät OAuthia: ohjelmasi ohjaa sinut palveluntarjoajan kirjautumissivulle, kirjaudut siellä sisään (mahdollisesti kaksivaiheisella tunnistautumisella), ja ohjelma saa avaimen salasanasi sijaan. Ohjelmat, jotka eivät tue tätä, saavat joskus sovelluskohtaisen salasanan: erillisen, pitkän salasanan, joka kelpaa vain tuolle yhdelle ohjelmalle ja jonka voi perua erikseen.

Tavallisessa hosting-yrityksen sähköpostilaatikossa kirjaudutaan yleensä sisään itse postilaatikon salasanalla. Siksi vahva ja ainutlaatuinen salasana on erityisen tärkeä (oppitunti 3.4).

Käytännössä: postilaatikon asetukset

WebOkén postilaatikossa asetukset ovat: IMAP 993 SSL/TLS:llä, POP3 995 SSL/TLS:llä, lähetys 587 STARTTLS:llä tai 465 SSL/TLS:llä, tunnistautuminen päällä koko sähköpostiosoitteellasi ja postilaatikon salasanalla. Muilla palveluntarjoajilla toiminta on vastaavaa: portit ovat lähes kaikkialla samat, vain palvelimen nimi vaihtelee. Minkä palvelimen nimen valitset, näet oppitunnilla 2.1.

Yhteenveto

• Sähköpostiohjelmat lähettävät portin 587 (STARTTLS) tai 465 (suora TLS) kautta, aina kirjautuen sisään. Portti 25 on palvelinten välistä liikennettä varten ja se estetään usein kotiliittymissä.
• Lukeminen tapahtuu portin 993 (IMAP) tai 995 (POP3) kautta, molemmat suoralla TLS:llä.
• Yhdistä oikein: 587 + STARTTLS, 465 + SSL/TLS. Aseta salaus pakolliseksi.
• Varmenneilmoitus tarkoittaa yleensä: syöttämäsi palvelimen nimi ei löydy varmenteesta. Pois klikkaaminen ei ole ratkaisu.
• "Lukeminen onnistuu, lähetys ei" tarkoittaa lähes aina: lähtevän palvelimen tunnistautuminen on pois päältä tai tyhjä.

Tietovisa

Tehtävä

Tehtävä Z1.4: Sähköpostipalvelimen portit ja varmenne. Syötä saapuvan ja lähtevän palvelimen nimi, jota käytät omassa postilaatikossasi (jos sinulla ei ole omaa postilaatikkoa, käytä imap.gmail.com ja smtp.gmail.com). Valitse portille 993 (saapuva) sekä porteille 465 ja 587 (lähtevä) se, mitä odotat: suora TLS, STARTTLS vai ei tavoitettavissa, ja merkitse, uskotko että nimi löytyy varmenteesta. Ohjelma muodostaa itse yhteyden kaikkiin kolmeen porttiin ja asettaa tuloksen rinnalle vastauksiesi kanssa.

Lue lisää

Näiden artikkelien ohjeet koskevat WebOkén hallintapaneeleita; muilla palveluntarjoajilla toiminta on vastaavaa.

• DirectAdmin-ohje 8.1: Kaikki asetukset yhdessä paikassa: palvelimet, portit ja suojaus
• DirectAdmin-ohje 8.8: Sähköpostin lähettäminen tai vastaanottaminen ei onnistu: näin ratkaiset ongelman
• Varmennevirhe sähköpostia haettaessa
• En voi lähettää sähköpostia (vastaanottaminen toimii)
• RFC 8314 (suora TLS sähköpostiohjelmille), RFC 6409 (submission), RFC 3207 (STARTTLS), RFC 4954 (SMTP AUTH)