Šifrované schránky SQLite pro vaše soukromí

Na rozdíl od jiných e-mailových služeb zajišťujeme, že ke své poštovní schránce budete mít vždy přístup pouze vy .

Úvodní slovo

tldr; Naše e-mailová služba je 100% open source a zaměřené na soukromí prostřednictvím zabezpečených a šifrovaných schránek SQLite.

Dokud jsme nespustili podpora IMAP, použili jsme MongoDB pro naše potřeby trvalého ukládání dat.

Tato technologie je úžasná a používáme ji dodnes – ale abyste mohli mít šifrování v klidu s MongoDB, musíte použít poskytovatele, který nabízí MongoDB Enterprise, jako je Digital Ocean nebo Mongo Atlas – nebo zaplatit za podnikovou licenci (a následně musí pracovat s latencí prodejního týmu).

Náš tým na Přeposlat e-mail potřeboval vývojářské, škálovatelné, spolehlivé a šifrované řešení úložiště pro poštovní schránky IMAP. Jako vývojáři s otevřeným zdrojovým kódem bylo používání technologie, kterou musíte zaplatit licenční poplatek, abyste získali funkci šifrování v klidu, proti naše zásady – a tak jsme experimentovali, zkoumali a vyvinuli zcela nové řešení, abychom tyto potřeby vyřešili.

Místo používání sdílené databáze k ukládání vašich poštovních schránek ukládáme a šifrujeme vaše poštovní schránky individuálně pomocí vašeho hesla (které máte pouze vy). Naše e-mailová služba je tak bezpečná, že pokud zapomenete heslo, přijdete o svou poštovní schránku (a je třeba obnovit pomocí offline záloh nebo začít znovu).

Pokračujte ve čtení, zatímco se níže ponoříme s a srovnání poskytovatelů e-mailových služeb, jak naše služba funguje, náš technologický zásobník, a více.

Porovnání poskytovatelů e-mailových služeb

Jsme jediným 100% poskytovatelem e-mailových služeb s otevřeným zdrojovým kódem a zaměřeným na soukromí, který ukládá jednotlivě šifrované poštovní schránky SQLite, nabízí neomezený počet domén, aliasů a uživatelů a má odchozí podporu SMTP, IMAP a POP3:

Na rozdíl od jiných poskytovatelů e-mailu nemusíte u Forward Email platit za úložiště na základě domény nebo aliasu. Úložiště je sdíleno napříč celým vaším účtem – takže pokud máte více vlastních názvů domén a více aliasů na každém, pak jsme pro vás dokonalým řešením. Všimněte si, že stále můžete vynutit limity úložiště, pokud si to přejete na základě domény nebo aliasu.

Přečtěte si Srovnání e-mailových služeb

Jak to funguje

  1. Pomocí e-mailového klienta, jako je Apple Mail, Thunderbird, Gmail nebo Outlook – se připojíte k našemu zabezpečenému IMAP servery pomocí vašeho uživatelského jména a hesla:

    • Vaše uživatelské jméno je váš úplný alias s vaší doménou, jako je např hello@example.com.
    • Vaše heslo je vygenerováno náhodně a po kliknutí se vám zobrazí pouze na 30 sekund Vygenerovat heslo z Můj účet Domény Přezdívky.
  2. Po připojení váš e-mailový klient odešle Příkazy protokolu IMAP na náš server IMAP, aby byla vaše poštovní schránka synchronizovaná. To zahrnuje psaní a ukládání konceptů e-mailů a další akce, které můžete provádět (např. označit e-mail jako důležitý nebo označit e-mail jako spam/nevyžádaná pošta).

  3. Servery pro výměnu pošty (běžně známé jako servery „MX“) přijímají nové příchozí e-maily a ukládají je do vaší poštovní schránky. Když k tomu dojde, váš e-mailový klient dostane upozornění a synchronizuje vaši poštovní schránku. Naše servery pro výměnu pošty mohou přeposlat váš e-mail jednomu nebo více příjemcům (včetně webhooky), ukládat váš e-mail pro vás do vašeho šifrovaného úložiště IMAP u nás, nebo oboje!

    Máte zájem dozvědět se více? Číst jak nastavit přeposílání e-mailů, jak funguje naše služba výměny poštynebo zobrazit naši průvodci.

  4. Náš návrh bezpečného e-mailového úložiště v zákulisí funguje dvěma způsoby, jak udržet vaše poštovní schránky zašifrované a přístupné pouze vám:

    • Když pro vás obdrží nový e-mail od odesílatele, naše servery pro výměnu pošty za vás zapíší do individuální, dočasné a šifrované poštovní schránky.

      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!
      
    • Když se připojíte k našemu IMAP serveru pomocí svého e-mailového klienta, vaše heslo se poté zašifruje v paměti a použije se ke čtení a zápisu do vaší poštovní schránky. S tímto heslem lze do vaší poštovní schránky pouze číst a zapisovat. Mějte na paměti, že jste jediný, kdo má toto heslo, jen ty můžete číst a psát do vaší poštovní schránky, když k ní přistupujete. Až se váš e-mailový klient příště pokusí požádat o poštu nebo synchronizovat, vaše nové zprávy budou přeneseny z této dočasné poštovní schránky a uloženy do vašeho skutečného souboru poštovní schránky pomocí vašeho dodaného hesla. Všimněte si, že tato dočasná poštovní schránka je poté vymazána a odstraněna, takže zprávy má pouze vaše poštovní schránka chráněná heslem.

    • Pokud jste připojeni k IMAP (např. pomocí e-mailového klienta, jako je Apple Mail nebo Thunderbird), nemusíme zapisovat na dočasné diskové úložiště. Místo toho se načte a použije vaše heslo IMAP zašifrované v paměti. V reálném čase, když se vám zpráva pokouší doručit, odešleme požadavek WebSocket na všechny servery IMAP, kde se jich zeptáme, zda pro vás mají aktivní relaci (toto je část načtení), a následně ji předáme šifrované heslo v paměti – takže nemusíme psát do dočasné schránky, můžeme psát do vaší skutečné šifrované schránky pomocí vašeho zašifrovaného hesla.

      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!
      
  5. Zálohy vašich šifrovaných poštovních schránek jsou vyráběny denně. Můžete také kdykoli požádat o novou zálohu nebo stáhnout nejnovější zálohu z Můj účet Domény Přezdívky. Pokud se rozhodnete přejít na jinou e-mailovou službu, můžete kdykoli snadno migrovat, stahovat, exportovat a vymazat své poštovní schránky a zálohy.

Technologie

Databáze

Prozkoumali jsme další možné vrstvy úložiště databáze, ale žádná nesplňovala naše požadavky tak jako SQLite:

DatabázeŠifrování v kliduSandboxed Poštovní schránkyLicencePoužívá se všude
SQLite✅ Ano s SQLite3MultipleCiphers✅ Veřejná doména
MongoDB"K dispozici pouze v MongoDB Enterprise"❌ Relační databáze❌ AGPL a SSPL-1.0
rqlitePouze síť❌ Relační databázeMIT
dqliteNetestováno a zatím není podporováno?Netestováno a zatím není podporováno?LGPL-3.0-only
PostgreSQLAno❌ Relační databázePostgreSQL (podobný BSD nebo MIT)
MariaDBPouze pro InnoDB❌ Relační databázeGPLv2 a BUSL-1.1
ŠvábDBFunkce pouze pro podniky❌ Relační databázeBUSL-1.1 a další

Tady je blogový příspěvek, který porovnává několik možností úložiště databáze SQLite v tabulce výše.

Bezpečnostní

Po celou dobu používáme šifrování v klidu (AES-256), šifrování při přenosu (TLS), DNS přes HTTPS ("DoH") pomocí 🍊 Mandarinka, a sqleet (ChaCha20-Poly1305) šifrování na poštovních schránkách. Kromě toho používáme dvoufaktorovou autentizaci založenou na tokenech (na rozdíl od SMS, která je podezřelá muž-in-the-middle-útoky), rotované klíče SSH se zakázaným přístupem root, exkluzivní přístup k serverům prostřednictvím omezených IP adres a další.

V případě an útok zlé služky nebo nepoctivý zaměstnanec od dodavatele třetí strany, Vaši poštovní schránku lze stále otevřít pouze pomocí vygenerovaného hesla. Ujišťujeme vás, že se nespoléháme na žádné dodavatele třetích stran kromě našich poskytovatelů serverů pro stížnosti SOC typu 2 Cloudflare, Digital Ocean a Vultr.

Naším cílem je mít co nejméně jediný bod selhání jak je to možné.

Poštovní schránky

tldr; Naše servery IMAP používají individuálně šifrované databáze SQLite pro každou z vašich poštovních schránek.

SQLite je velmi populární vestavěná databáze – aktuálně běží na vašem telefonu a počítači – a používají téměř všechny hlavní technologie.

Například na našich šifrovaných serverech existuje poštovní schránka databáze SQLite linux@example.com, info@example.com, hello@example.com a tak dále – jeden pro každého jako a .sqlite databázový soubor. Databázové soubory nepojmenováváme ani e-mailovou adresou – místo toho používáme BSON ObjectID a unikátní vygenerované UUID, které nesdílí, komu schránka patří ani pod jakou e-mailovou adresou se nachází (např. 353a03f21e534321f5d6e267.sqlite).

Každá z těchto databází se sama zašifruje pomocí vašeho hesla (které máte pouze vy). sqleet (ChaCha20-Poly1305). To znamená, že vaše poštovní schránky jsou individuálně šifrované, samostatné, sandboxeda přenosné.

Doladili jsme SQLite s následujícím PRAGMA:

PRAGMAÚčel
cipher=chacha20Šifrování databáze ChaCha20-Poly1305 SQLite. Odkaz better-sqlite3-multiple-ciphers pod Projekty pro větší přehled.
key="****************"Toto je vaše dešifrované heslo pouze v paměti, které se předává prostřednictvím připojení IMAP vašeho e-mailového klienta k našemu serveru. Pro každou relaci čtení a zápisu se vytvářejí a zavírají nové instance databáze (aby se zajistilo sandboxing a izolace).
journal_model=WALWrite-ahead-log ("WAL") což zvyšuje výkon a umožňuje souběžný přístup ke čtení.
busy_timeout=5000Zabraňuje chybám blokování zápisu zatímco probíhají jiné zápisy.
synchronous=NORMALZvyšuje trvanlivost transakcí bez rizika poškození dat.
foreign_keys=ONVynucuje, aby byly vynuceny odkazy na cizí klíč (např. vztah z jedné tabulky do druhé). Ve výchozím nastavení to není v SQLite zapnuto, ale pro ověření a integritu dat by měla být povolena.
encoding='UTF-8'Výchozí kódování použít k zajištění duševního zdraví vývojářů.

Všechny ostatní výchozí hodnoty jsou z SQLite, jak je uvedeno v oficiální dokumentace PRAGMA.

Konkurence

tldr; Používáme WebSocket pro souběžné čtení a zápisy do vašich šifrovaných schránek SQLite.

Čte

Váš e-mailový klient ve vašem telefonu může vyřešit problém imap.forwardemail.net na jednu z našich IP adres Digital Ocean – a váš počítačový klient může rozlišit oddělenou IP od jiné poskytovatel celkem.

Bez ohledu na to, ke kterému serveru IMAP se váš e-mailový klient připojuje, chceme, aby připojení načítalo z vaší databáze v reálném čase se 100% přesností. To se provádí prostřednictvím WebSockets.

Píše

Zápis do vaší databáze je trochu jiný – protože SQLite je vestavěná databáze a vaše poštovní schránka žije ve výchozím nastavení v jediném souboru.

Zkoumali jsme možnosti jako např litestream, rqlite, a dqlite níže – žádný z nich však nesplňoval naše požadavky.

Chcete-li provést zápisy s protokolováním napřed ("WAL") povoleno – musíme zajistit, aby za to odpovídal pouze jeden server ("Primární"). WAL drasticky urychluje souběžnost a umožňuje jeden spisovatel a více čtenářů.

Primární běží na datových serverech s připojenými svazky obsahujícími šifrované poštovní schránky. Z hlediska distribuce byste mohli zvážit všechny jednotlivé servery IMAP za sebou imap.forwardemail.net být sekundárními servery ("sekundární").

Realizujeme obousměrnou komunikaci s WebSockets:

  • Primární servery používají instanci ws's WebSocketServer server.
  • Sekundární servery používají instanci ws's WebSocket klient, který je zabalen s websocket-jak-slíbil a reconnecting-websocket. Tyto dva obaly zajišťují, že WebSocket znovu připojí a může odesílat a přijímat data pro konkrétní zápisy do databáze.

Zálohy

tldr; Zálohy vašich šifrovaných poštovních schránek se provádějí denně. Můžete také okamžitě požádat o novou zálohu nebo si kdykoli stáhnout nejnovější zálohu Můj účet Domény Přezdívky.

Pro zálohování jednoduše spustíme SQLite VACUUM INTO příkaz každý den během zpracování příkazů IMAP, které využívá vaše zašifrované heslo z připojení IMAP v paměti. Zálohy se ukládají, pokud není detekována žádná existující záloha nebo pokud SHA-256 hash se v souboru změnil ve srovnání s nejnovější zálohou.

Všimněte si, že používáme VACUUM INTO příkaz na rozdíl od vestavěného backup příkaz, protože pokud je stránka změněna během a backup příkazovou operaci, pak musí začít znovu. The VACUUM INTO příkaz pořídí snímek. Viz tyto komentáře na GitHub a Hackerské zprávy pro větší přehled.

Navíc používáme VACUUM INTO naproti tomu backup, protože backup příkaz by ponechal databázi nezašifrovanou na krátkou dobu, dokud rekey je vyvoláno (viz tento GitHub komentář pro nahlédnutí).

Sekundární dá primárnímu pokyn WebSocket připojení k provedení zálohy – a primární poté obdrží příkaz k provedení zálohy a následně:

  1. Připojte se ke své šifrované poštovní schránce.
  2. Získejte zámek pro zápis.
  3. Spusťte kontrolní bod WAL přes wal_checkpoint(PASSIVE).
  4. Spusťte VACUUM INTO Příkaz SQLite.
  5. Ujistěte se, že zkopírovaný soubor lze otevřít pomocí zašifrovaného hesla (ochrana/ochrana).
  6. Nahrajte jej do Cloudflare R2 pro uložení (nebo vašeho vlastního poskytovatele, pokud je uveden).

Pamatujte, že vaše poštovní schránky jsou šifrované – a přestože máme pro komunikaci WebSocket zavedena omezení IP a další autentizační opatření – v případě špatného aktéra si můžete být jisti, že pokud obsah WebSocket nemá vaše heslo IMAP, nemůže otevřít vaši databázi. .

V současné době je na poštovní schránku uložena pouze jedna záloha, ale v budoucnu můžeme nabídnout obnovení v určitém okamžiku ("PITR").

Naše servery IMAP podporují SEARCH příkaz se složitými dotazy, regulárními výrazy a dalšími.

Rychlý výkon vyhledávání je díky FTS5 a sqlite-regex.

Skladujeme Date hodnoty v poštovních schránkách SQLite jako ISO 8601 řetězce přes Date.prototype.toISOString (s časovým pásmem UTC pro správné fungování porovnávání rovnosti).

Indexy jsou také uloženy pro všechny vlastnosti, které jsou ve vyhledávacích dotazech.

Projekty

Zde je tabulka s přehledem projektů, které používáme v našem zdrojovém kódu a procesu vývoje (seřazeno abecedně):

ProjektÚčel
AnsibleAutomatizační platforma DevOps pro snadnou údržbu, škálování a správu celé naší flotily serverů.
BreePlánovač úloh pro Node.js a JavaScript s podporou cronu, dat, ms, novější a uživatelsky přívětivou podporou.
ChataVývojářská knihovna JavaScript a protokolování Node.js s ohledem na bezpečnost a soukromí.
NechatNode.js framework, který pohání celou naši architekturu a inženýrský design s MVC a dalšími.
MongoDBNoSQL databázové řešení, které používáme pro ukládání všech ostatních dat mimo poštovní schránky (např. váš účet, nastavení, domény a konfigurace aliasů).
MangustaMongoDB objektové modelování dokumentů ("ODM"), které používáme v celém našem zásobníku. Sepsali jsme speciální pomocníky, které nám umožňují jednoduše pokračovat v používání Mongoose s SQLite 🎉
Node.jsNode.js je open-source, multiplatformní běhové prostředí JavaScriptu, které spouští všechny naše serverové procesy.
NodemailerBalíček Node.js pro odesílání e-mailů, vytváření spojení a další. Jsme oficiálním sponzorem tohoto projektu.
RedisDatabáze v paměti pro ukládání do mezipaměti, kanály pro publikování/odběry a DNS přes požadavky HTTPS.
SQLite3MultipleCiphersRozšíření šifrování pro SQLite, které umožňuje šifrování celých databázových souborů (včetně protokolu pro zápis dopředu ("WAL"), deník, návrat, …).
SQLiteStudioVisual SQLite editor (který můžete také použít) k testování, stahování a prohlížení vývojových poštovních schránek.
SQLiteVestavěná databázová vrstva pro škálovatelné, samostatné, rychlé a odolné úložiště IMAP.
Skener spamuAnti-spam, filtrování e-mailů a nástroj pro prevenci phishingu Node.js (naše alternativa k Spam Assassin a rspamd).
MandarinkaPožadavky DNS přes HTTPS s Node.js a ukládání do mezipaměti pomocí Redis – což zajišťuje globální konzistenci a mnoho dalšího.
ThunderbirdNáš vývojový tým to používá (a také to doporučuje) jako preferovaný e-mailový klient pro použití s Forward Email.
UTMNáš vývojový tým používá toto vytváření virtuálních strojů pro iOS a macOS k testování různých e-mailových klientů (paralelně) s našimi servery IMAP a SMTP.
UbuntuModerní open-source serverový operační systém na bázi Linuxu, který pohání veškerou naši infrastrukturu.
Divoká kachnaKnihovna IMAP serveru – viz její poznámky na deduplikace příloh a Podpora protokolu IMAP.
better-sqlite3-multiple-ciphersRychlá a jednoduchá knihovna API pro Node.js pro programovou interakci s SQLite3.
e-mailové šablonyVývojářský e-mailový rámec pro vytváření, náhled a odesílání vlastních e-mailů (např. oznámení o účtu a další).
json-sqlTvůrce dotazů SQL pomocí syntaxe ve stylu Mongo. To našemu vývojovému týmu šetří čas, protože můžeme pokračovat v psaní ve stylu Mongo napříč celým zásobníkem s přístupem agnostika k databázi. Pomáhá také vyhnout se útokům SQL injection pomocí parametrů dotazu.
knex-schema-inspectorNástroj SQL pro extrakci informací o existujícím schématu databáze. To nám umožňuje snadno ověřit, že všechny indexy, tabulky, sloupce, omezení a další jsou platné a jsou 1:1 s tím, jak by měli být. Napsali jsme dokonce automatické pomocníky pro přidání nových sloupců a indexů, pokud jsou provedeny změny ve schématech databáze (také s extrémně podrobným upozorněním na chyby).
knexTvůrce dotazů SQL, který používáme pouze pro migrace databází a ověřování schémat knex-schema-inspector.
mandarinkaAutomatický i18n překlad frází s podporou použití Markdown Google Cloud Translation API.
mx-connectBalíček Node.js k vyřešení a navázání spojení se servery MX a zpracování chyb.
pm2Manažer produkčního procesu Node.js s vestavěným nástrojem pro vyrovnávání zatížení (doladěno za výkon).
smtp-serverKnihovna serverů SMTP – používáme ji pro naše servery pro výměnu pošty ("MX") a odchozí SMTP servery.
ImapTestUžitečný nástroj pro testování IMAP serverů proti benchmarkům a kompatibilitě IMAP protokolu specifikace RFC. Tento projekt byl vytvořen společností Holubník tým (aktivní open-source IMAP a POP3 server od července 2002). S tímto nástrojem jsme rozsáhle testovali náš server IMAP.

Můžete najít další projekty, ve kterých používáme náš zdrojový kód na GitHubu.

Poskytovatelé

PoskytovatelÚčel
ZataženoPoskytovatel DNS, kontroly stavu, nástroje pro vyrovnávání zatížení a úložiště záloh Cloudflare R2.
Digitální oceánDedikovaný server hosting, SSD blokové úložiště a spravované databáze.
VultrDedikovaný server hosting a úložiště bloků SSD.

Myšlenky

Zásady

Přeposílání e-mailů je navrženo podle těchto zásad:

  1. Buďte vždy přátelští pro vývojáře, zaměřte se na bezpečnost a soukromí a buďte transparentní.
  2. Dodržovat MVC, Unix, KISS, DRY, YAGNI, Dvanáctý faktor, Occamova břitva, a interní testování
  3. Zaměřte se na útržkovité, bootstrapped a ramen-výnosný vývojář

Experimenty

tldr; V konečném důsledku není použití objektového úložiště kompatibilního s S3 a/nebo virtuálních tabulek technicky proveditelné z důvodů výkonu a je náchylné k chybám kvůli omezením paměti.

Udělali jsme několik experimentů vedoucích k našemu konečnému řešení SQLite, jak je uvedeno výše.

Jedním z nich bylo zkusit použít rclone a SQLite spolu s vrstvou úložiště kompatibilní s S3.

Tento experiment nás vedl k dalšímu pochopení a objevení okrajových případů kolem rclone, SQLite a VFS používání:

  • Pokud povolíte --vfs-cache-mode writes příznak s rclone, pak bude čtení v pořádku, ale zápisy budou uloženy do mezipaměti.
    • Pokud máte více serverů IMAP distribuovaných globálně, pak mezi nimi bude mezipaměť vypnutá, pokud nemáte jednoho zapisovače a více posluchačů (např. přístup typu pub/sub).
    • To je neuvěřitelně složité a přidání jakékoli další složitosti, jako je tato, bude mít za následek více jednotlivých bodů selhání.
    • Poskytovatelé úložiště kompatibilní s S3 nepodporují částečné změny souborů – což znamená jakoukoli změnu souboru .sqlite soubor bude mít za následek kompletní změnu a opětovné nahrání databáze.
    • Další řešení jako rsync existují, ale nezaměřují se na zápis napřed ("WAL") podpora – takže jsme skončili u kontroly Litestreamu. Naštěstí naše použití šifrování již šifruje WAL soubory za nás, takže se v tom nemusíme spoléhat na Litestream. Nicméně jsme si ještě nebyli jisti Litestreamem pro produkční použití a máme k tomu několik poznámek níže.
    • Pomocí této možnosti --vfs-cache-mode writes (ta pouze způsob, jak používat SQLite rclone pro zápisy) se pokusí zkopírovat celou databázi od začátku v paměti – manipulace s jednou 10GB poštovní schránkou je v pořádku, ale manipulace s více poštovními schránkami s příliš velkým úložištěm způsobí, že servery IMAP narazí na omezení paměti a ENOMEM chyby, chyby segmentace a poškození dat.
  • Pokud se pokusíte použít SQLite Virtuální stoly (např. pomocí s3db), abyste měli data živá na vrstvě úložiště kompatibilní s S3, narazíte na několik dalších problémů:
    • Čtení a zápis bude extrémně pomalý, protože koncové body S3 API budou muset být zasaženy HTTP GET, PUT, HEAD, a POST metody.
    • Vývojové testy ukázaly, že překročení 500K-1M+ záznamů na optickém internetu je stále omezeno propustností zápisu a čtení u poskytovatelů kompatibilních s S3. Například naši vývojáři běželi for smyčky pro provedení obou sekvenčních SQL INSERT výpisy a ty, které hromadně zapisovaly velké množství dat. V obou případech byl výkon neuvěřitelně pomalý.
    • Virtuální stoly nemůže mít indexy, ALTER TABLE prohlášení a jiný omezení – což vede ke zpožděním až 1-2 minutám nebo více v závislosti na množství dat.
    • Objekty byly uloženy nezašifrované a není k dispozici žádná podpora nativního šifrování.
  • Také jsme zkoumali použití sqlite-s3vfs který je koncepčně a technicky podobný předchozímu bodu (takže má stejné problémy). Možností by bylo použít vlastní sqlite3 sestavení zabalené se šifrováním jako např wxSQLite3 (které aktuálně používáme v našem řešení výše) prostřednictvím editaci instalačního souboru.
  • Dalším potenciálním přístupem bylo použití multiplexní rozšíření, nicméně to má omezení na 32 GB a vyžadovalo by to složité vytváření a vývoj.
  • ALTER TABLE jsou vyžadovány příkazy (takže to zcela vylučuje použití virtuálních tabulek). Potřebujeme ALTER TABLE prohlášení, aby náš háček s knex-schema-inspector fungovat správně – což zajišťuje, že data nebudou poškozena a načtené řádky lze převést na platné dokumenty podle našeho mongoose definice schémat (které zahrnují omezení, typ proměnné a libovolné ověření dat).
  • Téměř všechny projekty kompatibilní s S3 související s SQLite v komunitě open source jsou v Pythonu (a ne JavaScriptu, který používáme pro 100 % našeho zásobníku).
  • Kompresní knihovny jako např sqlite-zstd (vidět komentáře) vypadají slibně, ale ještě nemusí být připraven k produkčnímu použití. Namísto komprese na straně aplikace u datových typů, jako je např String, Object, Map, Array, Set, a Buffer bude čistší a snazší přístup (a také snazší migrace, protože bychom mohli uložit a Boolean vlajka nebo sloup – nebo dokonce použití PRAGMA user_version=1 pro kompresi popř user_version=0 bez komprese jako metadata databáze).
    • Naštěstí již máme v úložišti našeho serveru IMAP implementovanou deduplikaci příloh – proto si každá zpráva se stejnou přílohou neuchová kopii přílohy – místo toho je v poštovní schránce uložena jedna příloha pro více zpráv a vláken (a cizí následně se použije odkaz).
  • Projekt Litestream, což je řešení replikace a zálohování SQLite, je velmi slibný a s největší pravděpodobností jej v budoucnu využijeme.
  • Obnova zálohy musí být bezproblémová a triviální. Použití řešení, jako je MongoDB s mongodump a mongoexport je nejen zdlouhavé, ale časově náročné a má složitou konfiguraci.
    • Databáze SQLite to zjednodušují (je to jeden soubor).
    • Chtěli jsme navrhnout řešení, kde by si uživatelé mohli vzít svou poštovní schránku a kdykoli odejít.
      • Jednoduché příkazy Node.js do fs.unlink('mailbox.sqlite')) a bude trvale vymazán z diskového úložiště.
      • Podobně můžeme použít API kompatibilní s S3 s HTTP DELETE pro snadné odstranění snímků a záloh pro uživatele.
    • SQLite bylo nejjednodušší, nejrychlejší a cenově nejefektivnější řešení.

Nedostatek alternativ

Pokud je nám známo, žádné jiné e-mailové služby nejsou takto navrženy ani nejsou open source.

My myslím, že to může být způsobeno na stávající e-mailové služby využívající starší technologii ve výrobě kód špagety 🍝.

Většina stávajících poskytovatelů e-mailových služeb, pokud ne všichni, má buď uzavřený zdroj, nebo inzeruje jako open source, ale ve skutečnosti je open-source pouze jejich front-end.

Nejcitlivější část e-mailu (skutečná interakce úložiště/IMAP/SMTP) vše se děje na back-endu (serveru) a ne na front-endu (klient).

Vyzkoušejte Přeposlat e-mail

Zaregistrujte se ještě dnes na https://forwardemail.net! 🚀