A legjobb kvantumbiztonságos titkosított e-mail szolgáltatás 2024 ben

Előszó

tldr; E-mail szolgáltatásunk az 100%-ban nyílt forráskódú és az adatvédelemre összpontosító biztonságos és titkosított SQLite postafiókok révén.

Amíg el nem indultunk IMAP támogatás, a MongoDB-t használtuk állandó adattárolási igényeinkre.

Ez a technológia elképesztő, és még ma is használjuk – de ahhoz, hogy a MongoDB-vel nyugalmi állapotban legyen titkosítás, olyan szolgáltatót kell használnia, amely MongoDB Enterprise-t kínál, például Digital Ocean vagy Mongo Atlas – vagy vállalati licencet kell fizetnie (és ezt követően az értékesítési csapat késleltetésével kell dolgoznia).

Csapatunk a Továbbító e-mail fejlesztőbarát, méretezhető, megbízható és titkosított tárolási megoldásra volt szüksége az IMAP-postafiókokhoz. Nyílt forráskódú fejlesztőként a nyugalmi titkosítási funkció használatához licencdíjat kell fizetnie a technológia használata ellen. elveinket – és így kísérleteztünk, kutattunk, és a semmiből új megoldást fejlesztettünk ki ezen igények kielégítésére.

Ahelyett, hogy egy megosztott adatbázist használnánk postafiókjainak tárolására, egyedileg tároljuk és titkosítjuk postafiókjait az Ön jelszavával (amivel csak Ön rendelkezik). E-mail szolgáltatásunk annyira biztonságos, hogy ha elfelejti jelszavát, akkor elveszíti postafiókját (és helyre kell állítani offline biztonsági mentésekkel, vagy újra kell kezdeni).

Folytassa az olvasást, miközben alább mélyre ásunk a az e-mail szolgáltatók összehasonlítása, hogyan működik szolgáltatásunk, technológiai halmazunk, és több.

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

Mi vagyunk az egyetlen 100%-ban nyílt forráskódú és az adatvédelemre fókuszáló e-mail szolgáltató, amely egyedileg titkosított SQLite-postaládákat tárol, korlátlan számú tartományt, álneveket és felhasználókat kínál, valamint kimenő SMTP-, IMAP- és POP3-támogatással rendelkezik:

Más e-mail szolgáltatókkal ellentétben az E-mail továbbítása funkcióval nem kell fizetnie a tárhelyért domainenként vagy álnévenként. A tárhely a teljes fiókjában meg van osztva – tehát ha több egyéni domainnévvel és több álnévvel rendelkezik, akkor mi vagyunk a tökéletes megoldás az Ön számára. Ne feledje, hogy továbbra is érvényesítheti a tárolási korlátozásokat, ha szükséges, tartományonként vagy álnévenként.

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

Hogyan működik

Az e-mail kliens, például az Apple Mail, a Thunderbird, a Gmail vagy az Outlook használatával csatlakozhat biztonságosunkhoz IMAP a felhasználónevét és jelszavát használó szerverek:
- A felhasználóneve a teljes alias a domainnel együtt, mint pl hello@example.com.
- Jelszava véletlenszerűen generálódik, és csak 30 másodpercig jelenik meg, ha rákattint Jelszó generálása tól től Az én fiókom Domainek Álnevek.
A csatlakozás után az e-mail kliens küldeni fog IMAP protokoll parancsok IMAP szerverünkre, hogy a postafiókja szinkronban legyen. Ez magában foglalja a piszkozatok e-mailek írását és tárolását, valamint egyéb műveleteket, amelyeket Ön elvégezhet (pl. egy e-mailt fontosként címkézzen meg, vagy jelöljön meg egy e-mailt spam/levélszemétként).
A levelezőszerverek (közismert nevén "MX" szerverek) fogadják az új bejövő e-maileket, és eltárolják azokat a postafiókjában. Amikor ez megtörténik, az e-mail kliens értesítést kap, és szinkronizálja a postafiókját. Levelezőszervereink továbbíthatják e-mailjeit egy vagy több címzettnek (beleértve webhookok), tárolja e-mailjeit nálunk a titkosított IMAP-tárhelyén, vagy mindkettő!

Érdekel többet tanulni? Olvas hogyan kell beállítani az e-mail-továbbítást, hogyan működik levélváltási szolgáltatásunk, vagy nézet vezetőink.
A színfalak mögött biztonságos e-mail-tárolási kialakításunk kétféleképpen működik, hogy postafiókjait titkosítva tartsa, és csak Ön férhessen hozzá:
- Amikor új levelet kap egy feladótól, levelezőszervereink egyéni, ideiglenes és titkosított postafiókba írnak.
```
sequenceDiagram
    autonumber
    actor Sender
    Sender->>MX: Inbound message received for your alias (e.g. you@yourdomain.com).
    MX->>SQLite: Message is stored in a temporary mailbox.
    Note over MX,SQLite: Forwards to other recipients and webhooks configured.
    MX->>Sender: Success!
```
- Amikor e-mail kliensével csatlakozik IMAP-szerverünkhöz, jelszava a memóriában titkosítva lesz, és a postafiók olvasására és írására szolgál. Postafiókja csak ezzel a jelszóval olvasható és írható. Ne feledje, hogy mivel Ön az egyetlen, aki rendelkezik ezzel a jelszóval, csak te olvashat és írhat a postafiókjába, amikor hozzáfér. A következő alkalommal, amikor az e-mail kliens megpróbálja lekérdezni a leveleket vagy szinkronizál, az új üzenetek átkerülnek ebből az ideiglenes postafiókból, és a megadott jelszavával a tényleges postafiókfájlban tárolódnak. Vegye figyelembe, hogy ezt az ideiglenes postafiókot utólag törli, így csak a jelszóval védett postafiókja tartalmazza az üzeneteket.
- Ha IMAP-hoz csatlakozik (például olyan e-mail kliens használatával, mint az Apple Mail vagy a Thunderbird), akkor nem kell ideiglenes lemeztárolóra írnunk. Ehelyett a rendszer lekéri és felhasználja a memóriában lévő titkosított IMAP-jelszót. Valós időben, amikor egy üzenetet megpróbálnak kézbesíteni Önnek, egy WebSocket kérést küldünk az összes IMAP-szervernek, amelyben megkérdezzük, hogy van-e aktív munkamenetük az Ön számára (ez a letöltési rész), majd ezt követően továbbítjuk. titkosított, memórián belüli jelszó – így nem kell ideiglenes postafiókba írnunk, az Ön titkosított jelszavával írhatunk a tényleges titkosított postafiókjába.
```
sequenceDiagram
    autonumber
    actor You
    You->>IMAP: You connect to IMAP server using an email client.
    IMAP->>SQLite: Transfer message from temporary mailbox to your alias' mailbox.
    Note over IMAP,SQLite: Your alias' mailbox is only available in-memory using IMAP password.
    SQLite->>IMAP: Retrieves messages as requested by email client.
    IMAP->>You: Success!
```
Biztonsági másolatok a titkosított postafiókokról naponta készülnek. Bármikor kérhet új biztonsági másolatot, vagy letöltheti a legújabb biztonsági másolatot a webhelyről Az én fiókom Domainek Álnevek. Ha úgy dönt, hogy másik e-mail szolgáltatásra vált, akkor bármikor könnyedén migrálhatja, letöltheti, exportálhatja és törölheti postafiókjait és biztonsági másolatait.

Technológiák

Adatbázisok

Más lehetséges adatbázis-tárolási rétegeket is megvizsgáltunk, de egyik sem felelt meg annyira a követelményeinknek, mint az SQLite:

Adatbázis	Titkosítás nyugalmi állapotban	Sandboxed Postafiókok	Engedély	Mindenhol használt
SQLite ⭐	✅ Igen SQLite3MultipleCiphers	✅	✅ Public Domain	✅
MongoDB	❌ "Csak a MongoDB Enterprise-ban érhető el"	❌ Relációs adatbázis	❌ AGPL és `SSPL-1.0`	❌
rqlite	❌ Csak hálózat	❌ 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ó `BSD` vagy `MIT`)	❌
MariaDB	✅ Csak az InnoDB-hez	❌ Relációs adatbázis	✅ `GPLv2` és `BUSL-1.1`	❌
CockroachDB	❌ Csak vállalati szolgáltatás	❌ Relációs adatbázis	❌ `BUSL-1.1` és mások	❌

Itt van egy blogbejegyzés, amely összehasonlítja az SQLite adatbázis tárolási lehetőségeit a fenti táblázatban.

Biztonság

Mindig használjuk titkosítás nyugalmi állapotban (AES-256), továbbítás közbeni titkosítás (TLS), DNS HTTPS-en keresztül ("DoH") a 🍊 használatával Mandarin, és sqleet (ChaCha20-Poly1305) titkosítást a postafiókokon. Ezenkívül token alapú kéttényezős hitelesítést használunk (szemben az SMS-sel, amelyre gyanítható ember a középen-támadások), elforgatott SSH-kulcsok letiltott root hozzáféréssel, kizárólagos hozzáférés a szerverekhez korlátozott IP-címeken keresztül, és így tovább.

Abban az esetben, ha egy gonosz szobalány támadás vagy egy harmadik fél kereskedőtől származó szélhámos alkalmazott, postafiókja továbbra is csak a generált jelszóval nyitható meg. Biztos lehet benne, hogy a Cloudflare, a Digital Ocean és a Vultr SOC Type 2 panaszszerver szolgáltatóin kívül nem támaszkodunk semmilyen harmadik félre.

Célunk, hogy minél kevesebb legyen egyetlen hibapont amint lehet.

Postafiókok

tldr; IMAP-szervereink egyénileg titkosított SQLite adatbázisokat használnak minden egyes postafiókjához.

Az SQLite rendkívül népszerű beágyazott adatbázis – jelenleg fut a telefonon és a számítógépen – és szinte minden jelentősebb technológia használja.

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

Ezen adatbázisok mindegyike titkosítva van az Ön jelszavával (amely csak Ön rendelkezik) használatával sqleet (ChaCha20-Poly1305). Ez azt jelenti, hogy postafiókjai egyedileg titkosítottak, önállóak, homokozóbanés hordozható.

Az SQLite-t a következőkkel finomítottuk PRAGMA:

`PRAGMA`	Célja
`cipher=chacha20`	ChaCha20-Poly1305 SQLite adatbázis titkosítás. Referencia `better-sqlite3-multiple-ciphers` alatt Projektek több betekintésért.
`key="****************"`	Ez a visszafejtett, csak a memórián belüli jelszava, amely az e-mail kliens IMAP-kapcsolatán keresztül jut el a szerverünkhöz. Új adatbázis-példányok jönnek létre és záródnak be minden olvasási és írási munkamenethez (a sandbox-kezelés és az elkülönítés biztosítása érdekében).
`journal_model=WAL`	Írás előre-napló ("WAL") amely növeli a teljesítményt és lehetővé teszi az egyidejű olvasási hozzáférést.
`busy_timeout=5000`	Megakadályozza az írászárolási hibákat míg más írások zajlanak.
`synchronous=NORMAL`	Növeli a tranzakciók tartósságát adatsérülési kockázat nélkül.
`foreign_keys=ON`	Kényszeríti az idegen kulcs hivatkozások (például az egyik táblából a másikba való reláció) kényszerítését. Alapértelmezés szerint ez nincs bekapcsolva az SQLite-ban, de az érvényesítés és az adatintegritás érdekében engedélyezni kell.
`encoding='UTF-8'`	Alapértelmezett kódolás használni a fejlesztő józanságának biztosítására.

Az összes többi alapértelmezett érték az SQLite-ből származik, ahogyan azt a hivatalos PRAGMA dokumentáció.

Egyidejűség

tldr; Használjuk rclone és WebSocket a titkosított SQLite-postafiókok egyidejű olvasásához és írásához.

Olvas

A telefonon lévő e-mail kliens megoldhatja imap.forwardemail.net az egyik Digital Ocean IP-címünkre – és az asztali kliens egy másik IP-címet oldhat fel szolgáltató teljesen.

Függetlenül attól, hogy az e-mail kliens melyik IMAP-kiszolgálóhoz csatlakozik, azt szeretnénk, hogy a kapcsolat valós időben, 100%-os pontossággal olvassa be az adatbázisát:

Ezt használatával érik el rclone val vel --vfs-cache-mode off (az alapértelmezett).
A helyi lemezgyorsítótár használata helyett a gyorsítótár közvetlenül a távoli csatlakoztatásról (az adatbázisból) valós időben kerül beolvasásra.
Abban az esetben, ha a helyi fájl nem található, ez azt jelzi rclone nem sikerült felszerelni, vagy probléma van. Ebben az esetben a WebSocket tartalék az olvasáshoz (ami kissé csökkenti a teljesítményt, de továbbra is megőrzi a szolgáltatás integritását).
Minden szerverünk úgy van beállítva, hogy konzisztens módon csatlakozzon, és valós időben értesít minket az esetleges hibákról.

Ír

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

Olyan lehetőségeket vizsgáltunk, mint pl litestream, rqlite, és dqlite alább – azonban ezek egyike sem felelt meg követelményeinknek.

Írások végrehajtása előreírás-naplózással ("WAL") engedélyezve – biztosítanunk kell, hogy csak egy szerver ("Elsődleges") legyen felelős ezért. WAL drasztikusan felgyorsítja az egyidejűséget, és lehetővé teszi egy író és több olvasó számára.

Az Elsődleges az adatkiszolgálókon fut a titkosított postafiókokat tartalmazó csatolt kötetekkel. Elosztási szempontból figyelembe veheti az összes mögöttes IMAP-kiszolgálót imap.forwardemail.net másodlagos szerverek ("Másodlagos").

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

Az elsődleges kiszolgálók a ws's WebSocketServer szerver.
A másodlagos kiszolgálók a ws's WebSocket kliens, amelyhez csomagolva van websocket-az ígéret szerint és újracsatlakozó-websocket. Ez a két burkolóanyag biztosítja, hogy a WebSocket újracsatlakozik, és adatokat küldhet és fogadhat adott adatbázis-írásokhoz.

Biztonsági mentések

tldr; A titkosított postafiókokról naponta biztonsági másolatot készítenek. Ezenkívül bármikor azonnal kérhet új biztonsági másolatot, vagy letöltheti a legújabb biztonsági másolatot a webhelyről Az én fiókom Domainek Álnevek.

A biztonsági mentésekhez egyszerűen futtassuk az SQLite-t VACUUM INTO parancsot minden nap az IMAP-parancsfeldolgozás során, amely a memóriában lévő IMAP-kapcsolatból származó titkosított jelszót használja fel. A biztonsági mentéseket a rendszer tárolja, ha nem észlel meglévő biztonsági másolatot, vagy ha a SHA-256 A hash módosult a fájlban a legutóbbi biztonsági másolathoz képest.

Vegye figyelembe, hogy a VACUUM INTO parancsot, szemben a beépített backup parancsot, mert ha egy oldal módosul a backup parancsot, akkor elölről kell kezdenie. A VACUUM INTO parancs pillanatképet készít. Lásd ezeket a megjegyzéseket GitHub és Hacker hírek több betekintésért.

Ezen kívül használjuk VACUUM INTO szemben a backup, mert a backup parancs titkosítatlanul hagyná az adatbázist egy rövid ideig, amíg rekey meghívásra kerül (lásd ezt a GitHub megjegyzés betekintés céljából).

A másodlagos utasítja az Elsődlegest a WebSocket kapcsolatot a biztonsági mentés végrehajtásához – és az elsődleges megkapja az erre vonatkozó parancsot, és ezt követően:

Csatlakozzon titkosított postafiókjához.
Szerezzen be írászárat.
Futtasson egy WAL-ellenőrzőpontot ezen keresztül wal_checkpoint(PASSIVE).
Futtassa a VACUUM INTO SQLite parancs.
Győződjön meg arról, hogy a másolt fájlt meg lehet nyitni a titkosított jelszóval (biztonsági/álatlan védelem).
Töltsd fel a Cloudflare R2-be tárolás céljából (vagy saját szolgáltatódba, ha meg van adva).
Tömörítse a kapott biztonsági másolat fájlt a gzip.
Töltsd fel a Cloudflare R2-be tárolás céljából (vagy saját szolgáltatódba, ha meg van adva).

Ne feledje, hogy postaládái titkosítottak – és bár IP-korlátozásokat és egyéb hitelesítési intézkedéseket alkalmazunk a WebSocket-kommunikációhoz – rossz szereplő esetén biztos lehet benne, hogy ha a WebSocket rakomány nem rendelkezik az Ön IMAP-jelszavával, nem tudja megnyitni az adatbázist. .

Postafiókonként jelenleg csak egy biztonsági másolat van tárolva, de a jövőben felajánlhatjuk az időpont szerinti helyreállítást ("PITR").

Keresés

IMAP szervereink támogatják a SEARCH parancs összetett lekérdezésekkel, reguláris kifejezésekkel és még sok mással.

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

raktározunk Date értékeket az SQLite postafiókokban mint ISO 8601 karakterláncok keresztül Date.prototype.toISOString (UTC időzónával az egyenlőségi összehasonlítások megfelelő működéséhez).

A keresési lekérdezésekben szereplő összes tulajdonság indexeit is tárolja.

Projektek

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

Projekt	Célja
Lehetséges	DevOps automatizálási platform a teljes szerverflottánk egyszerű karbantartásához, méretezéséhez és kezeléséhez.
Bree	Job ütemező Node.js és JavaScript számára cron, dátumok, ms, későbbi és emberbarát támogatással.
Kabin	Fejlesztőbarát JavaScript és Node.js naplózási könyvtár a biztonság és az adatvédelem szem előtt tartásával.
enged	Node.js keretrendszer, amely a teljes architektúránkat és mérnöki tervezésünket MVC-vel és még sok mással támogatja.
MongoDB	NoSQL adatbázis-megoldás, amelyet minden egyéb, postafiókokon kívüli adat tárolására használunk (pl. fiókja, beállításai, tartományai és alias-konfigurációi).
Indiai menyét	MongoDB objektumdokumentum modellezés ("ODM"), amelyet a teljes veremünkben használunk. Speciális segítőket írtunk, amelyek lehetővé teszik, hogy egyszerűen tovább használjuk Mongoose SQLite-tal 🎉
node.js	A Node.js egy nyílt forráskódú, többplatformos JavaScript futási környezet, amely az összes szerverfolyamatot futtatja.
Megjegyzés levelező	Node.js csomag e-mailek küldéséhez, kapcsolatok létrehozásához stb. Ennek a projektnek hivatalos támogatói vagyunk.
Redis	Memórián belüli adatbázis a gyorsítótárazáshoz, a csatornák közzétételéhez/előfizetéséhez, valamint a DNS HTTPS-kérésekhez.
SQLite3MultipleCiphers	Az SQLite titkosítási kiterjesztése, amely lehetővé teszi a teljes adatbázisfájlok titkosítását (beleértve az előreírási naplót ("WAL"), napló, visszaállítás, …).
SQLiteStudio	Visual SQLite szerkesztő (amelyet szintén használhat) a fejlesztői postafiókok tesztelésére, letöltésére és megtekintésére.
SQLite	Beágyazott adatbázisréteg a méretezhető, önálló, gyors és rugalmas IMAP-tároláshoz.
Spam szkenner	A Node.js levélszemét-szűrő, e-mail-szűrő és adathalászat-megelőzési eszköz (a mi alternatívánk a Spam Assassin és rspamd).
Mandarin	DNS HTTPS-n keresztüli kérések Node.js-szel és gyorsítótárazás Redis használatával – ami biztosítja a globális konzisztenciát és még sok mást.
Thunderbird	Fejlesztő csapatunk ezt használja (és ezt is ajánlja), mint a preferált e-mail kliens az E-mail továbbításhoz.
UTM	Fejlesztőcsapatunk ezt a virtuális gépek létrehozását használja iOS és macOS rendszerhez, hogy különböző levelezőklienseket (párhuzamosan) teszteljen 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 szerver könyvtár – lásd a megjegyzéseket melléklet de-duplikáció és IMAP protokoll támogatás.
jobb-sqlite3-multiple-ciphers	Gyors és egyszerű API-könyvtár a Node.js-hez az SQLite3 programozott interakcióhoz.
email-sablonok	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	SQL lekérdezéskészítő Mongo stílusú szintaxist használva. Ezzel időt takaríthatunk meg fejlesztőcsapatunknak, mivel továbbra is Mongo-stílusban írhatunk a teljes veremben adatbázis-agnosztikus megközelítéssel. Lekérdezési paraméterek használatával segít elkerülni az SQL injekciós támadásokat is.
knex-séma-ellenőr	SQL segédprogram információk kinyerésére a meglévő adatbázissémáról. Ez lehetővé teszi számunkra, hogy könnyen ellenőrizzük, hogy minden index, táblázat, oszlop, megszorítás és egyebek érvényesek és `1:1` azzal, hogy milyennek kell lenniük. Sőt, automatizált segédprogramokat is írtunk, amelyek új oszlopok és indexek hozzáadására szolgálnak, ha az adatbázissémákban változás történik (rendkívül részletes hibariasztással).
knex	SQL lekérdezéskészítő, amelyet csak adatbázis-áttelepítéshez és séma-érvényesítéshez használunk `knex-schema-inspector`.
mandarin	Automatikus i18n kifejezések fordítása a Markdown használatával Google Cloud Translation API.
mx-connect	Node.js csomag az MX-kiszolgálókkal való kapcsolat feloldásához és létrehozásához, valamint a hibák kezeléséhez.
pm2	Node.js gyártási folyamatkezelő beépített terheléselosztóval (finomhangolt teljesítményhez).
smtp-szerver	SMTP szerver könyvtár – ezt használjuk a levelezőcsere ("MX") és a kimenő SMTP szervereinkhez.
ImapTest	Hasznos eszköz az IMAP-kiszolgálók benchmarkok és RFC-specifikáció szerinti IMAP-protokoll-kompatibilitási teszteléséhez. Ezt a projektet a Galambdúc team (2002 júliusától aktív nyílt forráskódú IMAP és POP3 szerver). Ezzel az eszközzel alaposan teszteltük IMAP-szerverünket.

Megtalálhat más projekteket is, amelyekben részt veszünk forráskódunk a GitHubon.

Szolgáltatók

Szolgáltató	Célja
CloudFlare	DNS-szolgáltató, állapotellenőrzések, terheléselosztók és biztonsági mentési tárhely használata Cloudflare R2.
Digitális óceán	Dedikált szerver hosting, SSD blokk tárhely és felügyelt adatbázisok.
Vultr	Dedikált szerver hosting és SSD blokk tárhely.

gondolatok

Alapelvek

Az e-mail továbbítás a következő elvek szerint készült:

Legyen mindig fejlesztőbarát, a biztonságra és az adatvédelemre összpontosító, valamint átlátható.
Tartsa be MVC, Unix, KISS, DRY, YAGNI, Tizenkét faktor, Occam borotvája, és dogfooding
Célozza meg a selejtes, bootstrapped és ramen nyereséges fejlesztő

Kísérletek

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

Végeztünk néhány kísérletet a végső SQLite-megoldásunkhoz, amint azt fent tárgyaltuk.

Ezek egyike a használat kipróbálása volt rclone és az SQLite egy S3-kompatibilis tárolóréteggel együtt.

Ez a kísérlet arra vezetett, hogy jobban megértsük és felfedezzük a rclone, SQLite és az SQLite körüli szélsőséges eseteket VFS használat:

Ha engedélyezi --vfs-cache-mode writes jelölje meg az rclone-val, akkor az olvasás rendben lesz, de az írások gyorsítótárba kerülnek.
- Ha több IMAP-kiszolgálója van globálisan elosztva, akkor a gyorsítótár ki lesz kapcsolva rajtuk, hacsak nem rendelkezik egyetlen íróval és több figyelővel (például pub/sub megközelítés).
- Ez hihetetlenül összetett, és az ehhez hasonló további komplexitás hozzáadása több hibapontot eredményez.
- Az S3-kompatibilis tárhelyszolgáltatók nem támogatják a részleges fájlmódosítást – ami azt jelenti, hogy a .sqlite fájl az adatbázis teljes megváltoztatását és újratöltését eredményezi.
- Más megoldások pl rsync léteznek, de nem az előreírás-naplóra ("WAL") támogatást – így végül megvizsgáltuk a Litestreamet. Szerencsére a titkosítási használatunk már titkosítja a WAL fájlokat nekünk, ezért nem kell a Litestream-re hagyatkoznunk. Azonban még nem voltunk biztosak a Litestream gyártási célú felhasználásában, és az alábbiakban néhány megjegyzést fűzünk ehhez.
- Ennek az opciónak a használatával --vfs-cache-mode writes (a csak az SQLite használatának módja rclone íráshoz) megpróbálja a teljes adatbázist a semmiből átmásolni a memóriába – egy 10 GB-os postafiók kezelése rendben van, azonban több, rendkívül nagy tárhellyel rendelkező postafiók kezelése az IMAP szerverek memóriakorlátozásába ütközik, és ENOMEM hibák, szegmentálási hibák és adatsérülések.
Ha megpróbálja használni az SQLite-t Virtuális asztalok (pl. használ s3db) annak érdekében, hogy egy S3-kompatibilis tárolórétegen élő adatok legyenek, akkor még több problémába ütközik:
- Az olvasás és az írás rendkívül lassú lesz, mivel az S3 API-végpontokat HTTP-vel kell elérni GET, PUT, HEAD, és POST mód.
- A fejlesztési tesztek azt mutatták, hogy az 500 000-1M+ rekordok számát az üvegszálas interneten továbbra is korlátozza az S3-kompatibilis szolgáltatók írási és olvasási sebessége. Például a fejlesztőink futottak for ciklusokat mindkét szekvenciális SQL végrehajtásához INSERT nyilatkozatok és azok, amelyek tömegesen írnak nagy mennyiségű adatot. Mindkét esetben megdöbbentően lassú volt az előadás.
- Virtuális asztalok nem rendelkezhetnek indexekkel, ALTER TABLE nyilatkozatok, és Egyéb korlátozásokat – ami az adatmennyiségtől függően akár 1-2 perces vagy több késést is eredményez.
- Az objektumokat titkosítás nélkül tárolták, és nem áll rendelkezésre natív titkosítási támogatás.
Használatát is megvizsgáltuk sqlite-s3vfs amely fogalmilag és technikailag hasonló az előző ponthoz (tehát ugyanazok a problémák). Egy lehetőség az egyéni használat sqlite3 build titkosítással burkolva, mint pl wxSQLite3 (amit jelenleg a fenti megoldásunkban használunk) keresztül a telepítőfájl szerkesztése.
Egy másik lehetséges megközelítés a multiplex kiterjesztésEz azonban 32 GB-os korláttal rendelkezik, és bonyolult építési és fejlesztési fejfájást igényelne.
ALTER TABLE utasítások szükségesek (tehát ez teljesen kizárja a virtuális táblák használatát). Szükségünk van ALTER TABLE kijelentéseket annak érdekében, hogy a horogunk knex-schema-inspector megfelelően működjön – ami biztosítja, hogy az adatok ne sérüljenek meg, és a lekért sorok érvényes dokumentumokká konvertálhatók legyenek mongoose sémadefiníciók (amely magában foglalja a kényszert, a változótípust és a tetszőleges adatérvényesítést).
A nyílt forráskódú közösségben az SQLite-tal kapcsolatos S3-kompatibilis projektek szinte mindegyike Pythonban van (és nem JavaScriptben, amelyet a veremünk 100%-ára használunk).
Tömörítési könyvtárak, mint pl sqlite-zstd (lát Hozzászólások) ígéretesnek tűnik, de lehet, hogy még nem áll készen a termelési használatra. Ehelyett alkalmazásoldali tömörítés adattípusokon, mint pl String, Object, Map, Array, Set, és Buffer tisztább és egyszerűbb megközelítés lesz (és könnyebben migrálható is, mivel tárolhatnánk a Boolean zászlót vagy oszlopot – vagy akár használja PRAGMA user_version=1 tömörítéshez ill user_version=0 adatbázis metaadatként való tömörítés nélkül).
- Szerencsére az IMAP szerver tárhelyünkön már be van építve a mellékletek duplikálásának megszüntetése – így minden azonos melléklettel rendelkező üzenet nem őrzi meg a melléklet másolatát – ehelyett egyetlen mellékletet tárolunk több üzenethez és szálhoz egy postafiókban (és egy idegenben hivatkozás kerül felhasználásra a későbbiekben).
A Litestream projekt, amely egy SQLite replikációs és biztonsági mentési megoldás, nagyon ígéretes, és nagy valószínűséggel a jövőben is használni fogjuk.
- A szerző(k) hiteltelenítésének elkerülése végett – mert szeretjük munkájukat és a nyílt forráskódú hozzájárulásaikat immár több mint egy évtizede –, de a valós használatból úgy tűnik, hogy sok fejfájás lehet és lehetséges adatvesztés a használatból.
A biztonsági másolat helyreállításának súrlódásmentesnek és triviálisnak kell lennie. Olyan megoldást használva, mint például a MongoDB with mongodump és mongoexport nem csak unalmas, de időigényes és konfigurációs összetett.
- Az SQLite adatbázisok egyszerűvé teszik (egyetlen fájl).
- Olyan megoldást akartunk kialakítani, ahol a felhasználók bármikor elvihetik a postafiókjukat és távozhatnak.
  - Egyszerű Node.js parancsok fs.unlink('mailbox.sqlite')) és végleg törlődik a lemeztárból.
  - Hasonlóképpen használhatunk S3-kompatibilis API-t HTTP-vel DELETE a pillanatképek és biztonsági másolatok egyszerű eltávolításához a felhasználók számára.
- Az SQLite volt a legegyszerűbb, leggyorsabb és legköltséghatékonyabb megoldás.

Alternatívák hiánya

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

Mi szerintem ennek oka lehet a meglévő e-mail szolgáltatásokhoz, amelyek már meglévő technológiát használnak spagetti kód 🍝.

A legtöbb, ha nem az összes létező e-mail szolgáltató vagy zárt forráskódú, vagy nyílt forráskódúként hirdet, 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ó) mindez a háttérben (szerveren) történik, és nem a front-end (kliens).

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

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

Mély merülés: Hogyan használjuk a kvantumbiztonságos titkosított SQLite postafiókokat az adatvédelemre fókuszáló és biztonságos e-mail szolgáltatásunkhoz