Kvantumálló e-mail: Hogyan használjuk a titkosított SQLite postafiókokat az e-mailek biztonságának megőrzése érdekében

Előszó

A IMAP-támogatás elindítása előtt a MongoDB-t használtuk az állandó adattárolási igényeinkre.

Ez a technológia lenyűgöző, és még ma is használjuk – de ahhoz, hogy a MongoDB-vel inaktív titkosítást használjunk, olyan szolgáltatót kell használnunk, amely MongoDB Enterprise-t kínál, például a Digital Oceant vagy a Mongo Atlast – vagy vállalati licencet kell fizetnünk (és ennek következtében az értékesítési csapat késleltetésével kell foglalkoznunk).

A E-mail továbbítása csapatának egy fejlesztőbarát, skálázható, megbízható és titkosított tárolási megoldásra volt szüksége IMAP postaládákhoz. Nyílt forráskódú fejlesztőkként a alapelveink ellentmondott egy olyan technológia használatának, amelyhez licencdíjat kell fizetni a titkosítás inaktív állapotban funkció használatáért – ezért kísérleteztünk, kutattunk és a nulláról fejlesztettünk ki egy új megoldást ezen igények kielégítésére.

Ahelyett, hogy megosztott adatbázisban tárolnánk a postaládáit, azokat egyenként tároljuk és titkosítjuk a jelszavával (amelyet csak Ön birtokol). E-mail szolgáltatásunk olyan biztonságos, hogy ha elfelejti jelszavát, akkor elveszíti postaládáját (és offline biztonsági mentésekkel kell helyreállítania, vagy újra kell kezdenie az egész folyamatot).

Olvasson tovább, mivel alább részletesen bemutatjuk a e-mail szolgáltatók összehasonlítása, hogyan működik a szolgáltatásunk, a technológiai rendszerünk és további elemeket.

E-mail szolgáltató összehasonlítása

Mi vagyunk az egyetlen 100%-ban nyílt forráskódú és adatvédelmet szem előtt tartó e-mail szolgáltató, amely egyedileg titkosított SQLite postaládákat tárol, korlátlan számú domaint, aliast és felhasználót kínál, valamint támogatja a kimenő SMTP, IMAP és POP3 e-maileket:

Más e-mail szolgáltatókkal ellentétben a Forward Email esetében nem kell domainenként vagy aliasonként fizetni a tárhelyért. A tárhely a teljes fiókod között megosztott – tehát ha több egyéni domainneved és mindegyikhez több aliasod van, akkor mi vagyunk a tökéletes megoldás számodra. Fontos megjegyezni, hogy továbbra is beállíthatsz tárhelykorlátokat domainenként vagy aliasonként.

Olvassa el az e-mail szolgáltatások összehasonlítását

Hogyan működik?

1. Az Apple Mail, a Thunderbird, a Gmail vagy az Outlook levelezőprogram használatával a felhasználónevével és jelszavával csatlakozik biztonságos IMAP szervereinkhez:

• A felhasználóneved a domainedhez tartozó teljes aliasod, például hello@example.com.
• A jelszavad véletlenszerűen generálódik, és csak 30 másodpercig jelenik meg számodra, amikor a Jelszó generálása lehetőségre kattintasz a Fiókom Domainek Aliasok menüpontból.

2. A csatlakozás után az e-mail kliens elküldi a IMAP protokollparancsok üzenetet az IMAP-szerverünknek, hogy a postaládád szinkronban maradjon. Ez magában foglalja az e-mailek piszkozatainak írását és tárolását, valamint egyéb műveleteket, amelyeket elvégezhetsz (pl. egy e-mail megjelölése fontosként vagy egy e-mail megjelölése spamként/levélszemétként).

3. A levelezőszerverek (közismert nevén „MX” szerverek) fogadják az új bejövő e-maileket, és tárolják azokat a postaládádban. Amikor ez megtörténik, az e-mail kliens értesítést kap, és szinkronizálja a postaládádat. Levelezőszervereink képesek továbbítani az e-maileket egy vagy több címzettnek (beleértve a webhookok címzettet is), tárolni az e-maileket a titkosított IMAP tárhelyünkön, vagy mindkettőt!

4. A színfalak mögött biztonságos e-mail-tárolási megoldásunk kétféleképpen működik, hogy postaládái titkosítva legyenek, és csak Ön férhessen hozzájuk:

• Amikor új levelet kapsz egy feladótól, levelezőszervereink egy egyedi, ideiglenes és titkosított postafiókba írják az e-mailt.

  

• Amikor levelezőprogramjával csatlakozik az IMAP-kiszolgálónkhoz, jelszavát a memóriában titkosítjuk, és a postaládájába való írásra és olvasásra használjuk. A postaládájából csak ezzel a jelszóval lehet olvasni és írni. Ne feledje, hogy mivel Ön az egyetlen, aki rendelkezik ezzel a jelszóval, csak Ön tudja olvasni és írni a postaládáját, amikor hozzáfér hozzá. Amikor a levelezőprogram legközelebb megpróbál leveleket lekérdezni vagy szinkronizálni, az új üzenetei ebből az ideiglenes postaládából kerülnek át, és a megadott jelszóval tárolódnak a tényleges postaládafájlban. Vegye figyelembe, hogy ez az ideiglenes postaláda utána törlődik, így csak a jelszóval védett postaládájában találhatók meg az üzenetek.

• Ha IMAP-hoz csatlakozol (pl. egy e-mail klienst, például Apple Mailt vagy Thunderbirdet használsz), akkor nem kell ideiglenes lemezre írnunk. Ehelyett a memóriában tárolt titkosított IMAP-jelszavadat kérjük le és használjuk. Valós időben, amikor egy üzenetet megpróbálunk kézbesíteni neked, egy WebSocket kérést küldünk az összes IMAP-kiszolgálónak, megkérdezve tőlük, hogy van-e aktív munkamenetük az számodra (ez a lekérés része), majd ezt követően továbbítjuk ezt a titkosított, memóriában tárolt jelszót – így nem kell egy ideiglenes postaládába írnunk, hanem a tényleges titkosított postaládádba írhatunk a titkosított jelszavaddal.

  

5. A Titkosított postaládáinak biztonsági mentései elemek naponta készülnek. Bármikor kérhet új biztonsági mentést, vagy letöltheti a legújabb biztonsági mentést a Fiókom Domainek Aliasok menüpontból. Ha úgy dönt, hogy másik e-mail szolgáltatásra vált, bármikor könnyedén migrálhatja, letöltheti, exportálhatja és törölheti postaládáit és biztonsági mentéseit.

Technológiák

Adatbázisok

Más lehetséges adatbázis-tárolási rétegeket is megvizsgáltunk, de egyik sem elégítette ki annyira az igényeinket, mint az SQLite:

Adatbázis	Inaktív titkosítás	Sandboxed Postaládák	Engedély	Used Everywhere
SQLite :csillag:	✅ Igen, SQLite3MultipleCiphers címmel	:fehér_pipa_jel:	✅ Közkincs	:fehér_pipa_jel:
MongoDB	❌ "Available in MongoDB Enterprise only"	❌ Relációs adatbázis	❌ AGPL és SSPL-1.0	❌
rqlite	❌ Network only	❌ Relációs adatbázis	✅ CELLA_KÓD_0	❌
dqlite	❌ Untested and not yet supported?	❌ Untested and not yet supported?	✅ CELLA_KÓD_0	❌
PostgreSQL	✅ Yes	❌ Relációs adatbázis	✅ PostgreSQL (hasonlóan a BSD vagy MIT-hoz)	❌
MariaDB	✅ For InnoDB only	❌ Relációs adatbázis	✅ GPLv2 és BUSL-1.1	❌
CockroachDB	❌ Enterprise-only feature	❌ Relációs adatbázis	❌ BUSL-1.1 és mások	❌

Itt egy blogbejegyzés, amely összehasonlítja a különböző SQLite adatbázis-tárolási lehetőségeket a fenti táblázatban.

Biztonság

Mindenkor titkosítás inaktív állapotban (AES-256), átvitel közbeni titkosítás (TLS), DNS HTTPS-en keresztül ("DoH") titkosítást használunk a postaládákon 🍊 Mandarin és sqleet (ChaCha20-Poly1305) titkosítással. Ezenkívül token alapú kétfaktoros hitelesítést (szemben az SMS-sel, amely a közbeavatkozó támadások által gyanúsítható), rotált SSH-kulcsokat használunk letiltott root hozzáféréssel, kizárólagos hozzáférést biztosítunk a szerverekhez korlátozott IP-címeken keresztül és egyebeket.

gonosz szobalány támadás vagy harmadik féltől származó, jogosulatlan alkalmazott esetén a postaládád továbbra is csak a generált jelszavaddal nyitható meg. Biztosíthatunk, hogy nem támaszkodunk harmadik féltől származó szolgáltatókra, kivéve a SOC Type 2 panaszkiszolgáló-szolgáltatóinkat, mint például a Cloudflare, a DataPacket, a Digital Ocean és a Vultr.

A célunk, hogy a lehető legkevesebb egyetlen meghibásodási pont legyen.

Postaládák

tldr; IMAP-szervereink minden egyes postaládájához külön-külön titkosított SQLite adatbázisokat használnak.

Az SQLite egy rendkívül népszerű beágyazott adatbázis – jelenleg a telefonján és a számítógépén fut – és szinte minden nagyobb technológia használja.

Például a titkosított szervereinken van egy SQLite adatbázis postafiók a linux@example.com, info@example.com, hello@example.com és így tovább számára – mindegyikhez egy .sqlite adatbázisfájlként. Az adatbázisfájlokat nem az e-mail címmel nevezzük el – ehelyett BSON ObjectID-t és egyedi UUID-kat használunk, amelyek nem osztják meg, hogy kihez tartozik a postafiók, vagy milyen e-mail cím alatt található (pl. 353a03f21e534321f5d6e267.sqlite).

Ezen adatbázisok mindegyike titkosítva van a jelszavaddal (amelyet csak te birtokolsz) a sqleet (ChaCha20-Poly1305) használatával. Ez azt jelenti, hogy a postaládáid egyenként titkosítottak, önállóak (homokozóban és hordozhatóak.

Finomhangoltuk az SQLite-ot a következő PRAGMA értékkel:

PRAGMA	Cél
cipher=chacha20	ChaCha20-Poly1305 SQLite database encryption. További információkért lásd a better-sqlite3-multiple-ciphers kódot a Projects alatt.
key="****************"	Ez a visszafejtett, csak memóriában tárolt jelszava, amely az e-mail kliens IMAP-kapcsolatán keresztül jut el a szerverünkhöz. Minden olvasási és írási munkamenethez új adatbázis-példányok jönnek létre és záródnak be (a sandboxing és az izoláció biztosítása érdekében).
journal_model=WAL	Előreírt napló ("WAL") which boosts performance and allows concurrent read access.
busy_timeout=5000	Megakadályozza az írászárolási hibákat while other writes are taking place.
synchronous=NORMAL	Növeli a tranzakciók tartósságát without data corruption risk.
foreign_keys=ON	Kikényszeríti az idegen kulcshivatkozások (pl. egy tábla és egy másik közötti reláció) kikényszerítését. By default this is not turned on in SQLite, de az érvényesítés és az adatintegritás érdekében engedélyezni kell.
encoding='UTF-8'	Default encoding a fejlesztői józanság biztosítása érdekében.

Minden más alapértelmezett érték az SQLite-ból származik, a hivatalos PRAGMA dokumentáció által meghatározottak szerint.

Párhuzamos működés

tldr; A WebSocket függvényt használjuk a titkosított SQLite postaládák egyidejű olvasásához és írásához.

Olvasás:

A telefonodon lévő levelezőprogramod feloldhatja a imap.forwardemail.net címet a Digital Ocean egyik IP-címünkre – az asztali kliensed pedig egy teljesen más szolgáltató címről feloldhat egy külön IP-címet.

Függetlenül attól, hogy melyik IMAP-kiszolgálóhoz csatlakozik az e-mail kliens, azt szeretnénk, hogy a kapcsolat valós időben, 100%-os pontossággal olvassa be az adatbázisból az adatokat. Ezt WebSockets-en keresztül végezzük.

Írja a következőt:

Az adatbázisba írás egy kicsit más – mivel az SQLite egy beágyazott adatbázis, és a postaládád alapértelmezés szerint egyetlen fájlban található.

Olyan lehetőségeket vizsgáltunk meg, mint a litestream, rqlite és dqlite, de egyik sem felelt meg az igényeinknek.

Ahhoz, hogy az írási műveleteket engedélyezve, az előzetes írási naplózás ("WAL") mellett végezzük, biztosítanunk kell, hogy csak egy szerver ("Elsődleges") legyen felelős ezért. A WAL jelentősen felgyorsítja a párhuzamos működést, és egy író, valamint több olvasó használatát teszi lehetővé.

Az Elsődleges szerver azokon az adatszervereken fut, amelyekhez a titkosított postaládákat tartalmazó csatlakoztatott kötetek tartoznak. Terjesztési szempontból a imap.forwardemail.net mögötti összes egyedi IMAP-szerver másodlagos szervernek („Másodlagos”) tekinthető.

Kétirányú kommunikációt valósítunk meg a WebSockets paraméterrel:

• Az elsődleges szerverek a ws WebSocketServer szerverének egy példányát használják.

A másodlagos szerverek a ws WebSocket kliensének egy példányát használják, amely a websocket-ahogy-ígért és a újracsatlakozó websocket kliensekkel van csomagolva. Ez a két csomagoló biztosítja, hogy a WebSocket újracsatlakozzon, és adatokat küldhessen és fogadhasson adott adatbázis-írásokhoz.

Biztonsági mentések

tldr; A titkosított postaládákról naponta készülnek biztonsági mentések. Bármikor azonnal kérhet új biztonsági mentést, vagy letöltheti a legújabb biztonsági mentést a Fiókom Domainek Aliasok menüpontból.

Biztonsági mentések esetén egyszerűen lefuttatjuk az SQLite VACUUM INTO parancsot minden nap az IMAP parancsok feldolgozása során, amely a memóriában tárolt IMAP kapcsolat titkosított jelszavát használja. A biztonsági mentések akkor kerülnek mentésre, ha nem észlelünk meglévő biztonsági mentést, vagy ha a SHA-256 hash megváltozott a fájlban a legutóbbi biztonsági mentéshez képest.

Megjegyzendő, hogy a VACUUM INTO parancsot használjuk a beépített backup parancs helyett, mert ha egy oldal módosul a backup parancsművelet során, akkor újra kell kezdenie. A VACUUM INTO parancs pillanatképet készít. További információkért lásd a GitHub és Hacker hírek parancsokkal kapcsolatos megjegyzéseket.

Ezenkívül a VACUUM INTO parancsot használjuk a backup parancs helyett, mivel a backup parancs rövid ideig titkosítatlanul hagyná az adatbázist, amíg a rekey parancsot meg nem hívjuk (lásd a GitHub megjegyzés dokumentációját a részletekért).

A Másodlagos szerver a WebSocket kapcsolaton keresztül utasítja az Elsődleges szervert a biztonsági mentés végrehajtására – az Elsődleges szerver ezután megkapja a szükséges parancsot, és ezt követően a következőket teszi:

1. Csatlakozzon titkosított postaládájához.

2. Szerezzen be írási zárat.

3. Futtasson egy WAL ellenőrzőpontot a wal_checkpoint(PASSIVE) segítségével.

4. Futtassa a VACUUM INTO SQLite parancsot.

5. Győződjön meg arról, hogy a másolt fájl megnyitható a titkosított jelszóval (biztonsági/álvédelmi védelem).

6. Töltse fel a Cloudflare R2-be tárolás céljából (vagy a saját szolgáltatójára, ha meg van adva).

Ne feledd, hogy a postaládáid titkosítva vannak – és bár IP-korlátozások és egyéb hitelesítési intézkedések vannak érvényben a WebSocket kommunikációhoz –, rosszindulatú szereplő esetén biztos lehetsz benne, hogy ha a WebSocket hasznos adata nem rendelkezik az IMAP-jelszavaddal, akkor nem tudja megnyitni az adatbázisodat.

Jelenleg postaládánként csak egy biztonsági mentés kerül tárolásra, de a jövőben felajánlhatjuk az időponthoz kötött helyreállítást („PITR”).

Keresés:

IMAP-szervereink támogatják a SEARCH parancsot összetett lekérdezésekkel, reguláris kifejezésekkel és egyebekkel.

A gyors keresési teljesítmény a FTS5 és a sqlite-regex tulajdonságoknak köszönhető.

A Date értékeket az SQLite postaládákban ISO 8601 karakterláncként tároljuk a Date.prototype.toISOString-n keresztül (UTC időzónával, hogy az egyenlőség-összehasonlítások megfelelően működjenek).

Az indexek a keresési lekérdezésekben szereplő összes tulajdonsághoz is tárolódnak.

Projektek

Íme egy táblázat, amely felvázolja a forráskódunkban és a fejlesztési folyamatunkban használt projekteket (betűrendben):

Projekt	Cél
Ansible	DevOps automatizálási platform a teljes szerverflottánk egyszerű karbantartásához, skálázásához és kezeléséhez.
Bree	Feladatütemező Node.js-hez és JavaScripthez cron, dates, ms, later és felhasználóbarát támogatással.
Cabin	Fejlesztőbarát JavaScript és Node.js naplózókönyvtár, amely a biztonságot és az adatvédelmet szem előtt tartja.
Lad	Node.js keretrendszer, amely az MVC és más technológiák felhasználásával működteti a teljes architektúránkat és mérnöki tervezésünket.
MongoDB	NoSQL adatbázis-megoldás, amelyet a postaládákon kívüli összes többi adat (pl. fiók, beállítások, domainek és alias konfigurációk) tárolására használunk.
Mongoose	MongoDB objektumdokumentum-modellezés ("ODM"), amelyet a teljes rendszerünkben használunk. Speciális segítőket írtunk, amelyek lehetővé teszik számunkra, hogy egyszerűen folytassuk a Mongoose használatát SQLite-tal 🎉
Node.js	A Node.js egy nyílt forráskódú, platformfüggetlen JavaScript futtatókörnyezet, amely az összes szerverfolyamatunkat futtatja.
Nodemailer	Node.js csomag e-mailek küldéséhez, kapcsolatok létrehozásához és egyebekhez. A projekt hivatalos szponzorai vagyunk.
Redis	Memórián belüli adatbázis gyorsítótárazáshoz, közzétételi/feliratkozási csatornákhoz és HTTPS-kéréseken keresztüli DNS-hez.
SQLite3MultipleCiphers	Titkosítási bővítmény az SQLite-hoz, amely lehetővé teszi a teljes adatbázisfájlok titkosítását (beleértve az előre írási naplót ("WAL"), a naplót, a visszagörgetést stb.).
SQLiteStudio	Visual SQLite szerkesztő (amit te is használhatsz) a fejlesztői postaládák teszteléséhez, letöltéséhez és megtekintéséhez.
SQLite	Beágyazott adatbázis réteg a skálázható, önálló, gyors és rugalmas IMAP-tároláshoz.
Spam Scanner	Node.js anti-spam, e-mail szűrő és adathalászat elleni eszköz (alternatívánk a Spam Assassin és rspamd helyett).
Tangerine	DNS HTTPS kéréseken keresztül Node.js-sel és gyorsítótárazás Redis használatával – ami globális konzisztenciát és még sok minden mást biztosít.
Thunderbird	Fejlesztőcsapatunk ezt használja (és ajánlja is) a Forward Email funkcióhoz preferált e-mail kliensként.
UTM	Fejlesztőcsapatunk ezt a virtuális gépeket használja iOS és macOS rendszerekhez, hogy különböző e-mail klienseket (párhuzamosan) tesztelhessen az IMAP és SMTP szervereinkkel.
Ubuntu	Modern, nyílt forráskódú, Linux alapú szerver operációs rendszer, amely az összes infrastruktúránkat működteti.
WildDuck	IMAP szerverkönyvtár – lásd a attachment de-duplication és IMAP protocol support könyvtárakra vonatkozó megjegyzéseit.
better-sqlite3-multiple-ciphers	Gyors és egyszerű API könyvtár a Node.js és az SQLite3 programozott interakciójához.
email-templates	Fejlesztőbarát e-mail keretrendszer egyéni e-mailek (pl. fiókértesítések és egyebek) létrehozásához, előnézetéhez és küldéséhez.
json-sql-enhanced	SQL lekérdezésszerkesztő Mongo stílusú szintaxissal. Ez időt takarít meg a fejlesztőcsapatunknak, mivel továbbra is Mongo stílusban írhatunk a teljes veremben, adatbázis-agnosztikus megközelítéssel. A lekérdezési paraméterek használatával segít elkerülni az SQL injekciós támadásokat is.
knex-schema-inspector	SQL segédprogram a meglévő adatbázissémák információinak kinyerésére. Ez lehetővé teszi számunkra, hogy könnyedén ellenőrizzük, hogy az összes index, tábla, oszlop, megszorítás és egyebek érvényesek-e, és a 1:1 megfelelő-e. Még automatizált segítőket is írtunk, amelyek új oszlopokat és indexeket adnak hozzá, ha az adatbázissémákban változások történnek (rendkívül részletes hibajelzéssel).
knex	SQL lekérdezésszerkesztő, amelyet csak adatbázis-migrációkhoz és sémaérvényesítéshez használunk a knex-schema-inspector cella segítségével.
mandarin	Automatikus i18n kifejezésfordítás Markdown-támogatással Google Cloud Translation API használatával.
mx-connect	Node.js csomag az MX szerverekkel való kapcsolatok feloldásához és létrehozásához, valamint a hibák kezeléséhez.
pm2	Node.js éles folyamatkezelő beépített terheléselosztóval (fine-tuned a teljesítmény érdekében).
smtp-server	SMTP szerverkönyvtár – ezt használjuk a levélcsere ("MX") és a kimenő SMTP szervereinkhez.
ImapTest	Hasznos eszköz az IMAP-kiszolgálók benchmarkok és az RFC-specifikáció szerinti IMAP protokoll kompatibilitásának teszteléséhez. Ezt a projektet a Dovecot csapata hozta létre (egy aktív, nyílt forráskódú IMAP és POP3 szerver 2002 júliusa óta). Ezzel az eszközzel széles körben teszteltük az IMAP-kiszolgálónkat.

További, általunk használt projekteket a forráskódunk a GitHub-on alatt találhatsz.

Szolgáltatók

Szolgáltató	Cél
Cloudflare	DNS-szolgáltató, állapotellenőrzések, terheléselosztók és biztonsági mentési tárhely a Cloudflare R2 használatával.
Digital Ocean	Dedikált szerver hosting és menedzselt adatbázisok.
Vultr	Dedikált szerver hosting.
DataPacket	Dedikált szerver hosting.

Gondolatok

Alapelvek

Az e-mail továbbítása a következő elvek szerint történik:

1. Mindig legyen fejlesztőbarát, biztonság- és adatvédelmi fókuszú, valamint átlátható.

2. Tartsa be a MVC, Unix, KISS, DRY, YAGNI, Tizenkét tényező, Occam borotvája és dogfood-tesztelés irányelveket.

3. Célozza meg a selejtes, bootstrap és ramen-nyereséges fejlesztőket.

Kísérletek

tldr; Végső soron az S3-kompatibilis objektumtárolás és/vagy virtuális táblák használata teljesítménybeli okokból technikailag nem megvalósítható, és a memóriakorlátok miatt hibákra hajlamos.

A fent említett végső SQLite megoldásunkhoz néhány kísérletet végeztünk.

Az egyik ilyen módszer az rclone és az SQLite együttes használata volt egy S3-kompatibilis tárolási réteggel.

Ez a kísérlet vezetett minket az rclone, az SQLite és a VFS használatát övező peremhelyzetek jobb megértéséhez és felfedezéséhez:

• Ha engedélyezed a --vfs-cache-mode writes jelzőt az rclone-nal, akkor az olvasások rendben lesznek, de az írások gyorsítótárba kerülnek.
• Ha több IMAP szervered van globálisan elosztva, akkor a gyorsítótár nem fog működni közöttük, kivéve, ha egyetlen íród és több figyelőd van (pl. egy pub/sub megközelítés).
• Ez hihetetlenül bonyolult, és minden további ilyen bonyolultság további egyedi meghibásodási pontokat eredményez.
• Az S3-kompatibilis tárolószolgáltatók nem támogatják a részleges fájlmódosításokat – ami azt jelenti, hogy a .sqlite fájl bármilyen módosítása az adatbázis teljes módosítását és újratöltését eredményezi.
• Léteznek más megoldások is, mint például a rsync, de ezek nem az előre írásos naplózás ("WAL") támogatására összpontosítanak – ezért végül a Litestreamet vizsgáltuk meg. Szerencsére a titkosítási használatunk már titkosítja a WAL fájlokat, így nem kell a Litestreamre hagyatkoznunk ehhez. Azonban még nem voltunk biztosak a Litestreamben éles használatra, és erről alább néhány megjegyzést teszünk közzé.
• A --vfs-cache-mode writes ezen opciójának használata (az egyetlen módja az SQLite használatának a rclone helyett íráshoz) megpróbálja a teljes adatbázist a memóriából lemásolni – egy 10 GB-os postafiók kezelése rendben van, azonban több, rendkívül nagy tárhelyű postafiók kezelése az IMAP-kiszolgálók memóriakorlátozásába, valamint ENOMEM hibákba, szegmentálási hibákba és adatsérülésbe ütközik.
• Ha az SQLite Virtuális asztalok-at (pl. s3db használatával) próbálja meg használni ahhoz, hogy az adatok élőben legyenek egy S3-kompatibilis tárolási rétegen, akkor további problémákba ütközik:
• Az olvasás és írás rendkívül lassú lesz, mivel az S3 API végpontokat HTTP .sqlite0, .sqlite1, .sqlite2 és .sqlite3 metódusokkal kell elérni. * A fejlesztői tesztek azt mutatták, hogy az optikai interneten az 500K-1M+ rekordok túllépését továbbra is korlátozza az S3-kompatibilis szolgáltatók felé történő írás és olvasás átviteli sebessége. Például fejlesztőink .sqlite4 ciklusokat futtattak mind a szekvenciális SQL .sqlite5 utasítások, mind a nagy mennyiségű adat tömeges írását végző utasítások végrehajtásához. Mindkét esetben a teljesítmény megdöbbentően lassú volt.
• A virtuális táblák nem tartalmazhatnak indexeket, .sqlite6 utasításokat és .sqlite7 .sqlite8 utasításokat – ami az adatmennyiségtől függően akár 1-2 perces vagy annál hosszabb késésekhez is vezethet.
• Az objektumokat titkosítatlanul tároltuk, és nem áll rendelkezésre natív titkosítási támogatás.
• A .sqlite9 használatát is megvizsgáltuk, amely fogalmilag és technikailag hasonló az előző ponthoz (tehát ugyanazokkal a problémákkal küzd). Egy lehetséges megoldás lehetne egy egyéni rsync0 build használata titkosítással, például a rsync1-gyel (amelyet jelenleg a fenti megoldásunkban használunk) a rsync2-n keresztül.
• Egy másik lehetséges megközelítés a rsync3 használata volt, azonban ennek a mérete 32 GB, és összetett építési és fejlesztési fejfájást igényelne.
• A rsync4 utasítások szükségesek (tehát ez teljesen kizárja a virtuális táblák használatát). A rsync6-tal rendelkező hookunk megfelelő működéséhez rsync5 utasításokra van szükségünk – ez biztosítja, hogy az adatok ne sérüljenek meg, és a lekért sorok érvényes dokumentumokká konvertálhatók legyenek a rsync7 sémadefinícióink szerint (amelyek magukban foglalják a korlátozást, a változótípust és az önkényes adatellenőrzést).
• A nyílt forráskódú közösségben az SQLite-hoz kapcsolódó S3-kompatibilis projektek szinte mindegyike Pythonban van (és nem JavaScriptben, amelyet a verem 100%-ában használunk).
• Az olyan tömörítési könyvtárak, mint a rsync8 (lásd rsync9), ígéretesnek tűnnek, de a __PROTECTED_LINK_189__0. Ehelyett az olyan adattípusok alkalmazásoldali tömörítése, mint a __PROTECTED_LINK_189__1, __PROTECTED_LINK_189__2, __PROTECTED_LINK_189__3, __PROTECTED_LINK_189__4, __PROTECTED_LINK_189__5 és __PROTECTED_LINK_189__6, tisztább és egyszerűbb megközelítést kínál (és könnyebben migrálható is, mivel tárolhatnánk egy __PROTECTED_LINK_189__7 jelzőt vagy oszlopot – vagy akár használhatnánk a __PROTECTED_LINK_189__8 __PROTECTED_LINK_189__9 tömörítést vagy a __PROTECTED_LINK_190__0 tömörítés nélküli változatot adatbázis-metaadatként).
• Szerencsére már implementáltuk a mellékletduplikáció-eltávolítást az IMAP-kiszolgálónk tárolójában – ezért minden azonos melléklettel rendelkező üzenet nem őriz meg a melléklet másolatát – ehelyett egyetlen mellékletet tárolunk több üzenethez és szálhoz egy postaládában (és ezt követően egy idegen hivatkozást használunk).
• A Litestream projekt, amely egy SQLite replikációs és biztonsági mentési megoldás, nagyon ígéretes, és valószínűleg a jövőben is használni fogjuk.
• Nem akarom lejáratni a szerző(ke)t – mert több mint egy évtizede szeretjük a munkájukat és a nyílt forráskódú projektekhez való hozzájárulásukat –, azonban a valós használatból úgy tűnik, hogy létezik __PROTECTED_LINK_190__1 és __PROTECTED_LINK_190__2.
• A biztonsági mentések visszaállításának zökkenőmentesnek és triviálisnak kell lennie. Egy olyan megoldás, mint a MongoDB használata a __PROTECTED_LINK_190__3 és __PROTECTED_LINK_190__4 paraméterekkel nemcsak fárasztó, de időigényes és konfigurációs bonyolultsággal is jár.
• Az SQLite adatbázisok egyszerűvé teszik (egyetlen fájlról van szó).
• Olyan megoldást szerettünk volna tervezni, ahol a felhasználók bármikor elvihetik a postaládájukat és elhagyhatják azt.
• Egyszerű Node.js parancsok a __PROTECTED_LINK_190__5 paraméterhez, és az véglegesen törlődik a lemezes tárolóból. * Hasonlóképpen használhatunk egy S3-kompatibilis API-t a HTTP __PROTECTED_LINK_190__6-tal, hogy könnyedén eltávolítsuk a felhasználók pillanatképeit és biztonsági mentéseit.
• Az SQLite volt a legegyszerűbb, leggyorsabb és legköltséghatékonyabb megoldás.

Alternatívák hiánya

Tudomásunk szerint egyetlen más e-mail szolgáltatás sem ilyen módon lett megtervezve, és nem is nyílt forráskódúak.

Úgy gondoljuk, hogy ez annak tudható be, hogy a meglévő e-mail szolgáltatásokban éles környezetben működnek a spagetti kód 🍝 értékkel rendelkező, régi technológiával.

A legtöbb, ha nem az összes meglévő e-mail szolgáltató vagy zárt forráskódú, vagy nyílt forráskódúként hirdeti magát, de a valóságban csak a front-endjük nyílt forráskódú.

Az e-mail legérzékenyebb része (a tényleges tárolási/IMAP/SMTP interakció) a háttérrendszeren (szerveren) történik, nem a felhasználói felületen (kliens).

Próbálja ki az e-mail továbbítását

Regisztrálj még ma itt: https://forwardemail.net! 🚀