Kvantumbiztos e-mail: Hogyan használunk titkosított SQLite postaládákat az e-mailjeid biztonságáért

Kvantumbiztos titkosított e-mail szolgáltatás illusztráció

Előszó

Important

E-mail szolgáltatásunk 100%-ban nyílt forráskódú és adatvédelmi szempontból fókuszált, biztonságos és titkosított SQLite postaládákat használ.

Amíg el nem indítottuk az IMAP támogatást, addig MongoDB-t használtunk az állandó adataink tárolására.

Ez a technológia csodálatos, és ma is használjuk – de ahhoz, hogy a MongoDB-vel titkosítást kapjunk az adatok tárolásakor, olyan szolgáltatót kell választani, amely MongoDB Enterprise-ot kínál, mint például a Digital Ocean vagy a Mongo Atlas – vagy meg kell vásárolni egy vállalati licencet (és ezután a sales csapat lassúságával kell dolgozni).

A Forward Email csapatának fejlesztőbarát, skálázható, megbízható és titkosított tárolási megoldásra volt szüksége az IMAP postaládákhoz. Nyílt forráskódú fejlesztőként egy olyan technológia használata, amelyhez licencdíjat kell fizetni a titkosítási funkcióért, ellentétes volt elveinkkel – ezért kísérleteztünk, kutattunk és egy teljesen új megoldást fejlesztettünk ki ezen igények kielégítésére.

Ahelyett, hogy egy megosztott adatbázist használnánk a postaládáid tárolására, egyénileg tároljuk és titkosítjuk a postaládáidat a jelszavaddal (amit csak te ismersz). E-mail szolgáltatásunk annyira biztonságos, hogy ha elfelejted a jelszavad, elveszíted a postaládádat (és offline biztonsági mentésekből kell helyreállítanod vagy újrakezdened).

Olvass tovább, mert alaposan bemutatjuk az alábbiakat: e-mail szolgáltató összehasonlítás, hogyan működik a szolgáltatásunk, technológiai stackünk és még sok más.

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

Mi vagyunk az egyetlen 100%-ban nyílt forráskódú és adatvédelmi szempontból fókuszált e-mail szolgáltató, amely egyénileg titkosított SQLite postaládákat tárol, korlátlan domaineket, aliasokat és felhasználókat kínál, valamint támogatja a kimenő SMTP-t, IMAP-ot és POP3-at:

Ellentétben más e-mail szolgáltatókkal, a Forward Email-nél nem kell domain vagy alias alapon fizetned a tárhelyért. A tárhely megosztott az egész fiókodban – tehát ha több egyedi domain neved és több aliasod van mindegyiken, akkor mi vagyunk a tökéletes megoldás számodra. Megjegyzés: ha szeretnéd, továbbra is érvényesíthetsz tárhelykorlátokat domain vagy alias alapon.

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

Hogyan működik

Az e-mail klienseddel, például Apple Mail, Thunderbird, Gmail vagy Outlook segítségével – a felhasználóneveddel és jelszavaddal csatlakozol a biztonságos IMAP szervereinkhez:
- A felhasználóneved a teljes aliasod a domaineddel együtt, például hello@example.com.
- A jelszavad véletlenszerűen generált, és csak 30 másodpercig jelenik meg, amikor rákattintasz a Jelszó generálása gombra a Fiókom Domain-ek Aliasok menüpontban.
Miután csatlakoztál, az email kliensed IMAP protokoll parancsokat fog küldeni az IMAP szerverünkre, hogy szinkronban tartsa a postaládádat. Ez magában foglalja a piszkozat e-mailek írását és tárolását, valamint más műveleteket, amelyeket végezhetsz (pl. egy e-mail megjelölése Fontosként vagy Spam/Kéretlen levélként való megjelölése).
A levelező szerverek (közismert nevükö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 email kliensed értesítést kap és szinkronizálja a postaládádat. A levelező szervereink továbbíthatják az e-mailedet egy vagy több címzettnek (beleértve a webhookokat), tárolhatják az e-mailedet az általunk biztosított titkosított IMAP tárolódban, vagy akár mindkettőt!

Tip
Érdekel többet megtudni? Olvasd el hogyan állítsd be az email továbbítást, hogyan működik a levelező szolgáltatásunk, vagy nézd meg útmutatóinkat.
A háttérben a biztonságos email tárolási rendszerünk két módon működik, hogy a postaládáid titkosítottak legyenek és csak te férhess hozzájuk:
- Amikor új levelet kapsz egy feladótól, a levelező szervereink egy egyéni, ideiglenes és titkosított postaládába írnak neked.
- Amikor az email klienseddel csatlakozol az IMAP szerverünkhöz, a jelszavad memóriában titkosítva kerül felhasználásra a postaládád olvasására és írására. A postaládádat csak ezzel a jelszóval lehet olvasni és írni. Ne feledd, hogy mivel csak neked van meg ez a jelszó, csak te férhetsz hozzá és írhatod a postaládádat, amikor használod azt. Amikor az email kliensed legközelebb megpróbál levelet lekérni vagy szinkronizálni, az új üzenetek átkerülnek ebből az ideiglenes postaládából és a megadott jelszóval titkosított valódi postaláda fájlba kerülnek tárolásra. Fontos, hogy ez az ideiglenes postaláda később törlésre és kiürítésre kerül, így csak a jelszóval védett postaládában maradnak meg az üzenetek.
- Ha IMAP-hoz vagy csatlakozva (pl. Apple Mail vagy Thunderbird email kliens használatával), akkor nincs szükség ideiglenes lemez tárolóra írni. Ehelyett a memóriában titkosított IMAP jelszó kerül lekérésre és felhasználásra. Valós időben, amikor egy üzenet kézbesítése történik, WebSocket kérést küldünk az összes IMAP szervernek, hogy van-e aktív munkamenet számodra (ez a lekérés része), majd ezt követően továbbítjuk a titkosított memóriában lévő jelszót – így nincs szükség ideiglenes postaládába írni, a valódi titkosított postaládádba írhatunk a titkosított jelszóval.
A titkosított postaládáid biztonsági mentései naponta készülnek. Bármikor kérhetsz új biztonsági mentést, vagy letöltheted a legfrissebb mentést a Saját fiók Domain-ek Aliasok menüpontból. Ha úgy döntesz, hogy másik email szolgáltatóra váltasz, akkor könnyedén migrálhatod, letöltheted, exportálhatod és törölheted a postaládáidat és biztonsági mentéseidet bármikor.

Technológiák

Adatbázisok

Megvizsgáltunk más lehetséges adatbázis tároló rétegeket is, azonban egyik sem felelt meg annyira az igényeinknek, mint az SQLite:

Adatbázis	Titkosítás nyugalmi állapotban	Sandboxolt postaládák	Licenc	Mindenhol Használt
SQLite ⭐	✅ Igen a SQLite3MultipleCiphers segítségével	✅	✅ Public Domain	✅
MongoDB	❌ "Csak a MongoDB Enterprise verzióban elérhető"	❌ Relációs adatbázis	❌ AGPL és `SSPL-1.0`	❌
rqlite	❌ Csak hálózati titkosítás	❌ Relációs adatbázis	✅ `MIT`	❌
dqlite	❌ Nem tesztelt és még nem támogatott?	❌ Nem tesztelt és még nem támogatott?	✅ `LGPL-3.0-only`	❌
PostgreSQL	✅ Igen	❌ Relációs adatbázis	✅ `PostgreSQL` (hasonló a `BSD` vagy `MIT`)	❌
MariaDB	✅ Csak InnoDB-hez	❌ Relációs adatbázis	✅ `GPLv2` és `BUSL-1.1`	❌
CockroachDB	❌ Csak Enterprise funkció	❌ Relációs adatbázis	❌ `BUSL-1.1` és mások	❌

Itt található egy blogbejegyzés, amely több SQLite adatbázis tárolási lehetőséget hasonlít össze a fenti táblázatban.

Biztonság

Minden esetben használunk titkosítást nyugalmi állapotban (AES-256), titkosítást átvitel közben (TLS), DNS over HTTPS ("DoH") protokollt a 🍊 Tangerine segítségével, valamint sqleet (ChaCha20-Poly1305) titkosítást a postaládákon. Ezen felül token-alapú kétfaktoros hitelesítést alkalmazunk (szemben az SMS-sel, amely érzékeny a man-in-the-middle támadásokra), forgatott SSH kulcsokat root hozzáférés letiltásával, kizárólagos hozzáférést a szerverekhez korlátozott IP-címeken keresztül, és még sok mást. Egy rosszindulatú szobalány támadás vagy egy harmadik fél szolgáltatójának rosszindulatú alkalmazottja esetén a postaládádat továbbra is csak a te általad generált jelszóval lehet megnyitni. Nyugodj meg, nem támaszkodunk más harmadik fél szolgáltatókra, csak a Cloudflare, DataPacket, Digital Ocean, GitHub és Vultr SOC Type 2 megfelelőségi szerver szolgáltatóinkra.

Célunk, hogy minél kevesebb legyen az egypontos hibák.

Postaládák

röviden; Az IMAP szervereink egyénileg titkosított SQLite adatbázisokat használnak minden egyes postaládádhoz.

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

Például a titkosított szervereinken van egy SQLite adatbázis postaláda linux@example.com, info@example.com, hello@example.com és így tovább – mindegyikhez egy .sqlite adatbázis fájl. Az adatbázis fájlokat nem az email cím alapján nevezzük el – helyette BSON ObjectID és egyedi UUID-ket használunk, amelyek nem árulják el, hogy kié a postaláda vagy melyik email címhez tartozik (pl. 353a03f21e534321f5d6e267.sqlite).

Ezek az adatbázisok maguk is a te jelszavaddal vannak titkosítva (amit csak te ismersz) a sqleet (ChaCha20-Poly1305) segítségével. Ez azt jelenti, hogy a postaládáid egyénileg titkosítottak, önállóak, sandboxoltak és hordozhatóak.

Finomhangoltuk az SQLite-ot a következő PRAGMA beállításokkal:

`PRAGMA`	Cél
`cipher=chacha20`	ChaCha20-Poly1305 SQLite adatbázis titkosítás. További betekintésért lásd a `better-sqlite3-multiple-ciphers` projektet a Projektek alatt.
`key="****************"`	Ez a memóriában csak dekódolt jelszavad, amely az email kliensed IMAP kapcsolatán keresztül jut el a szerverünkre. Új adatbázis példányok jönnek létre és záródnak le minden olvasási és írási munkamenethez (a sandboxolás és izoláció biztosítása érdekében).
`journal_model=WAL`	Írás-előtti napló ("WAL") amely növeli a teljesítményt és lehetővé teszi az egyidejű olvasást.
`busy_timeout=5000`	Megakadályozza az írási zárolási hibákat amiközben más írások zajlanak.
`synchronous=NORMAL`	Növeli a tranzakciók tartósságát adatvesztés kockázata nélkül.
`foreign_keys=ON`	Biztosítja, hogy a külső kulcs hivatkozások (pl. egy tábla kapcsolat egy másikhoz) érvényesüljenek. Alapértelmezés szerint ez nincs bekapcsolva az SQLite-ban, de az érvényesítés és adat integritás érdekében engedélyezni kell.
`encoding='UTF-8'`	Alapértelmezett kódolás, amelyet a fejlesztői érthetőség biztosítására használunk.

Minden egyéb alapértelmezett érték az SQLite-ból származik, az hivatalos PRAGMA dokumentáció szerint.

Egyidejűség

röviden; A WebSocket-et használjuk az egyidejű olvasásokhoz és írásokhoz a titkosított SQLite postaládáidhoz.

Olvasások

A telefonodon lévő e-mail kliensed az imap.forwardemail.net címet a Digital Ocean egyik IP-címére oldhatja fel – míg az asztali kliensed egy teljesen más szolgáltató IP-címét is feloldhatja.

Függetlenül attól, hogy melyik IMAP szerverhez csatlakozik az e-mail kliensed, azt szeretnénk, hogy a kapcsolat valós időben, 100%-os pontossággal olvasson az adatbázisodból. Ezt WebSocketeken keresztül valósítjuk meg.

Írások

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

Megvizsgáltunk olyan lehetőségeket, mint a litestream, rqlite és dqlite – azonban egyik sem felelt meg az igényeinknek.

Az írások végrehajtásához, a write-ahead-logging ("WAL") engedélyezésével – biztosítanunk kell, hogy csak egy szerver ("Elsődleges") legyen felelős ezért. A WAL drasztikusan felgyorsítja az egyidejűséget, és lehetővé teszi egy író és több olvasó működését.

Az Elsődleges a titkosított postaládákat tartalmazó csatolt kötetekkel rendelkező adat szervereken fut. Elosztási szempontból az imap.forwardemail.net mögötti összes egyedi IMAP szervert másodlagos szervereknek ("Másodlagos") tekintheted.

Kétirányú kommunikációt valósítunk meg WebSocketekkel:

Az Elsődleges szerverek a ws WebSocketServer szerver példányát használják.
A Másodlagos szerverek a ws WebSocket kliens példányát használják, amelyet a websocket-as-promised és a reconnecting-websocket csomagokkal burkolnak. Ezek a két burkoló biztosítja, hogy a WebSocket újracsatlakozzon, és képes legyen adatokat küldeni és fogadni az adott adatbázis-írásokhoz.

Biztonsági mentések

röviden; A titkosított postaládáid biztonsági mentése naponta készül. Azonnal kérhetsz új biztonsági mentést, vagy bármikor letöltheted a legfrissebbet a Fiókom Tartományok Átirányítások menüpontból.

A biztonsági mentésekhez egyszerűen futtatjuk az SQLite VACUUM INTO parancsot minden nap az IMAP parancs feldolgozása közben, amely kihasználja a titkosított jelszavadat egy memóriabeli IMAP kapcsolaton keresztül. A biztonsági mentések akkor készülnek, ha nincs meglévő mentés, vagy ha a fájl SHA-256 hash értéke megváltozott az utolsó 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 parancs végrehajtása közben, akkor újra kell kezdeni. A VACUUM INTO parancs egy pillanatképet készít. Erről további információkat találsz ezekben a kommentekben a GitHubon és a Hacker News-on.

Továbbá a VACUUM INTO-t használjuk a backup helyett, mert a backup parancs ideiglenesen titkosítatlanul hagyná az adatbázist, amíg a rekey meg nem történik (erről bővebben ebben a GitHub kommentben).

A Másodlagos a WebSocket kapcsolaton keresztül utasítja az Elsődleges szervert a biztonsági mentés végrehajtására – az Elsődleges pedig megkapja a parancsot, és ezt követően:

Csatlakozik a titkosított postaládádhoz.
Írási zárolást szerez.
Lefuttat egy WAL ellenőrzőpontot a wal_checkpoint(PASSIVE) segítségével.
Lefuttatja az SQLite VACUUM INTO parancsot.
Ellenőrzi, hogy a másolt fájl megnyitható-e a titkosított jelszóval (biztonsági ellenőrzés).
Feltölti a Cloudflare R2 tárhelyre (vagy a megadott saját szolgáltatódhoz).

Ne feledje, hogy a postaládái titkosítva vannak – és bár IP-korlátozásokat és egyéb hitelesítési intézkedéseket alkalmazunk a WebSocket kommunikációhoz – rosszindulatú szereplő esetén biztos lehet benne, hogy ha a WebSocket terhelés nem tartalmazza az IMAP jelszavát, akkor nem tudja megnyitni az adatbázisát.

Jelenleg postaládánként csak egy biztonsági mentés tárolódik, de a jövőben lehet, hogy kínálunk időpontra visszaá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 használatának köszönhető.

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

Indexek is tárolódnak minden olyan tulajdonságra, amely keresési lekérdezésekben szerepel.

Projektek

Az alábbi táblázat a forráskódunkban és fejlesztési folyamatunkban használt projekteket mutatja be (ábécé sorrendben):

Projekt	Cél
Ansible	DevOps automatizációs platform, amely megkönnyíti a szerverparkunk karbantartását, skálázását és kezelését.
Bree	Feladatütemező Node.js és JavaScript számára, cron, dátumok, ms, later és emberbarát támogatással.
Cabin	Fejlesztőbarát JavaScript és Node.js naplózó könyvtár, biztonság és adatvédelem szem előtt tartásával.
Lad	Node.js keretrendszer, amely az egész architektúránkat és mérnöki tervezésünket működteti MVC-vel és egyebekkel.
MongoDB	NoSQL adatbázis megoldás, amelyet minden egyéb adat (például fiókja, beállítások, domainek és alias konfigurációk) tárolására használunk a postaládákon kívül.
Mongoose	MongoDB objektum dokumentum modellező ("ODM"), amelyet az egész stackünkben használunk. Külön segédfüggvényeket írtunk, amelyek lehetővé teszik, hogy egyszerűen folytathassuk a Mongoose használatát SQLite-tal 🎉
Node.js	A Node.js nyílt forráskódú, platformok közötti JavaScript futtatókörnyezet, amely az összes szerverfolyamatunkat futtatja.
Nodemailer	Node.js csomag e-mailek küldésére, kapcsolatok létrehozására és egyebekre. Hivatalos támogatója vagyunk ennek a projektnek.
Redis	Memóriában futó adatbázis gyorsítótárazáshoz, publish/subscribe csatornákhoz és DNS over HTTPS kérésekhez.
SQLite3MultipleCiphers	Titkosítási kiterjesztés SQLite-hoz, amely lehetővé teszi az egész adatbázis fájlok titkosítását (beleértve az írási előnapló ("WAL"), napló, visszavonás, …).
SQLiteStudio	Vizualizált SQLite szerkesztő (amit Ön is használhat), fejlesztési postaládák tesztelésére, letöltésére és megtekintésére.
SQLite	Beágyazott adatbázis réteg skálázható, önálló, gyors és ellenálló IMAP tároláshoz.
Spam Scanner	Node.js alapú antispam, e-mail szűrő és adathalászat elleni eszköz (alternatívánk a Spam Assassin és rspamd helyett).
Tangerine	DNS over HTTPS kérések Node.js-sel és Redis gyorsítótárazással – amely globális konzisztenciát és még sok mást biztosít.
Thunderbird	Fejlesztői csapatunk ezt használja (és ajánlja is) mint a Forward Email-hez ajánlott e-mail kliens.
UTM	Fejlesztői csapatunk ezt használja virtuális gépek létrehozására iOS és macOS rendszerekhez, hogy párhuzamosan tesztelhessük különböző e-mail klienseket az IMAP és SMTP szervereinkkel.
Ubuntu	Modern, nyílt forráskódú Linux-alapú szerver operációs rendszer, amely az egész infrastruktúránkat működteti.
WildDuck	IMAP szerver könyvtár – lásd megjegyzéseit az melléklet duplikáció eltávolításáról és az IMAP protokoll támogatásáról.
better-sqlite3-multiple-ciphers	Gyors és egyszerű API könyvtár Node.js-hez, amely programozottan kezeli az SQLite3-at.
email-templates	Fejlesztőbarát e-mail keretrendszer egyedi e-mailek létrehozásához, előnézetéhez és küldéséhez (pl. fiók értesítések és egyebek).
json-sql-enhanced	SQL lekérdezés építő Mongo-stílusú szintaxissal. Ez időt takarít meg fejlesztői csapatunknak, mivel az egész stackben Mongo-stílusban írhatunk adatbázis független megközelítéssel. Segít elkerülni az SQL injekciós támadásokat is lekérdezési paraméterek használatával.
knex-schema-inspector	SQL eszköz meglévő adatbázis sémák információinak kinyerésére. Ez lehetővé teszi számunkra, hogy könnyen ellenőrizzük, hogy minden index, tábla, oszlop, megszorítás és egyéb érvényes és `1:1` megfelel annak, amilyennek lennie kell. Automatikus segédfüggvényeket is írtunk új oszlopok és indexek hozzáadására, ha változások történnek az adatbázis sémákban (rendkívül részletes hibajelzéssel).
knex	SQL lekérdezés építő, amelyet csak adatbázis migrációkhoz és séma ellenőrzéshez használunk a `knex-schema-inspector` segítségével.
mandarin	Automatikus i18n kifejezés fordítás Markdown támogatással a Google Cloud Translation API használatával.
mx-connect	Node.js csomag MX szerverek feloldására és kapcsolatok létrehozására, valamint hibakezelésre.
pm2	Node.js termelési folyamatkezelő beépített terheléselosztóval (finomhangolva a teljesítmény érdekében).
smtp-server	SMTP szerver könyvtár – ezt használjuk a levelezési ("MX") és kimenő SMTP szervereinkhez.
ImapTest	Hasznos eszköz IMAP szerverek tesztelésére benchmarkok és RFC specifikáció szerinti IMAP protokoll kompatibilitás ellenőrzésére. 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 alaposan teszteltük az IMAP szerverünket.

Más projekteket, amelyeket használunk, megtalálhat a forráskódunkban a GitHubon.

Szolgáltatók

Szolgáltató	Cél
Cloudflare	DNS szolgáltató, egészségügyi ellenőrzések, terheléselosztók és biztonsági mentés tárolása a Cloudflare R2 használatával.
GitHub	Forráskód tárolás, CI/CD és projektmenedzsment.
Digital Ocean	Dedikált szerver hoszting és kezelt adatbázisok.
Vultr	Dedikált szerver hoszting.
DataPacket	Dedikált szerver hoszting.

Gondolatok

Elvek

A Forward Email az alábbi elvek szerint készült:

Mindig legyen fejlesztőbarát, biztonság- és adatvédelmi fókuszú, valamint átlátható.
Tartsa be az MVC, Unix, KISS, DRY, YAGNI, Twelve Factor, Occam borotvája és a dogfooding elveket.
Célcsoport a szívós, saját erőből induló és ramen-profitos fejlesztő.

Kísérletek

röviden; Végül az S3-kompatibilis objektumtároló és/vagy a Virtuális Táblák használata technikailag nem kivitelezhető teljesítménybeli okok miatt, és memóriakorlátok miatt hibákra hajlamos.

Néhány kísérletet végeztünk a fent említett végleges SQLite megoldás előtt.

Egyik ilyen volt az rclone és az SQLite együttes használata egy S3-kompatibilis tárolóréteggel.

Ez a kísérlet segített jobban megérteni és felfedezni az rclone, SQLite és a VFS használatával kapcsolatos szélsőséges eseteket:

Ha engedélyezi az --vfs-cache-mode writes kapcsolót az rclone-nál, akkor az olvasások rendben lesznek, viszont az írások gyorsítótárazva lesznek.
- Ha több globálisan elosztott IMAP szervere van, akkor a gyorsítótár nem lesz szinkronban közöttük, hacsak nincs egyetlen író és több hallgató (pl. pub/sub megközelítés).
- Ez rendkívül bonyolult, és bármilyen további komplexitás hozzáadása több egyedi hibapontot eredményez.
- Az S3-kompatibilis tárolók nem támogatják a részleges fájl módosításokat – ami azt jelenti, hogy a .sqlite fájl bármilyen változása az adatbázis teljes újrafeltöltését eredményezi.
- Léteznek más megoldások, mint az rsync, de ezek nem fókuszálnak az előírásos napló ("WAL") támogatására – ezért végül a Litestreamet vizsgáltuk meg. Szerencsére az általunk használt titkosítás már titkosítja a WAL fájlokat, így nem kell a Litestreamre támaszkodnunk ebben. Azonban még nem voltunk teljesen biztosak a Litestream éles használatában, erről lentebb néhány megjegyzés található.
- Az --vfs-cache-mode writes opció használata (az egyetlen mód az SQLite írására rclone felett) megpróbálja az egész adatbázist memóriában újra másolni – egy 10 GB-os postaláda kezelése még OK, de több nagy tárolású postaláda esetén az IMAP szerverek memóriakorlátokba ütköznek, ENOMEM hibák, szegmentációs hibák és adatkorruptáció léphet fel.
Ha megpróbálja használni az SQLite Virtuális Táblákat (pl. s3db használatával) az adatok S3-kompatibilis tárolón való élő tárolására, akkor több további problémába ütközik:
- Az olvasás és írás rendkívül lassú lesz, mivel az S3 API végpontokat HTTP GET, PUT, HEAD és POST metódusokkal kell elérni.
- Fejlesztési tesztek azt mutatták, hogy 500K-1M+ rekord felett a fiber interneten is az S3-kompatibilis szolgáltatók írási és olvasási áteresztőképessége korlátozza a teljesítményt. Például fejlesztőink for ciklusokat futtattak szekvenciális SQL INSERT utasításokra és nagy mennyiségű adat tömeges írására is. Mindkét esetben a teljesítmény rendkívül lassú volt.
- A virtuális táblák nem tartalmazhatnak indexeket, ALTER TABLE utasításokat és egyéb korlátozásokat – ami 1-2 perces vagy annál hosszabb késéseket eredményez az adatmennyiségtől függően.
- Az objektumok titkosítatlanul voltak tárolva, és nincs natív titkosítási támogatás.
Megvizsgáltuk az sqlite-s3vfs használatát is, amely koncepcionálisan és technikailag hasonló az előző ponthoz (így ugyanazokkal a problémákkal rendelkezik). Egy lehetőség lehet egy egyedi sqlite3 build használata titkosítással, például a wxSQLite3 (amit jelenleg is használunk a fent említett megoldásban) segítségével, a setup fájl szerkesztésével.
Egy másik lehetséges megközelítés a multiplex kiterjesztés használata volt, de ennek 32 GB-os korlátja van, és bonyolult építési és fejlesztési problémákat okozna.
ALTER TABLE utasításokra szükség van (ez teljesen kizárja a Virtuális Táblák használatát). Szükségünk van ALTER TABLE utasításokra, hogy a knex-schema-inspector hook megfelelően működjön – ez biztosítja, hogy az adatok ne sérüljenek, és a lekért sorok érvényes dokumentumokká konvertálhatók legyenek a mongoose séma definícióink szerint (beleértve a megszorításokat, változó típusokat és tetszőleges adatellenőrzést).
Az összes S3-kompatibilis SQLite projektek az open-source közösségben szinte kizárólag Pythonban vannak (nem JavaScriptben, amit mi a teljes stack-ünkben használunk).
Olyan tömörítő könyvtárak, mint a sqlite-zstd (lásd hozzászólások) ígéretesek, de lehet, hogy még nem alkalmasak éles használatra. Ehelyett az alkalmazásoldali tömörítés String, Object, Map, Array, Set és Buffer adattípusokra tisztább és könnyebb megoldás lesz (és könnyebb migrálni is, mivel tárolhatunk egy Boolean jelzőt vagy oszlopot – vagy akár használhatjuk a PRAGMA user_version=1 tömörítéshez vagy user_version=0 tömörítés nélkül adatbázis metaadatként).
- Szerencsére már megvalósítottuk a mellékletek duplikációmentesítését az IMAP szerver tárolásában – így minden azonos mellékletű üzenet nem tárol külön másolatot, hanem egyetlen mellékletet tárolunk több üzenet és szál számára egy postaládában (és 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 használni fogjuk.
- Nem akarjuk a szerző(k) munkáját lekicsinyelni – mert nagyon szeretjük a munkájukat és hozzájárulásaikat az open-source-hoz több mint egy évtizede – de a valós használat alapján úgy tűnik, hogy sok fejfájást okozhat és potenciális adatvesztés is előfordulhat.
A biztonsági mentések visszaállítása súrlódásmentes és egyszerű kell legyen. Olyan megoldások használata, mint a MongoDB mongodump és mongoexport nemcsak fárasztó, hanem időigényes és konfigurációs bonyodalmakat okoz.
- Az SQLite adatbázisok egyszerűek (egyetlen fájl).
- Olyan megoldást akartunk tervezni, ahol a felhasználók bármikor elvihetik a postaládájukat.
  - Egyszerű Node.js parancsok, mint az fs.unlink('mailbox.sqlite'), és az véglegesen törlődik a lemezről.
  - Hasonlóképpen használhatunk S3-kompatibilis API-t HTTP DELETE metódussal a pillanatképek és biztonsági mentések egyszerű törléséhez a felhasználók számára.
- Az SQLite volt a legegyszerűbb, leggyorsabb és leggazdaságosabb megoldás.

Alternatívák hiánya

Tudomásunk szerint más e-mail szolgáltatások nem így vannak tervezve, és nem is nyílt forráskódúak.

Úgy gondoljuk, hogy ennek oka lehet, hogy a meglévő e-mail szolgáltatások örökölt technológiát használnak éles környezetben, spagetti kóddal 🍝.

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únak hirdeti magát, de valójában csak a front-endjük nyílt forráskódú.

Az e-mail legérzékenyebb része (a tényleges tárolás/IMAP/SMTP interakció) mind a back-end-en (szerveren) történik, és nem a front-end-en (kliensen).

Próbáld ki a Forward Emailt

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