Sähköpostit eivät mene inboxiin? SPF, DKIM ja DMARC auttavat

Sähköposti on ollut käänteentekevä keksintö, ja se on onnistunut sulautumaan arkeemme niin hyvin, että sitä ei juurikaan tule edes ajatelleeksi. Maailmanlaajuiset sähköpostitilastot vuodelta 2020 ovatkin lähes uskomattomia:

• Sähköpostikäyttäjiä arvioitiin olevan hieman yli neljä miljardia
• Keskimääräisenä päivänä lähetettiin arviolta yli kolmesataa miljardia sähköpostia

(lähde: Statista)

Koska sähköposti on niin arkinen asia, on ehkä hieman yllättävää, että sähköpostin kanssa toimiminen on nykyään aivan järkyttävän vaikeaa.

Roskaposti: this is why we can’t have nice things!

Sähköpostin yleismaailmallisuuden ja kustannustehokkuuden vuoksi sitä käytetään erittäin paljon myös kaikenlaisten hämärähommien hoitamiseen. Kaikille ovat varmasti tuttuja huijausmailit, joissa tarjotaan mahdollisuutta äkkirikastumiseen: afrikkalainen prinssi haluaa apuasi merkittävän omaisuutensa kanssa tai sähköpostiosoitteesi on voittanut jackpotin kansainvälisessä sähköpostilottoarvonnassa. Varsin usein taitaa sähköpostilaatikkoon kolahtaa myös mainoksia keinoista kasvattaa sukupuolielimen kokoa, parantaa potenssia tai ehkäistä kaljuuntumista. Ahneus, seksi ja turhamaisuus yleensä toimivat aika hyvinä houkuttimina.

Vuonna 2004 Bill Gates ennusti, että roskaposti on ratkaistu ongelma vuoteen 2006 mennessä. Näin 15 vuotta myöhemmin voidaan todeta, että Gatesin ennustus meni metsään. Tämä ei kuitenkaan tarkoita, etteikö roskapostiongelmaan oltaisi kehitetty jokseenkin toimivia estomenetelmiä. Kuten kaikilla muillakin elämän osa-alueilla, myös sähköpostissa hämäräpuuhien ehkäisy aiheuttaa julmetusti vaivaa lainkuuliaisille kaidan tien kulkijoille.

Wikipediaan on koottu erinomainen lista erilaisista roskapostin ehkäisymenetelmistä. Tässä blogikirjoituksessa haluan kuitenkin keskittyä kolmeen tekniikkaan, joiden kanssa me joudumme toimimaan lähes päivittäin, kun rakennamme sähköpostilähetystoiminnallisuuksia osaksi verkkopalveluita: SPF, DKIM ja DMARC.

Vuonna 2004 Bill Gates ennusti, että roskaposti on ratkaistu ongelma vuoteen 2006 mennessä.

SPF, Sender Policy Framework

SPF, eli Sender Policy Framework, on menetelmä, jolla pyritään estämään epämääräisiä tahoja lähettämästä sähköpostia jonkin organisaation nimissä. SPF:n toiminta perustuu domainiin liitettyyn TXT-tietueeseen, jossa kerrotaan, mitkä palvelimet saavat lähettää sähköpostia niin, että lähettäjänä on jokin ko. domainin osoite. Sähköpostipalvelimet voivat sitten tarkistaa tuon SPF-käytössä olevan tietueen ja joko hyväksyä tai hylätä sähköpostin sillä perusteella, onko lähettävä palvelin sallittuna domainin SPF-asetuksissa. Esimerkiksi karhuhelsinki.fi-domainin SPF-asetukset näyttävät tältä: v=spf1 include:spf.mailjet.com mx a include:servers.mcsv.net include:spf.protection.outlook.com ~all

Tässä tietueessa olevat säännöt tarkoittavat seuraavaa:

• v=spf1: Ilmoitus siitä, että tietue sisältää SPF-tiedot version 1 mukaisina (muita versioita ei ole käytössä).
• include:spf.mailjet.com: Lisätään tämän domainin SPF-asetuksiin mukaan kaikki asetukset domainista spf.mailjet.com (Mailjet-palvelun palvelimet).
• mx: Sallitaan lähettäviksi palvelimiksi ne palvelimet, jotka on listattu domainin MX-tietueissa – eli domainin sähköpostipalvelimet.
• a: Sallitaan lähettäviksi palvelimiksi domainin A- ja AAAA-tietueissa mainitut palvelimet.
• include:servers.mcsv.net: Lisätään tämän domainin SPF-asetuksiin mukaan kaikki asetukset domainista servers.mcsv.net (Mailchimp-palvelun palvelimet).
• include:spf.protection.outlook.com: Lisätään tämän domainin SPF-asetuksiin mukaan kaikki asetukset domainista spf.protection.outlook.com (Microsoftin SPF-asetukset).
• ~all: Kaikkien muiden lähettävien palvelinten sähköpostit käsitellään ns. softfail-menettelyllä, eli postien sallitaan mennä läpi, mutta ne merkitään epäilyttäviksi tai roskapostiksi. Jos merkintänä olisi -all, olisi käytössä ns. hardfail-menettely, jossa sähköpostit muilta palvelimilta hylätään kokonaan.

Domainin SPF-asetusten tarkistaminen onnistuu näppärästi esim. dig-komentorivityökalulla: dig karhuhelsinki.fi txt. SPF ei yksinään ole kovinkaan hyvä tae siitä, että sähköposti on OK. Se ei anna mitään takuita siitä, että sähköpostin sisältö ei ole muuttunut matkalla lähettäjältä vastaanottajalle, ja etenkin löyhemmillä SPF-asetuksilla lähettävä palvelinkin voi olla melkein mikä vain.

Tämän kaiken lisäksi sähköpostia käsiteltäessä on käytössä kaksi erillistä From-tietoa: SMTP-sessioon liitetty From sekä SMTP-datassa oleva From-otsake. SPF validoi ainoastaan SMTP-sessiossa olevan From-tiedon, joten vastaanottajalle viesti voi näyttää tulevan eri lähettäjältä kuin mitä SPF on validoinut. Ei hyvä.

DKIM, DomainKeys Identified Mail

DKIM, eli DomainKeys Identified Mail, on kryptografinen varmennusmetodi, jolla sähköposti pyritään saamaan liitettyä väitettyyn lähettäjään ja mahdollisesti saadaan myös takeita siitä, että sähköpostin sisältöön ei ole kajottu lähettämisen jälkeen. DKIM:n toiminta perustuu avainpariin ja digitaaliseen allekirjoitukseen:

• Lähetettävälle viestille muodostetaan DKIM-otsake, joka sisältää tietoa sekä itse viestistä että viestin allekirjoituksen tarkistamisesta. Otsakkeen sisällä tulee muiden tietojen mukana myös digitaalinen allekirjoitus, joka muodostetaan valittavien viestin otsakkeiden ja sisällön perusteella. Käytettävistä otsakkeista vain from (viestin lähettäjä) on pakollinen ja muut voi lähettävän pään toteutus valita itse.
• Digitaalinen allekirjoitus salataan avainparin yksityisellä avaimella. Salaus toimii asymmetrisesti niin, että yksityisellä avaimella salattu viesti voidaan avata avainparin julkisella avaimella, mutta yksityistä avainta ei voida päätellä julkisen avaimen perusteella.
• Allekirjoituksen salaukseen käytetyn avainparin julkinen avain on saatavilla tietyn alidomainin TXT-tietueessa. Varmistettaessa DKIM-allekirjoitettua viestiä muodostetaan käytettävä alidomain DKIM-otsakkeen d– ja s-kenttien perusteella kaavan [s]._domainkey.[d] mukaan. Jos siis esim. selektori s on skeletor ja domain d on heman.dog, on julkisen avaimen sisältävä alidomain skeletor._domainkey.heman.dog. Tämä mekanismi mahdollistaa usean avainparin käyttämisen DKIM-allekirjoitusten salauksessa.

Käytännössä DKIM pyrkii varmistamaan vain, että viesti on lähetetty siitä domainista, joka viestissä näkyy lähettäjänä, ja että allekirjotuksen kattamia kenttiä ei ole muutettu viestin välittämisen aikana. DKIM ei oikeastaan pääse tähän pyrkimykseen kovinkaan hyvin, sillä standardista on unohtunut mm. määritellä, mitä tehdään sellaisissa tapauksissa, joissa sama kenttä esiintyy viestissä kahdesti. DKIM kärsii myös samasta From-tieto-ongelmasta kuin SPF. Toisaalta alunperinkin vain osa viestistä on allekirjoitettuna, joten viestiin voidaan välityksen aikana lisätä kenttiä varsin vapaasti ja allekirjoitus pysyy silti validina. Eli myös DKIM sinällään on jokseenkin hyödytön.

DMARC, Domain-based Message Authentication, Reporting and Conformance

DMARC, eli Domain-based Message Authentication, Reporting and Conformance, on varmennusprotokolla, jolla SPF ja DKIM saadaan oikeasti hyödyllisiksi. DMARC nimittäin määrittelee sen, miten tietyn domainin nimissä lähetettyä sähköpostia tulee käsitellä ja mitkä kaikki varmennusmetodit lähetetyn viestin tulee läpäistä. DMARCiin on sisäänrakennettu myös raportointimekanismi, jolla voidaan tuottaa XML-muotoisia raportteja läpäisseistä ja hylätyistä lähetyksistä.

Kuten SPF ja DKIM, myös DMARC vaatii omat TXT-tietueensa domainiin. DMARCin tapauksessa tietue löytyy _dmarc-alidomainista ja on muodoltaan seuraavanlainen: v=DMARC1;p=reject;pct=100;rua=mailto:postmaster@dmarcdomain.com

Esimerkkitietueessa olevat osat ovat:

• v=DMARC1: Protokollaversio.
• p=reject: Käytäntö, jonka mukaan lähetyksiä käsitellään. Tässä tapauksessa lähetykset hylätään SMTP-palvelintasolla, eli tuloksena on ns. bounce – sähköpostia ei välitetä eteenpäin ollenkaan.
• pct=100: Prosenttiosuus lähetyksistä, joihin DMARCia sovelletaan. Tämä on kätevä asetus DMARCin käyttöönottovaiheessa, kun halutaan varmistaa, että DMARC toimii oikein.
• rua=mailto:postmaster@dmarcdomain.com: Sähköpostiosoite, johon koosteraportit lähetetään.

Sen lisäksi, että DMARCilla voidaan pakottaa viestit menemään SPF- ja DKIM-validoinnin läpi, DMARC myös korjaa joitakin SPF:n ja DKIM:n puutteita. DMARC nimittäin esittelee identifier alignment -ominaisuuden, joka varmistaa, että käyttäjälle näkyvän From-kentän (SMTP-datasta poimittu otsake) domain vastaa sitä domainia, jota on käytetty SPF- ja DKIM-validoinnissa. DMARC siis oikeasti tekee myös SPF:stä ja DKIM:stä hyödyllisiä!

Mitä tämä käytännössä tarkoittaa?

Alussa kerroin, että sähköpostin kanssa toimiminen on nykyään yllättävän vaikeaa. Tällä viittasin siihen, että sähköpostitoiminnallisuuksien rakentaminen osaksi verkkopalveluita on tänä päivänä hyvin erilaista verrattuna siihen, mitä sama homma oli kymmenen-viisitoista vuotta sitten. Nyt ei riitä, että palvelimella on yhteys SMTP-palvelimeen, vaan onnistuneiden sähköpostilähetysten vaatimuslista on nykyään melkoinen:

Jos domainilla ei ole käytössä SPF:ää, DKIM:ää tai DMARCia, on melko todennäköistä, että kyseisellä domainilla lähetetty sähköposti sujahtaa roskaposteihin. Jos tuollaista sähköpostia lähtee joltakin palvelimelta paljon, kärsii koko domainin maine ja on todennäköistä, että kaikki muutkin ko. domainin osoitteilla lähetetyt sähköpostit jäävät roskapostisuodatinten haaveihin.

Onkin ehdottomasti järkevää siirtää osa vastuusta muiden huoleksi ja keskittyä itse olennaiseen. Mailgunin kaltaiset palvelut auttavat paitsi domainin konfiguroinnissa, myös sähköpostipalveluiden rakentamisessa. Kun sähköpostit lähetetään Mailgunin kautta, hoidetaan lähettävän tahon varmennus normaalien rajapintakutsujen autentikointimenetelmillä. Tämä tarkoittaa, että lähetys voidaan tehdä joustavasti melkein mistä vain, kunhan Mailgun pysyy luotettavana lähettäjänä domainille. Koska roskapostittajien toiminta perustuu huippumassiiviseen volyymiin, eivät Mailgun ja muut vastaavat maksulliset palvelut ole heille varteenotettavia vaihtoehtoja.

Hopealuotia roskapostiongelman taklaamiseen ei ole. SPF, DKIM ja DMARC ovat askeleita oikeaan suuntaan, mutta matkaa on vielä reilusti taitettavana. Sähköpostin kanssa toimiminen muuttuu siis aina vain vaikeammaksi.

Lue myös: Miksi sähköposti menee roskapostiin