E-kirjade suunamine serverite vahel võib olla üllatavalt keeruline. Seletame, kuidas seda viisakalt teha.

Hiljuti tekkis meil probleem e-kirjade ümbersuunamisega, kus klient on teinud endale ümbersuunamisaadressi, näiteks minu-pere@minudomeen.ee ja iga sellele aadressile saadetud kiri edastatakse siis kliendi poolt määratud sihtkoha aadressidele. Aga enne, kui vaadata mis probleem see täpselt oli ja mis oli lahenduseks, vaataksime kõigepealt üldse kirjade liikumise ja ümbersuunamise tausta.

Kirjade ümbsuunamine toimub reeglina nii, et saatev MTA server (Message Transfer Agent), näites saatjadomeen.ee, otsib välja saaja ehk minudomeen.ee e-posti MX serveri (Mail Exchange) aadressi ja saadab sinna üle SMTP protkolli oma kirja nagu iga teise kirjagi.

saatjadomeen.ee MTA -> minudomeen.ee MX
MAIL FROM: <saatja@saatjadomeen.ee>
RCPT TO: <minu-pere@minudomeen.ee>

Vastuvõttev minudomeen.ee MX server omakorda näeb oma seadistustest, et kasutaja minu-pere näol on tegu hoopis ümbersuunamisaadressiga, kirjutab selle puhul SMTP ümbrikul saaja aadressi ringi ning saadab kirja koopiad siis omakorda edasi juba tegelikesse e-posti MX serveritesse. Eelnevalt näidatud SMTP ümbriku asemel võiks ümbrik nüüd välja näha hoopis järgmine (esialgne saaja on asendatud kolme uue saaja aadressiga):

MAIL FROM: <saatja@saatjadomeen.ee>
RCPT TO: <isa@isadomeen.ee>
RCPT TO: <ema@emadomeen.ee>
RCPT TO: <laps@lapsdomeen.ee>

Nüüd jõuab kiri kõigepealt isadomeen.ee MX serverisse, kes näeb sissetuleva kirja ümbrikut järgmiselt:

minudomeen.ee MX -> isadomeen.ee MX
MAIL FROM: <saatja@saatjadomeen.ee>
RCPT TO: <isa@isadomeen.ee>

Ja siin tekibki probleemne koht. Nimelt on vastuvõtva MX serveri jaoks saatvaks MTA serveriks mitte saatjadomeen.ee nagu MAIL FROM aadressi järgi SMTP ümbrikult seda eeldada võiks, vaid hoopis meie ümbersuunav MTA server minudomeen.ee, sest ühendus kirja edastamiseks tuleb justnimelt sealt.

Ajalooliselt ei ole see olnud eriline mure, sest algselt oligi kogu e-posti süsteem mõeldud kirju edastama läbi suvaliste MTA serverite. Sarnaselt töötab ka tigupost, kus kirja võib jätta suvalisse postkontorisse ning see võib liikuda samuti läbi erinevate kontorite, kuni lõpuks kohale jõuab. Kui Saksamaalt Eestisse pakki saates läheb postkontoris Estland ja Island segamini ning pakk seetõttu hoopis valesse kohta jõuab, pole sellest suurt lugu, sest avastades vea, saadavad Islandi postitöötajad selle paki lõpuks ikkagi Eestisse (true story). Sama lugu on ka e-postiga, iga MTA või MX server peaks teoorias suutma leida parima võimaliku järgmise serveri, kuhu mingi kiri saata, isegi kui see kiri on saabunud kuidagi kogemata või valesti.

Paraku asusid spämmerid sellist hajusat ümbersuunamist kiirelt ära kasutama, näiteks saates jälgede segamiseks oma spämmikirjad üle maailma erinevatesse MTA serveritesse, lootuses et kõik need serverid siis edastavad kirja lõpuks tegelikule spämmi saaja MX serverile. Saaja jaoks paistab, et kirjad tulevad eri kohtadest ja seega ei saa sellist spämmi ka kergesti blokeerida, kuna tegelik spämmisaatja ei ole lihtsalt teada. Spämmeritega võitlemiseks keelatigi esimesena niiöelda avatud releed ehk sellised meiliserverid, mis võtavad kirju vastu suvalistest kohtadest ja edastavad need suvalistesse kohtadesse. Keelamine siinkohal ei tähenda, et mingi organisatsioon või kohus oleks seda teinud, taolised avatud releed pannakse lihtsalt erinevatesse mustadesse nimekirjadesse ning mustas nimekirjas olevast serverist ei võta ükski endast lugupidav MX server kunagi kirju vastu (musta nimekirja võib pidada kas igaüks ise või siis osta kuskilt sisse või kasutada mõnd avalikku teenust).

Kui kirju saatev meiliserver ei ole avatud relee (võtab kirju vastu ainult kindlatest võrkudest või nõuab eelnevat autentimist), siis ei ole see ka üheski mustas nimekirjas ja seega nagu ei tohiks probleemi olla. Nüüd tuleb mängu järgmine spämmimistaktika ehk kirja saatja andmete võltsimine. Spämmer saab enda käsutusse mõne enamvähem talutava reputatsiooniga meiliserveri ja saadab välja oma spämmikirja, kuid saatjaks märgib mõne reaalse isiku andmed, kes ise ei tea sellest midagi. Kuna saatev MTA ei ole mustas nimekirjas, siis võiks MX selle kirja nagu isegi vastu võtta. Samas, ilmselgelt ei meeldi kellelegi kui nende identiteeti kasutatakse kolmandatele isikutele spämmi saatmiseks ja seetõttu mõeldi välja taolise saatja andmete võltsimise vastu SPF (Sender Policy Framework) reeglid. Lühidalt tähistab see kirjet domeeni nimeserveris, mis määrab ära, et millistest serveritest võib selle domeeni aadressidega kirju välja saata.

Tulles tagasi meie näite juurde näeks vastuvõttev MX nimega isadomeen.ee, et kirja saatjaks on saatja@saatjadomeen.ee. Kontrollides SPF DNS kirjet, leiaks MX, et saatjadomeen.ee aadressidega kirju tohib saata ainult saatjadomeen.ee MTA serverist, samas kui tegelik MTA on hoopis meie ümbersuunav MX nimega minudomeen.ee. Üldiselt ei tähenda selline olukord veel, et kiri jääks vastu võtmata. Läbi aastate on üles seatud meeletus koguses igasugu postiloendeid jmt. mis ei oska sellise piiranguga arvestada (SPF on e-posti kümnete aastate pikkuse ajaloo juures suhteliselt hiline nähtus) ning kust tuleb siiski autentne e-post, mitte spämm.

SPF’il on kaks reeglit, lõtv ja range, lisaks on võimalik täpsemat käitumist reguleerida DMARC (Domain Message Authentication Reporting & Conformance) reeglitega. Lõdva režiimi puhul võetakse kiri igal juhul vastu, aga kirjale võidakse määrata mittekorrektse SPF tõttu spämmipunkte (spämmipunkte võidakse anda kirjale paljude erinevate asjade eest ning kui summeeritud punktid ületavad mingi kindla piiri, siis loetaksegi kiri spämmiks). Range SPF reegli korral aga on olukord juba segasem. Mõned serverid ei võta sellist kirja üldse vastu, mõni võtab, aga annab rohkem spämmipunkte, mõni ei arvesta sellega üldse jne.

Ühesõnaga, siiani ei ole kirjade suunamine olnud eriline probleem, kuid mida aeg edasi, seda rohkem king pigistama hakkab. Inimesed kasutavad rohkem SPF ja DMARC reegleid, sh. ka ranget režiimi (kusjuures ise tihti seda üldse teadmata, kuna see seadistus võib tulla teenusepakkuja poolt juba automaatselt kaasa). Üha rohkemad MX serverid samas ka reaalselt arvestavad SPF seadetega ning lükkavadki selle põhjal kirju tagasi. Samuti on paljud serverid seadistatud lubama omaenda domeenidele kirjade saatmist ainult läbi omaenda serveri. Näiteks kui server, mis vastutab isadomeen.ee kirjade eest (st. et saadab neid välja ning samuti võtab nendele aadressidele mõeldud posti internetist vastu), saab nüüd internetist kirja, mille saatja on väidetavalt samuti isadomeen.ee, siis võib see loomulikult tunduda piisavalt kahtlane, et see kiri ära blokeerida.

Sellele olukorrale, kus korrektne ümbersuunaja tahab niiöelda “valest” serverist kirju edastada, on olemas ka lahendus, nimelt SRS (Sender Rewriting Scheme). SRS defineerib viisi kuidas ümbersuunav MTA võib saatja aadressi ümber kirjutada, et järgmisele serverile paistaks saatjaks mitte enam esialgne, vaid ümbersuunav server. Seega SRS kasutamise korral näeks vastuvõttev domeen kirja ümbrikut hoopis nii:

minudomeen.ee MX -> isadomeen.ee MX
MAIL FROM: <SRS0=HHH=TT=saatjadomeen.ee=saatja@minudomeen.ee>
RCPT TO: <isa@isadomeen.ee>

Nüüd paistab kiri olevat saadetud minudomeen.ee aadressilt ja minudomeen.ee serverist, seega kõik klapib ja midagi blokeerida ei ole vaja. Kui kirja vastuvõtmisel tekib probleem (näiteks on addressaadi postkasti maht täis ja kirja ei ole võimalik sinna salvestada) ning vastuvõttev MX server saadab selle kohta saatjale teavituse, oskab minudomeen.ee teavitust vastu võttes sellisest SRS aadressist välja lugeda tegeliku saatja ning omakorda teavituse sellele edasi suunata.

Ühesõnaga, kuna taolisi olukordi, kus ümber suunatud kirju ei tahetud vastu võtta, hakkas tekkima juba liiga palju, tuligi mõte samuti SRS aadressidele üle minna. Murekohaks sai, et kuidas? E-posti liigutab meil eelkõige Postfix ning sellele on olemas ka SRS pluginad, kuid Postfix on selline imeloom, mis töötab väga paljudel erinevatel platvormidel, nii vanadel kui uutel. Kuigi sobiv SRS plugin oli isegi olemas, ei olnud seda võimalik meie olemasolevas keskkonnas tööle saada, sest Postfixi pluginate tööle saamine sõltub sellest, kas ka plugina autor on arvestanud kõigi nende platvormidega, kus Postfix töötada võib või mitte.

Lisaks, kui juba midagi muutma hakata, siis võiks vaadata ka muid külgi peale aadresside ümberkirjutamise. M³AAWG (Messaging, Malware and Mobile Anti-Abuse Working Group) on määranud ära parimad praktikad igasuguste kirjade ümbersuunamiste kohta ja seal on punkte rohkem kui üks. Näiteks tuleks ümbersuunava MTA serveri IP hoida lahus ülejäänud süsteemist, teostada kirjadele spämmikontrolli jne.

Kus häda kõige suurem, seal abi kõige lähem. Olin juba mõnda aega meie laboris nikerdanud ühe katselise uue MTA serveri rakenduse kallal, nimega ZoneMTA, millele oleks SRS toe tekitamine olnud vaid 10 realise pluginaskripti lisamine. IP aadresside eraldamine, vastavalt M³AAWG soovitusele, oleks ZoneMTA korral olnud samuti lihtne, kuna rakendus oskab saata kirju erinevate IP aadresside pealt, eeldusel muidugi et konkreetne server saab neid IP aadresse kasutada.

IP aadressid tuleb põhisüsteemist eraldi hoida eelkõige suure spämmiriski tõttu, sest me ei saa olla kindlad, et mis kirjad need üldse on, mida me edasi suuname. Nii võib juhtuda, et edastame kogemata spämmi ja meie IP aadress läheb seetõttu mõnda musta nimekirja. Juhul kui saadame sama IP kaudu prioriteetsemat e-posti, tekib ka selle edastamisega probleeme, nii et IP aadresside lahushoidmine võtaks sellist riski kohe väiksemaks. Esimese hooga sai ümbersuunamise teenusele eraldatud kolm IP aadressi, mille vahel hajutatakse väljuvad ümbersuunatavad kirjad ära ning saajale tundub nagu kirjad tuleks kolmest erinevast serverist, kuigi tegelikult tulevad kõik ühest ja samast kohast. Taoline hajutamine aitab üle saada ka murest, kus niiöelda tundmatult IP aadressilt hakkab äkitselt liikuma suures koguses e-kirju, mis paneb kõiksugu spämmikontrollide punased tuled kohe põlema. Kolme erineva IP aadressi vahel hajutades on iga erineva aadressi koormus – ja selle võrra ka oht sattuda kahtlaste saatjate nimekirja – palju väiksem.

Lisaks aadresside eraldamisele tuleb muidugi kontrollida, et ega me ilmselget spämmi ei edasta. Väljuva spämmi kontrollimine on osaliselt keerukam, kui sisenevate kirjade puhul, kuna sisenemisel saab kahtlased kirjad suunata spämmikausta. Väljuvate kirjade puhul peame aga olema täiesti kindlad, et tegu on spämmiga, sest muidu tekib oht kustutada ka õigeid kirju. Spämmikausta puhul saab kasutaja ise sealsed kirjad üle vaadata ja õiged kirjad tagasi postkasti tõsta, samas kui teekonnal kustutatud kirju ei saa enam keegi kuidagi tagasi.

Spämmikontrolli lisamiseks oli mõte kasutada Rspamd rakendust. See on küll veidi toores, dokumentatsioon ei ole ülemäära põhjalik ning kohati esinevad mingid anomaaliad (näiteks ei saanud kirja sisu Rspamd deemonile saata suuremate kui 12kB lõikude kaupa, vastasel korral läksid andmed kaduma). Samas on tegu üsna ressursisõbraliku lahendusega, mis suudab ilma erilise vaevata vaadata läbi väga kiiresti suures koguses kirju. Tipphetkedel käib süsteemist läbi umbes 30 kirja sekundis ning Rspamd’d, mis kõik need kirjad ka läbi vaatab ja neile oma hinnangu annab, ei pane serveris eriti tähelegi.

Kuna valepositiivsete kirjade kustutamise oht on üsna suur, kustutame ainult need kirjad, mille spämmipunktid on väga kõrged, näiteks sellised, mis sisaldavad teadaolevaid phishingu linke (andmed selle jaoks tulevad OpenPhish ja PhishTank teenustest). Keskmiselt on ainult 2 protsenti kirjadest olnud selge spämm, mida me edasi saatma ei hakkagi. Sellistele kirjadele, mis tõenäoliselt on spämm, kuid ei pruugi seda olla (13% kirjade kogumahust), paneme kirja päisesse vastavad spämmi träkkimise päisekirjed, kuid sellise kirja liikumist kuidagi takistama siiski ei hakka.

Praeguseks saadab süsteem välja rohkem kui miljon kirja nädalas ning SenderScore on määranud kõik kastutusel olevad IP aadressid kategooriasse Very High Volume Sender ning hinnanud neid punktidega 97 või 98 võimalikust sajast. Kui suurem spämm jääks maha korjamata, siis me kindlasti nii kõrgeid punkte ei saaks. ZoneMTA tarkvara ise on veel üsna toores ja vajab kohati käehoidmist (sellest, et mis probleemid kaasnevad MTA tarkvara ehitamisel, tuleb kindlasti kunagi üks põhjalikum blogipostitus), seega seda kellelegi soovitada veel ei julgeks, kuid meie probleemid kirjade ümbersuunamisega on see praeguseks sisuliselt juba lahendanud.