Sähköpostin matka

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

Oppimistavoite: Tämän oppitunnin jälkeen osaat kuvailla vaihe vaiheelta, miten sähköposti kulkee lähettäjältä vastaanottajalle, ja kertoa jokaisen vaiheen kohdalla, mikä ohjelma tai palvelin tekee työn.

Keskeiset käsitteet: sähköpostiohjelma (MUA), lähetyspalvelin (MSA, submission), sähköpostipalvelin (MTA), MX-tietue, jono, toimitus (MDA), postilaatikko, noutaminen (IMAP/POP3), envelope, otsikkorivit

Sähköposti on postia, ei pikaviesti

Kun lähetät pikaviestin, se kulkee yhden yrityksen kautta: lähettäjän ja vastaanottajan sovellukset keskustelevat samojen palvelimien kanssa. Sähköposti toimii toisin. Lähettäjä ja vastaanottaja voivat olla kumpikin eri palveluntarjoajalla: toinen hostingyrityksellä, toinen Gmailissa, kolmas Microsoft 365:ssä tai omalla yrityspalvelimellaan. Silti sähköposti perille. Tämä onnistuu, koska kaikki maailman sähköpostipalvelimet noudattavat samoja sopimuksia.

Sähköpostia voi hyvin verrata postinkulkuun. Kirjoitat kirjeen (viestin), laitat sen kirjekuoreen, jossa on osoite (envelope), viet sen postilaatikkoon (lähetyspalvelin), postiyhtiö selvittää, missä osoite sijaitsee (MX-haku), kuljettaa kirjeen oikeaan lajittelukeskukseen (vastaanottava sähköpostipalvelin) ja se laittaa sen vastaanottajan postilaatikkoon (postilaatikko). Vastaanottaja noutaa sen sieltä, kun hänelle sopii.

Asemat järjestyksessä

Oletetaan, että Anna lähettää sähköpostia osoitteesta anna@example.com osoitteeseen jan@example.net. Näin tapahtuu:

Pienillä palveluntarjoajilla MSA, MTA ja MDA ovat usein yksi ja sama ohjelma yhdellä palvelimella. Suurilla palveluntarjoajilla ne ovat erillisiä klustereita. Sinulle sillä ei ole paljon väliä: kyseessä ovat roolit, eivät laitteet.

Huomaa ero vaiheiden 1 ja 4 välillä. Molemmat käyttävät SMTP:tä, Simple Mail Transfer Protocolia (RFC 5321). Mutta vaiheessa 1 kirjaudut sisään ja käytät porttia 587 tai 465; tätä kutsutaan nimellä submission (RFC 6409). Vaiheessa 4 kaksi palvelinta keskustelee keskenään portissa 25 ilman sisäänkirjautumista: vastaanottava palvelin ottaa vastaan sähköpostia omille domeineilleen keneltä tahansa. Oppitunnilla 1.4 näet, miksi tämä erottelu on olemassa.

Vaihe 3 lähempää tarkasteltuna: MX-haku

Lähettävä palvelin ei tiedä itsestään, minne example.net vastaanottaa sähköpostinsa. Se kysyy sitä DNS:ltä:

example.net.   3600  IN  MX  10 mx1.mailprovider.example.
example.net.   3600  IN  MX  20 mx2.mailprovider.example.

Pienimmällä numerolla on etusija. Palvelin yrittää ensin mx1:tä, ja jos se ei vastaa, mx2:ta. Sen jälkeen se kysyy kyseisen nimen IP-osoitteen (A- tai AAAA-tietue) ja muodostaa yhteyden.

Kaksi erikoistapausta, jotka tulet käytännössä kohtaamaan:

• Ei MX-tietuetta. Tällöin lähettäjä yrittää domeenin oman A- tai AAAA-tietueen kautta (RFC 5321:n kappaleen 5.1 mukainen "implisiittinen MX"). Tämä on jäänne menneisyydestä eikä toimi luotettavasti; jokaisella sähköpostia vastaanottavalla domeenilla pitäisi olla MX-tietue.
• Null MX: 0 . Tämä tarkoittaa: "tämä domeeni ei koskaan vastaanota sähköpostia" (RFC 7505). Domeenilla example.com on tällainen. Lähettäjä luovuttaa heti ja lähettää virheilmoituksen takaisin sen sijaan, että yrittäisi uudelleen päiväkausia.

Tarkemmin siitä, miten MX-tietueet ja niiden prioriteetit toimivat, lue DNS-kurssin oppitunnilta 4.1.

Jono: sähköposti saa kestää hetken

Sähköposti ei aina saavu sekunnissa. Jos vastaanottava palvelin ei vastaa, tai se sanoo "yritä myöhemmin uudelleen" (koodi, joka alkaa numerolla 4), sähköposti jää lähetyspalvelimen jonoon. Palvelin yrittää myöhemmin uudelleen, aina vähän pidemmällä väliajalla. RFC 5321 (kappale 4.5.4.1) suosittelee vähintään 30 minuutin väliä yritysten välillä ja luopumista vasta 4-5 päivän jälkeen. Monet palvelimet lähettävät jo muutaman tunnin kuluttua varoituksen ("delayed", ei vielä toimitettu) ja muutaman päivän kuluttua lopullisen virheilmoituksen.

Tämä on sähköpostin vahva puoli: jos sähköpostipalvelin on tunnin poissa käytöstä, mikään sähköposti ei katoa. Se on myös syy siihen, miksi sähköposti saapuu joskus vasta tuntien kuluttua. Moduulissa 6 näet, miten tällaisen viiveen tunnistaa.

Envelope ja otsikkorivit: kaksi osoitetta

Aivan kuten postissa, sähköpostilla on kahdenlaisia osoitteita:

• Envelope. Nämä ovat osoitteita, joita palvelimet käyttävät keskenään SMTP-keskustelussa: MAIL FROM (lähettäjä virheilmoituksia varten, myöhemmin näkyy nimellä Return-Path) ja RCPT TO (vastaanottaja). Palvelimet toimittavat sähköpostin envelopen perusteella.
• Otsikkorivit (headers). Tämä on se, mitä itse kirjeessä lukee: From:, To:, Cc:, Subject:, Date:. Sähköpostiohjelmasi näyttää nämä.

Yleensä ne ovat samat, mutta ei aina. Piilokopion (BCC) saaja on envelopessa, mutta ei otsikkoriveillä; siksi muut eivät näe häntä. Uutiskirjepalvelu laittaa oman osoitteensa envelope-lähettäjäksi (envelope sender), jotta virheilmoitukset menevät palvelulle, kun taas From:-kentässä on sinun osoitteesi. Ja huijari voi laittaa From:-kenttään mitä tahansa.

Miksi tällä on merkitystä: SPF tarkistaa envelope-lähettäjän, käyttäjä näkee From:-kentän. Siksi on olemassa DMARC, joka yhdistää nämä kaksi toisiinsa (moduuli 4).

Missä kohtaa voi mennä pieleen

Tämän kuvan avulla voit jokaisen ongelman kohdalla kysyä: missä asemassa menee pieleen?

• Lähettäminen ei onnistu (virheilmoitus heti ohjelmassasi): vaihe 1 tai 2. Lähes aina asetusten vika: portti, sisäänkirjautuminen, salasana (moduuli 2).
• Saat bouncen takaisin: vaihe 4 tai 5. Vastaanottava palvelin hylkäsi sähköpostin, tai osoitetta ei ole olemassa (moduuli 6).
• Sähköposti saapuu, mutta roskapostikansioon: vaihe 5. Vastaanottaja ei luota sähköpostiin (moduulit 4 ja 5).
• Vastaanottaja ei näe mitään, etkä sinä saa virheilmoitusta: sähköposti on ehkä vielä jonossa, tai se on suodatettu vastaanottajan puolella huomaamatta. Tässä auttavat lähetyspalvelimen lokit (moduuli 6).
• Sähköposti ei saavu lainkaan domeenillesi: vaihe 3. MX-tietueet eivät ole kunnossa, esimerkiksi muuton jälkeen (moduuli 8).

Käytännössä: näin se näkyy hostingpaketissa

WebOkén hostingpaketissa yksi palvelin per paketti hoitaa kaikki roolit: sähköpostiohjelmasi toimittaa viestin tälle palvelimelle (vaihe 1 ja 2), palvelin lähettää sen ulospäin (vaihe 3 ja 4) ja vastaanottaa sähköpostia domeenillesi (vaihe 5). DirectAdminissa voit E-mail Trackingin avulla tarkistaa viestikohtaisesti, onko viesti toimitettu. Muilla palveluntarjoajilla se toimii samankaltaisesti; siellä vastaava toiminto voi olla nimeltään esimerkiksi "viestien seuranta" tai "mail log".

Yhteenveto

• Sähköposti kulkee sähköpostiohjelmastasi (MUA) lähetyspalvelimen (MSA/MTA) kautta vastaanottavalle palvelimelle (MTA/MDA) ja sieltä vastaanottajan sähköpostiohjelmaan.
• Lähettäminen ohjelmastasi on SMTP-submissionia sisäänkirjautumisella (587/465); palvelimet keskustelevat keskenään SMTP:llä portissa 25; noutaminen tapahtuu IMAP:lla tai POP3:lla.
• Lähettävä palvelin hakee @-merkin jälkeisen domeenin MX-tietueet. Null MX (0 .) tarkoittaa: tämä domeeni ei vastaanota sähköpostia.
• Sähköposti, jota ei voida toimittaa heti, jää jonoon ja sitä yritetään uudelleen päivien ajan.
• Envelope (Return-Path) ja otsikkorivit (From) ovat kaksi eri lähettäjää. SPF tarkastelee ensimmäistä, käyttäjä toista.

Tietovisa

Tehtävä

Tehtävä Z1.1: Ensimmäisen sähköpostipalvelimen etsiminen. Hae domeenin gmail.com (tai oman domeenisi) MX-tietueet. Täytä, mitä palvelinta yritetään ensimmäisenä, sen prioriteettinumero, ja yksi kyseisen palvelimen IP-osoite (IPv4 tai IPv6). Ohjelma kysyy samat tiedot livenä ja tarkistaa ne.

Lue lisää

Näiden artikkelien vaiheet koskevat WebOkén paneeleja; muilla palveluntarjoajilla se toimii samankaltaisesti.

• Sähköpostin lähetysprosessi ja SMTP
• DirectAdmin-ohje 8.7: IMAP vai POP3: mikä on ero?
• Ilmainen DNS-kurssi 4.1: MX-tietueet ja prioriteetti
• RFC 5321 (SMTP), kappale 5.1 (MX ja implisiittinen MX) ja 4.5.4.1 (uudelleenyritys); RFC 7505 (null MX)