Kuuldused e-posti surmast on jätkuvalt liialdatud

Sõltumata regulaarsetest uutest e-posti killeritest on e-post, nagu me seda tunneme, püsinud enam-vähem samasugusena juba aastakümneid. Loomulikult on juurde tulnud uusi võimalusi nagu näiteks manuste kasutamine või täpitähtede tugi, mida e-posti esimesed versioonid sugugi ei tunnistanud, kuid see on reeglina alati olnud olemasoleva lahenduse raamides toimetamine, mitte millegi päriselt uue lisamine (manusega kiri oleks täiesti loetav ka manuse-eelse ajastu e-posti kliendiga, see lihtsalt näeks kummaline välja). Samal ajal on Google Wave, Slack, Facebook, WhatsApp ja teised e-posti alternatiivid lisanud loetamatul hulgal täiendusi, nii kasutajakogemuse kui turvalisuse vallas, mida e-postis kas senini ei ole või ei saagi kunagi olema.

E-posti areng on väljastpoolt vaadates kohutavalt aeglane, viimaste aastate suurim täiendus e-posti standardites on olnud täpitähtede tugi e-posti aadressi kasutajanime osas (domeeni osas olid täpitähed juba varem lubatud), näiteks андрис@уайлддак.орг on nende uuenduste alusel täiesti korrektne ja toimiv aadress. Samas suurem osa e-posti servereid selliseid aadresse endiselt ei toeta, kuna vastav standard on “alles” 6 aastat vana.

E-post elab ikka veel

Miskipärast ei ole e-posti kasutamine, hoolimata selle piiratud võimalustest ja üliaeglasest muutumisest kuhugi kadunud – vastupidi, selle tähtsus on ajas aina kasvanud. Tõsi, korrespondentsi laad ei ole võibolla püsinud päris sama. Täna me ei leia oma e-postkastist mitte niivõrd otsesuhtlust oma sõprade või lähedastega (selle jaoks on välksuhtlusrakendused tõesti paremad), vaid uudiskirju, paroolimeeldetuletusi, elektrooniliste teenuste kviitungeid, kõikvõimalikke teavitusi, tuttavate tehtud fotosid ühistest üritustest jmt.

Lisaks muutunud sisule on e-postkast sarnaselt päris postkastiga muutunud rohkem globaalse identiteedi osaks, selmet olla vaid suhtluskanal – Jaan Tammesid võib olla maailmas palju, aga konkreetsel aadressil elab siiski neist vaid üks. Facebookis on samanimelisi inimesi palju, aga igaühel neist on unikaalne e-posti aadress. E-posti aadress on seega sarnane läänemaailma kurikuulsate gaasiarvetega, mida tahetakse pangakonto avamisel näha. Kuigi e-post pole selleks üldse mõeldud ja riiklikult täiesti sanktsioneerimata, on praktikas tegu identiteedi tunnusega.

Failisüsteemi rõõmud ja mured

Muutunud sisu on jätnud oma jälje ka kasutaja e-postkasti majutavale ressursile. Uudiskirja peen HTML kood ja kujundus on mahult hoopis erinev välkteatest sõbrale. Kirjade kustutamise asemel kuhjatakse need erinevatesse kaustadesse, nii et mõnes kaustas on varasema 200 asemel 200 000 kirja. Moodsa telefoniga saadetud foto on suurem, kui kunagi ammu olid mitme aasta kirjad kokku. Mis siis veel sellest rääkida, kui see foto saadetakse mitte ühele inimesele, vaid kõikidele samal üritusel viibinutele. Mäletan isegi kuidas kunagises töökohas saatis postiserveri administraator kõigile kurja kirja, kui inimesed töökaaslastele ühte ja sedasama koerapilti edastasid ning sellega serveri töövõime ohtu seadsid.

Samas, kui nüüd vaadata, et kuidas on e-posti serveri tarkvara (eelkõige pean silmas kõigile kättesaadavat avatud lähtekoodil põhinevat tarkvara) nende muutustega kaasas käinud, siis selgub, et väga nagu ei olegi. Riistvara on odavam ja kiirem kui varem, seega piisab reeglina lihtsalt tarkvara seadistuses määrata endise 10MB postkasti suuruse asemel 10GB ning ongi nagu kõik korras. Enamikel juhtudel ongi korras, kümne inimese 10GB postkastide jaoks läheb serveris vaja kuni 100GB kõvaketast, mis ei ole tänapäeval mingi suurus. Probleemid tekivad siis, kui tegu on juba suurema hulga kui toatäie inimeste postkastide majutamisega. 1000 inimese postkastide majutamiseks läheb vaja 10TB kõvakettaruumi, 10 000 inimese jaoks juba 100TB jne.

Reeglina ei ole inimestel postkast kogu aeg servani täis, mis annab mõningase võimaluse paigutada serverisse rohkem postkaste, kui sinna tegelikult mahuks. Samas aga tähendab see pidevat monitoorimist, et kui täis või tühi mingi server tegelikult on ja vajadusel migreerida kasutajaid, tuleb liigutada suuri postkaste tühjematesse serverisse ja teha muid sarnaseid tegevusi. Klassikaliselt asuvad kasutaja kõik kirjad kas ühesainsas failis (mbox formaat) või ühes kaustas (maildir formaat), igal juhul tähendab kasutaja migreerimine, et ümber ei tule kolida mitte neid kirju, mis serverisse ära ei mahu, vaid terve postkast koos saba ja sarvedega.

Mõningase leevenduse annavad teinekord skaleeruvad võrgupõhised failisüsteemid nagu GlusterFS, kuid sõltuvalt kasutatud tarkvarast võib tekkida ootamatuid ja seletamatuid probleeme – tarkvara eeldab failisüsteemilt reeglina sellist käitumist, milleks võrgupõhine kuidagi võimeline pole, st. et süsteem peaks olema korraga kiire ja usaldusväärne. Failisüsteemi toimingud (näiteks faili ümbernimetamine, mis on maildir puhul väga tüüpiline tegevus) teostatakse koheselt ja enam-vähem konstantse kiirusega ning üldiselt need toimingud ka õnnestuvad, võrk aga on tunduvalt ebakindlam. Tavaliselt kõik toimib, aga siis, ühel hetkel, võtab faili ümbernimetamine aega 10 sekundit. Iseenesest mis siis sellest, aga kui tavaliselt võib lugeda sellise tegevuse kestust pigem milli- või isegi mikrosekundites, siis 10 sekundit on sellest 10 000 korda aeglasem. Lisame patta veel samal ajal kuhjuvad muud ootel tegevused (ka kõik ülejäänud kasutajad tahavad samal ajal oma postkastis muudatusi teha) ja saamegi tulemuseks väikese kaose.

Üks häda ja viletsus

IMAP protokoll, mille abil kasutajad oma e-kirju serverist alla laevad, on algselt disainitud olema skaleeruv, kus eeldatakse, et kasutaja võib ühenduda korraga erinevate serverite pihta kuna e-posti server ei pea otseselt olema seotud kirjade hoiustamisega. Selline disain tuli reaktsioonina ülimalt piiratud POP3 protokollile, kus, vähe sellest, et ei saa sama kasutaja paralleelselt pöörduda erinevate serverite poole, ei saa kasutaja paralleelselt üldse midagi teha ning peab piirduma üheainsa ühendusega. Samas praegused IMAP implementatsioonid on tavaliselt jäigalt failisüsteemiga seotud ja nendes implementatsioonides ei saa kasutaja päringuid hajutada, kuigi protokoll seda isegi võimaldaks. Ka Dovecot Director puhul, mis on kättesaadavatest lahendustest senini parim, satuvad sama kasutaja paralleelsed ühendused alati samasse serverisse (kuigi tõsi, see server võib aja jooksul vahelduda).

Veel üks keeruline küsimus e-posti puhul on autentimine. Esiteks on autenditavaid kohti palju – veebimeil, IMAP, POP3, SMTP ning kõiki neid tuleks kuidagi eraldi kohelda. Kui me tahame pakkuda veel kahefaktorilist autentimist, rakendusepõhiseid paroole, autentimislogi, ajas uuenevat parooliräsi algoritmi jmt. siis, kuigi võimalik, tähendab see olemasolevate rakenduste korralikku häkkimist.

Meilirakenduste monitoorimine on samuti olnud üldiselt paras peavalu. Loomulikult on olemas kõiksugu tööriistad e-posti järjekordade haldamiseks, kuid suures osas tähendab see failisüsteemis perioodilist failide ülelugemist või paremal juhul meiliserveri logifailide analüüsimist. Tõenäoliselt jääb meile meiliserveri kõhus toimuv siiski parajaks mustaks auguks. Siin tuleb jälle mängu sama kana ja muna probleem, et meilisüsteem asub reeglina ainult ühes masinas. Sellises seadistuses on ühes masinas loomulikult ka logifailid ja seega, kuigi võib-olla ebamugav, on neid logifaile võimalik töödelda standardsete utiliitidega nagu grep, awk ja sõbrad. Jaotame aga meilinduse mitmesse serverisse laiali ja kohe ongi pilt eest läinud, et mis täpselt toimub.

Üks tüüpiline puudujääk e-posti serverite tarkvaras on muutuste jälgimine kasutaja kontol. Näiteks kui kasutaja loob ühes meilirakenduses IMAP protokolli kaudu uue kausta, või veel hullem – nimetab mõne olemasoleva kausta ümber, siis sama kasutaja teine seade ei saa sellest mitte kuidagi teada. Muutused kaustadega ilmnevad üsna pea, sest reeglina teevad meilikliendid peale uue ühenduse avamist kaustade listingu, kuid esiteks võtab see aega ning teiseks, ümbernimetamiste puhul see ei aita, meilikliendi jaoks paistab selline kaust olevat uus kaust uute kirjadega, mis tuleb jälle alla tõmmata, samas kui ümbernimetatud kaust koos selles olnud kirjadega kustutatakse ära. Hea küll, IMAP klient on piiratud kasutatava protokolliga, aga sama kandub üle ka veebimeili rakendustele, mis reeglina on samuti taustal IMAP kliendid.

Ning kui veebimeil juba jutuks tuli, siis veebimeil üle IMAP protokolli on paras kaos. Heal juhul istub veebimeili rakenduse ja IMAP serveri vahel mingisugune kolmas rakendus, mis hoiab ühendusi IMAP serveri suunas lahti, aga reeglina tähendab siiski iga uus päring kliendi poolelt kogu IMAP tsirkuse taasmängimist – ühenduse avamine (sh. TLS “käepigistus”), serveri võimaluste küsimine, kasutaja autentimine, kausta avamist ning alles seejärel toimingut kirjaga (näiteks selle loetuks märkimist). IMAP protokolli kasutamine ning RFC822 vormingus e-kirjade haldamine teeb veebimeili arenduse ülimalt keerukaks ja aeganõudvaks. Populaarse veebimeili tarkvara Roundcube uue versiooni arenduseks mõeldud rahakogumise kampaania lõppes edukalt juba 3 aastat tagasi, aga siiani peame leppima vana versiooni kasutamisega.

Mida siis teha?

Väikestel pakkujatel taolisi skaleeruvusprobleeme, kus kasutajad enam ühte või paari serverisse ära ei mahu, üldiselt ei ole ning nemad saavad vabavara peal hakkama. Suured e-posti teenuse pakkujad on lahendanud skaleeruvusprobleemid ennekõike omaenda vajadustele vastava tarkvara arendusega, kus failisüsteemi asemel on kohe kasutuses skaleeruvad võrgusüsteemid ning tarkvara ei oota failisüsteemi tavapäraseid garantiisid, kuid need ei ole siis enam vabavaralised lahendused. Zone, kus postkastide arvu loetakse kuuekohalise numbriga, on selles suhtes olnud veidi õnnetus positsioonis, et tegu ei ole ammu enam väikese pakkujaga, aga maailma mastaabis ka mitte suurega. Olemasolevad vabavaralised lahendused jäävad kitsaks, kuid suurte poolt kasutatavad e-posti lahendused jäävad käeulatusest välja. Ainus mõeldav variant kuni senimaani oleks olnud Dovecoti kommertslahendus koos Dovecoti Directori ning object storagega.

Zones läksime siiski teist teed ning ka meil on nüüd kasutusel maja sees ehitatud (kuid siiski vabavaraline) e-posti süsteem, mis vastab paremini reaalsetele nõudmistele.

Featuuridest, seekord positiivse noodiga

Kirju ei hoita enam failisüsteemis, vaid need on laiali suures MongoDB sharditud klastris. See tähendab, et kui kasutaja rakendus teeb kirjade listingut, siis osad kirjad sellest listingust võivad asuda ühes, aga osad hoopis teises shardis. Samuti on kirjad ise osadeks jaotatud, kus manused on serveri pool kirjadest eraldatud ning võivad asuda hoopis mujal. Alles kliendi päringu peale otsitakse need erinevad jupid klastris pealt kokku ja esitatakse kasutajale tavalise e-kirjana. Selle kohta võiks öelda, et tegu on üsna tüüpilise pilve-mudelil töötava lahendusega.

Veebimeili puhul võib IMAP protokolliga seonduva osa täiesti vahele jätta ning saame meiliserverist küsida andmeid üle standardse REST API. Kusjuures kogu töö e-posti vormindusega jääb serveri kanda, nii et veebimeil ei pea midagi teadma MIME-kodeeringutest ega sellest, et kuidas manuseid kirjadest kätte saada. Sama API annab koheselt teada ka kõikidest kontol toimunud muutustest, sealhulgas siis kaustade ümbernimetamisest ning kirjade lisandumistest/kustutamisest.

Keskne autentimissüsteem võimaldab granulaarset haldust, kus kasutajal võib olla mitu erinevat parooli ning igal paroolil saavad olla erinevad õigused mingite toimingute teostamiseks. Samuti võimaldab see paremini paroolide kasutamist logida ning seda logi kasutajale vajadusel ka näidata.

Iga tegevuse kohta on võimalik saata struktureeritud infot kas Greylogi või muusse sarnasesse logiserverisse, väljuvate kirjade queue seis on loetav Prometheuse formaadis, nii et sisepilt e-posti serveri töösse on tunduvalt parem ning anomaaliad kergemini tuvastatavad.

Lõpetuseks

Kõiki lisandunud võimalusi ei hakkagi üles lugema, muidu ei jää uuteks blogipostitusteks enam materjali. Kokkuvõtvalt võib küll tõdeda, et sellise e-posti süsteemi arendus ei ole olnud lihtne, see on võtnud kaua aega, aga loodetavasti on tulemus seda väärt. Siiani ei ole keskmise suurusega e-posti teenuse pakkujatele sobivat platvormi leidunud, eelkõige mõeldes siis muutunud kasutajaharjumuste ning postkastide suuruse peale, nüüdsest võibolla siis on.