Kvanteresistent e-mail-tjeneste i 2024

Forord

tldr; Vores e-mail service er 100% open source og privatlivsfokuseret gennem sikre og krypterede SQLite-postkasser.

Indtil vi lancerede IMAP support, brugte vi MongoDB til vores vedvarende datalagringsbehov.

Denne teknologi er fantastisk, og vi bruger den stadig i dag - men for at have encryption-at-rest med MongoDB skal du bruge en udbyder, der tilbyder MongoDB Enterprise, såsom Digital Ocean eller Mongo Atlas - eller betale for en virksomhedslicens (og efterfølgende skal arbejde med salgsteamets latency).

Vores team kl Videresend e-mail havde brug for en udviklervenlig, skalerbar, pålidelig og krypteret lagringsløsning til IMAP-postkasser. Som open source-udviklere skal du ved at bruge en teknologi betale et licensgebyr for at få funktionen kryptering i hvile var imod vores principper – og så vi eksperimenterede, undersøgte og udviklede en ny løsning fra bunden til at løse disse behov.

I stedet for at bruge en delt database til at gemme dine postkasser, gemmer og krypterer vi individuelt dine postkasser med din adgangskode (som kun du har). Vores e-mail-service er så sikker, at hvis du glemmer din adgangskode, så mister du din postkasse (og skal gendanne med offline sikkerhedskopier eller starte forfra).

Fortsæt med at læse, mens vi tager et dybt dyk nedenfor med en sammenligning af e-mail-tjenesteudbydere, hvordan vores service fungerer, vores teknologistak, og mere.

Sammenligning af e-mail-tjenesteudbydere

Vi er den eneste 100 % open source og privatlivsfokuserede e-mail-tjenesteudbyder, der gemmer individuelt krypterede SQLite-postkasser, tilbyder ubegrænsede domæner, aliaser og brugere og har udgående SMTP-, IMAP- og POP3-understøttelse:

I modsætning til andre e-mail-udbydere behøver du ikke betale for lagerplads pr. domæne eller alias med Videresend e-mail. Lagerplads deles på tværs af hele din konto – så hvis du har flere tilpassede domænenavne og flere aliaser på hver, så er vi den perfekte løsning for dig. Bemærk, at du stadig kan håndhæve lagergrænser, hvis det ønskes på et domæne- eller aliasbasis.

Læs sammenligning af e-mail-tjenester

Hvordan virker det

Ved at bruge din e-mail-klient som Apple Mail, Thunderbird, Gmail eller Outlook - opretter du forbindelse til vores sikre IMAP servere ved hjælp af dit brugernavn og adgangskode:
- Dit brugernavn er dit fulde alias med dit domæne som f.eks hello@example.com.
- Din adgangskode genereres tilfældigt og vises kun til dig i 30 sekunder, når du klikker Generer adgangskode fra Min konto Domæner Aliaser.
Når du er tilsluttet, vil din e-mail-klient sende IMAP protokol kommandoer til vores IMAP-server for at holde din postkasse synkroniseret. Dette omfatter skrivning og lagring af kladder til e-mails og andre handlinger, du kan gøre (f.eks. mærke en e-mail som Vigtig eller markere en e-mail som spam/junkmail).
Mailudvekslingsservere (almindeligvis kendt som "MX"-servere) modtager ny indgående e-mail og gemmer den i din postkasse. Når dette sker, vil din e-mail-klient få besked og synkronisere din postkasse. Vores mailudvekslingsservere kan videresende din e-mail til en eller flere modtagere (inkl webhooks), gemme din e-mail for dig i dit krypterede IMAP-lager hos os, eller begge!

Interesseret i at lære mere? Læs hvordan man opsætter videresendelse af e-mail, hvordan vores postudvekslingstjeneste fungerereller se vores guider.
Bag kulisserne fungerer vores sikre e-mail-lagringsdesign på to måder for at holde dine postkasser krypteret og kun tilgængelige for dig:
- Når der modtages ny mail til dig fra en afsender, skriver vores mailudvekslingsservere til en individuel, midlertidig og krypteret postkasse for dig.
```
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!
```
- Når du opretter forbindelse til vores IMAP-server med din e-mail-klient, krypteres din adgangskode i hukommelsen og bruges til at læse og skrive til din postkasse. Din postkasse kan kun læses fra og skrives til med denne adgangskode. Husk, at da du er den eneste med denne adgangskode, kun dig kan læse og skrive til din postkasse, når du tilgår den. Næste gang din e-mail-klient forsøger at polle efter e-mail eller synkronisere, vil dine nye meddelelser blive overført fra denne midlertidige postkasse og gemt i din faktiske postkassefil ved hjælp af din medfølgende adgangskode. Bemærk, at denne midlertidige postkasse renses og slettes efterfølgende, så kun din adgangskodebeskyttede postkasse har beskederne.
- Hvis du er forbundet til IMAP (f.eks. ved at bruge en e-mail-klient som Apple Mail eller Thunderbird), så behøver vi ikke at skrive til midlertidigt disklager. Din krypterede IMAP-adgangskode i hukommelsen bliver i stedet hentet og brugt. I realtid, når en meddelelse forsøger at blive leveret til dig, sender vi en WebSocket-anmodning til alle IMAP-servere og spørger dem, om de har en aktiv session til dig (dette er hente-delen), og derefter videresende den krypteret adgangskode i hukommelsen – så vi behøver ikke at skrive til en midlertidig postkasse, vi kan skrive til din faktiske krypterede postkasse ved hjælp af din krypterede adgangskode.
```
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!
```
Sikkerhedskopier af dine krypterede postkasser laves dagligt. Du kan også til enhver tid anmode om en ny backup eller downloade den seneste backup fra Min konto Domæner Aliaser. Hvis du beslutter dig for at skifte til en anden e-mail-tjeneste, kan du nemt migrere, downloade, eksportere og rense dine postkasser og sikkerhedskopier når som helst.

teknologier

Databaser

Vi undersøgte andre mulige databaselagerlag, men ingen opfyldte vores krav så meget som SQLite gjorde:

Database	Kryptering i hvile	Sandkasse Postkasser	Licens	Brugt overalt
SQLite ⭐	✅ Ja med SQLite3MultipleCiphers	✅	✅ Offentligt domæne	✅
MongoDB	❌ "Kun tilgængelig i MongoDB Enterprise"	❌ Relationel database	❌ AGPL og `SSPL-1.0`	❌
rqlite	❌ Kun netværk	❌ Relationel database	✅ `MIT`	❌
dqlite	❌ Utestet og endnu ikke understøttet?	❌ Utestet og endnu ikke understøttet?	✅ `LGPL-3.0-only`	❌
PostgreSQL	✅ Ja	❌ Relationel database	✅ `PostgreSQL` (svarende til `BSD` eller `MIT`)	❌
MariaDB	✅ Kun til InnoDB	❌ Relationel database	✅ `GPLv2` og `BUSL-1.1`	❌
KakerlakDB	❌ Kun virksomhedsfunktion	❌ Relationel database	❌ `BUSL-1.1` og andre	❌

Her er en blogindlæg, der sammenligner flere SQLite-databaselagringsmuligheder i tabellen ovenfor.

Sikkerhed

Vi bruger hele tiden kryptering i hvile (AES-256), kryptering under transport (TLS), DNS over HTTPS ("DoH") ved hjælp af 🍊 Mandarin, og sqleet (ChaCha20-Poly1305) kryptering på postkasser. Derudover bruger vi token-baseret to-faktor autentificering (i modsætning til SMS, som er mistænkelig for mand-i-midten-angreb), roterede SSH-nøgler med root-adgang deaktiveret, eksklusiv adgang til servere via begrænsede IP-adresser og mere.

I tilfælde af en onde tjenestepige angreb eller useriøs medarbejder fra en tredjepartsleverandør, din postkasse kan stadig kun åbnes med din oprettede adgangskode. Du kan være sikker på, at vi ikke er afhængige af andre tredjepartsleverandører end vores SOC Type 2-klageserverudbydere af Cloudflare, Digital Ocean og Vultr.

Vores mål er at have så få enkelt point of failure som muligt.

Postkasser

tldr; Vores IMAP-servere bruger individuelt krypterede SQLite-databaser til hver af dine postkasser.

SQLite er en ekstremt populær indlejret database – den kører i øjeblikket på din telefon og computer – og bruges af næsten alle større teknologier.

På vores krypterede servere er der f.eks. en SQLite-databasepostkasse til linux@example.com, info@example.com, hello@example.com og så videre – en for hver som en .sqlite database fil. Vi navngiver heller ikke databasefilerne med e-mailadressen – i stedet bruger vi BSON ObjectID og unikke UUID'er, der genereres, som ikke deler, hvem postkassen tilhører, eller hvilken e-mailadresse den er under (f.eks. 353a03f21e534321f5d6e267.sqlite).

Hver af disse databaser er selv krypteret ved hjælp af din adgangskode (som kun du har). sqleet (ChaCha20-Poly1305). Det betyder, at dine postkasser er individuelt krypterede, selvstændige, sandkasse, og bærbar.

Vi har finjusteret SQLite med følgende PRAGMA:

`PRAGMA`	Formål
`cipher=chacha20`	ChaCha20-Poly1305 SQLite databasekryptering. Reference `better-sqlite3-multiple-ciphers` under Projekter for mere indsigt.
`key="****************"`	Dette er din dekrypterede adgangskode i hukommelsen, som sendes gennem din e-mailklients IMAP-forbindelse til vores server. Nye databaseinstanser oprettes og lukkes for hver læse- og skrivesession (for at sikre sandboxing og isolation).
`journal_model=WAL`	Write-ahead-log ("WAL") som øger ydeevnen og giver samtidig læseadgang.
`busy_timeout=5000`	Forhindrer skrivelåsfejl mens andre skriverier finder sted.
`synchronous=NORMAL`	Øger holdbarheden af transaktioner uden risiko for datakorruption.
`foreign_keys=ON`	Håndhæver, at fremmednøglereferencer (f.eks. en relation fra en tabel til en anden) håndhæves. Som standard er dette ikke slået til i SQLite, men for validering og dataintegritet bør det være aktiveret.
`encoding='UTF-8'`	Standardkodning at bruge til at sikre udviklerens fornuft.

Alle andre standardindstillinger er fra SQLite som angivet fra officiel PRAGMA dokumentation.

Samtidighed

tldr; Vi bruger WebSocket til samtidige læsninger og skrivninger til dine krypterede SQLite-postkasser.

Læser

Din e-mail-klient på din telefon kan løse problemet imap.forwardemail.net til en af vores Digital Ocean IP-adresser – og din desktop-klient kan løse en separat IP fra en anden udbyder i det hele taget.

Uanset hvilken IMAP-server din e-mail-klient forbinder til, ønsker vi, at forbindelsen læser fra din database i realtid med 100 % nøjagtighed. Dette gøres gennem WebSockets.

Skriver

At skrive til din database er lidt anderledes – da SQLite er en indlejret database, og din postkasse som standard lever i en enkelt fil.

Vi havde undersøgt muligheder som f.eks litestream, rqlite, og dqlite nedenfor – men ingen af disse opfyldte vores krav.

For at udføre skrivninger med write-ahead-logging ("WAL") aktiveret – vi skal sikre, at kun én server ("Primær") er ansvarlig for at gøre det. WAL fremskynder samtidighed drastisk og tillader én forfatter og flere læsere.

Den primære kører på dataserverne med de monterede volumener, der indeholder de krypterede postkasser. Fra et distributionssynspunkt kunne du overveje alle de individuelle IMAP-servere bagved imap.forwardemail.net at være sekundære servere ("Sekundære").

Vi opnår tovejskommunikation med WebSockets:

Primære servere bruger en instans af ws's WebSocketServer server.
Sekundære servere bruger en instans af ws's WebSocket klient, der er pakket med websocket-som-lovet og gentilslutning-websocket. Disse to indpakninger sikrer, at WebSocket genopretter forbindelse og kan sende og modtage data til specifikke databaseskrivninger.

Sikkerhedskopier

tldr; Sikkerhedskopier af dine krypterede postkasser laves dagligt. Du kan også øjeblikkeligt anmode om en ny backup eller downloade den seneste backup når som helst fra Min konto Domæner Aliaser.

Til sikkerhedskopier kører vi simpelthen SQLite VACUUM INTO kommando hver dag under IMAP-kommandobehandling, som udnytter din krypterede adgangskode fra en IMAP-forbindelse i hukommelsen. Sikkerhedskopier gemmes, hvis der ikke findes nogen eksisterende sikkerhedskopi, eller hvis SHA-256 hash er ændret på filen sammenlignet med den seneste sikkerhedskopi.

Bemærk, at vi bruger VACUUM INTO kommando i modsætning til den indbyggede backup kommando, fordi hvis en side ændres i løbet af en backup kommandooperation, så skal den starte forfra. Det VACUUM INTO kommandoen tager et øjebliksbillede. Se disse kommentarer vedr GitHub og Hacker nyheder for mere indsigt.

Derudover bruger vi VACUUM INTO i modsætning til backup, fordi backup kommando ville lade databasen være ukrypteret i en kort periode indtil rekey påkaldes (se denne GitHub kommentar for indsigt).

Den sekundære vil instruere Primary om WebSocket forbindelse til at udføre sikkerhedskopieringen – og den primære vil derefter modtage kommandoen til at gøre det og vil efterfølgende:

Opret forbindelse til din krypterede postkasse.
Anskaf en skrivelås.
Kør et WAL-kontrolpunkt via wal_checkpoint(PASSIVE).
Kør VACUUM INTO SQLite kommando.
Sørg for, at den kopierede fil kan åbnes med den krypterede adgangskode (safeguard/dummyproofing).
Upload det til Cloudflare R2 til opbevaring (eller din egen udbyder, hvis det er angivet).

Husk, at dine postkasser er krypteret – og mens vi har IP-begrænsninger og andre autentificeringsforanstaltninger på plads for WebSocket-kommunikation – i tilfælde af en dårlig aktør, kan du være sikker på, at medmindre WebSocket-nyttelasten har din IMAP-adgangskode, kan den ikke åbne din database .

Der gemmes kun én sikkerhedskopi pr. postkasse på nuværende tidspunkt, men i fremtiden kan vi tilbyde punkt-i-tids-gendannelse ("PITR").

Søg

Vores IMAP-servere understøtter SEARCH kommando med komplekse forespørgsler, regulære udtryk og mere.

Hurtig søgeydelse er takket være FTS5 og sqlite-regex.

Vi gemmer Date værdier i SQLite-postkasserne som ISO 8601 strenge via Date.prototype.toISOString (med UTC-tidszone, så lighedssammenligninger fungerer korrekt).

Indekser gemmes også for alle egenskaber, der er i søgeforespørgsler.

Projekter

Her er en tabel, der viser projekter, vi bruger i vores kildekode og udviklingsproces (sorteret alfabetisk):

Projekt	Formål
Ansible	DevOps automatiseringsplatform til at vedligeholde, skalere og administrere hele vores flåde af servere med lethed.
Bree	Jobplanlægning til Node.js og JavaScript med cron, datoer, ms, senere og menneskevenlig support.
Kabine	Udviklervenligt JavaScript og Node.js logbibliotek med sikkerhed og privatliv i tankerne.
Drenge	Node.js-ramme, som driver hele vores arkitektur og ingeniørdesign med MVC og mere.
MongoDB	NoSQL-databaseløsning, som vi bruger til at gemme alle andre data uden for postkasser (f.eks. din konto, indstillinger, domæner og aliaskonfigurationer).
Mongoose	MongoDB objektdokumentmodellering ("ODM"), som vi bruger på tværs af hele vores stak. Vi skrev specielle hjælpere, der gør det muligt for os at fortsætte med at bruge Mongoose med SQLite 🎉
Node.js	Node.js er open source JavaScript-runtime-miljøet på tværs af platforme, som kører alle vores serverprocesser.
Notat mailer	Node.js-pakke til afsendelse af e-mails, oprettelse af forbindelser og mere. Vi er officiel sponsor for dette projekt.
Redis	In-memory database til cachelagring, publicerings-/abonnementskanaler og DNS over HTTPS-anmodninger.
SQLite3MultipleCiphers	Krypteringsudvidelse til SQLite for at tillade at hele databasefiler krypteres (inklusive skrive-ahead-loggen ("WAL"), journal, rollback, ...).
SQLiteStudio	Visuel SQLite-editor (som du også kan bruge) til at teste, downloade og se udviklingspostkasser.
SQLite	Indlejret databaselag til skalerbar, selvstændig, hurtig og modstandsdygtig IMAP-lagring.
Spam scanner	Node.js anti-spam, e-mail-filtrering og phishing-forebyggelsesværktøj (vores alternativ til Spammorder og rspamd).
Mandarin	DNS over HTTPS-anmodninger med Node.js og caching ved hjælp af Redis – hvilket sikrer global konsistens og meget mere.
Thunderbird	Vores udviklingsteam bruger dette (og anbefaler også dette) som den foretrukne e-mail-klient til brug med Videresend e-mail.
UTM	Vores udviklingsteam bruger denne skabe virtuelle maskiner til iOS og macOS for at teste forskellige e-mail-klienter (parallelt) med vores IMAP- og SMTP-servere.
Ubuntu	Moderne open source Linux-baseret serveroperativsystem, som driver hele vores infrastruktur.
Vildænd	IMAP-serverbibliotek – se dets noter vedr de-duplikering af vedhæftede filer og IMAP protokol understøttelse.
bedre-sqlite3-flere-cifre	Hurtigt og enkelt API-bibliotek til Node.js til at interagere med SQLite3 programmatisk.
e-mail-skabeloner	Udviklervenlig e-mail-ramme til at oprette, se forhåndsvisning og sende tilpassede e-mails (f.eks. kontomeddelelser og mere).
json-sql	SQL-forespørgselsbygger ved hjælp af syntaks i Mongo-stil. Dette sparer vores udviklingsteam tid, da vi kan fortsætte med at skrive i Mongo-stil på tværs af hele stakken med en databaseagnostisk tilgang. Det hjælper også med at undgå SQL-injektionsangreb ved at bruge forespørgselsparametre.
knex-skema-inspektør	SQL-værktøj til at udtrække information om eksisterende databaseskema. Dette giver os mulighed for nemt at validere, at alle indekser, tabeller, kolonner, begrænsninger og mere er gyldige og er `1:1` med hvordan de skal være. Vi skrev endda automatiske hjælpere til at tilføje nye kolonner og indekser, hvis der foretages ændringer i databaseskemaer (også med ekstremt detaljeret fejlvarsling).
knex	SQL-forespørgselsbygger, som vi kun bruger til databasemigreringer og skemavalidering igennem `knex-schema-inspector`.
mandarin	Automatisk i18n sætningsoversættelse med understøttelse af Markdown ved hjælp af Google Cloud Translation API.
mx-connect	Node.js-pakke til at løse og etablere forbindelser med MX-servere og håndtere fejl.
2. kl	Node.js produktionsproces manager med indbygget load balancer (finjusteret for ydeevne).
smtp-server	SMTP-serverbibliotek – vi bruger dette til vores mailudveksling ("MX") og udgående SMTP-servere.
ImapTest	Nyttigt værktøj til at teste IMAP-servere mod benchmarks og RFC-specifikation IMAP-protokolkompatibilitet. Dette projekt blev skabt af Dueslag team (en aktiv open source IMAP- og POP3-server fra juli 2002). Vi testede vores IMAP-server grundigt med dette værktøj.

Du kan finde andre projekter, vi bruger i vores kildekode på GitHub.

Udbydere

Udbyder	Formål
Cloudflare	DNS-udbyder, sundhedstjek, belastningsbalancere og backup-lager ved hjælp af Cloudflare R2.
Digital Ocean	Dedikeret serverhosting, SSD-bloklagring og administrerede databaser.
Vultr	Dedikeret serverhosting og SSD-bloklagring.

Tanker

Principper

Videresend e-mail er designet efter disse principper:

Vær altid udviklervenlig, sikkerheds- og privatlivsfokuseret og gennemsigtig.
overholde MVC, Unix, KISS, DRY, YAGNI, Tolv Faktor, Occams barbermaskine, og dogfooding
Målret mod de skrabet, støvler, og ramen-rentabel Udvikler

Eksperimenter

tldr; I sidste ende er det ikke teknisk muligt at bruge S3-kompatibelt objektlager og/eller virtuelle tabeller af ydeevneårsager og tilbøjelige til fejl på grund af hukommelsesbegrænsninger.

Vi har lavet et par eksperimenter op til vores endelige SQLite-løsning som diskuteret ovenfor.

En af disse var at prøve at bruge rclone og SQLite sammen med et S3-kompatibelt lagerlag.

Det eksperiment førte os til yderligere at forstå og opdage edge cases omkring rclone, SQLite og VFS brug:

Hvis du aktiverer --vfs-cache-mode writes flag med rclone, så vil læsning være OK, men skrivninger bliver cachelagret.
- Hvis du har flere IMAP-servere distribueret globalt, vil cachen være slukket på tværs af dem, medmindre du har en enkelt skribent og flere lyttere (f.eks. en pub/sub-tilgang).
- Dette er utroligt komplekst, og tilføjelse af yderligere kompleksitet som denne vil resultere i flere enkelte fejlpunkter.
- S3-kompatible lagerudbydere understøtter ikke delvise filændringer - hvilket betyder enhver ændring af .sqlite fil vil resultere i en fuldstændig ændring og gen-upload af databasen.
- Andre løsninger som f.eks rsync eksisterer, men de er ikke fokuseret på write-ahead-log ("WAL") support – så vi endte med at gennemgå Litestream. Heldigvis krypterer vores krypteringsbrug allerede WAL filer for os, så vi behøver ikke at stole på Litestream for det. Men vi var endnu ikke sikre på Litestream til produktionsbrug og har et par bemærkninger nedenfor om det.
- Ved at bruge denne mulighed for --vfs-cache-mode writes (det kun måde at bruge SQLite over rclone for writes) vil forsøge at kopiere hele databasen fra bunden i hukommelsen – håndtering af en 10 GB postkasse er OK, men håndtering af flere postkasser med overordentlig høj lagerplads vil få IMAP-serverne til at løbe ind i hukommelsesbegrænsninger og ENOMEM fejl, segmenteringsfejl og datakorruption.
Hvis du forsøger at bruge SQLite Virtuelle borde (fx ved at bruge s3db) for at have data live på et S3-kompatibelt lagerlag, vil du støde på flere problemer:
- Læsning og skrivning vil være ekstremt langsom, da S3 API-endepunkter skal rammes med HTTP GET, PUT, HEAD, og POST metoder.
- Udviklingstest viste, at overskridelse af 500K-1M+ rekorder på fiberinternet stadig er begrænset af gennemstrømningen af skrivning og læsning til S3-kompatible udbydere. For eksempel kørte vores udviklere for loops til at udføre både sekventiel SQL INSERT udsagn og dem, der bulk skrev store mængder data. I begge tilfælde var præstationen svimlende langsom.
- Virtuelle borde kan ikke have indekser, ALTER TABLE udtalelser, og Andet begrænsninger – hvilket fører til forsinkelser på op mod 1-2 minutter eller mere afhængigt af mængden af data.
- Objekter blev gemt ukrypteret, og ingen indbygget krypteringsunderstøttelse er let tilgængelig.
Vi udforskede også at bruge sqlite-s3vfs som er begrebsmæssigt og teknisk ens det forrige punktopstilling (så det har de samme problemer). En mulighed ville være at bruge en brugerdefineret sqlite3 build pakket ind med kryptering som f.eks wxSQLite3 (som vi i øjeblikket bruger i vores løsning ovenfor) gennem redigering af opsætningsfilen.
En anden potentiel tilgang var at bruge multiplex udvidelse, men dette har en begrænsning på 32 GB og ville kræve kompleks bygnings- og udviklingshovedpine.
ALTER TABLE erklæringer er påkrævet (så dette udelukker fuldstændigt at bruge virtuelle tabeller). Vi behøver ALTER TABLE udsagn i orden for vores krog med knex-schema-inspector at fungere korrekt – hvilket sikrer, at data ikke beskadiges, og rækker, der hentes, kan konverteres til gyldige dokumenter i henhold til vores mongoose skemadefinitioner (som inkluderer begrænsning, variabeltype og vilkårlig datavalidering).
Næsten alle de S3-kompatible projekter relateret til SQLite i open source-fællesskabet er i Python (og ikke JavaScript, som vi bruger til 100 % af vores stak).
Kompressionsbiblioteker som f.eks sqlite-zstd (se kommentarer) ser lovende ud, men er muligvis endnu ikke klar til produktionsbrug. I stedet for applikationssidekomprimering på datatyper som f.eks String, Object, Map, Array, Set, og Buffer vil være en renere og lettere tilgang (og er også nemmere at migrere, da vi kunne gemme en Boolean flag eller kolonne – eller endda brug PRAGMA user_version=1 til kompression el user_version=0 for ingen komprimering som databasemetadata).
- Heldigvis har vi allerede de-duplikering af vedhæftede filer implementeret i vores IMAP-serverlager – derfor vil hver meddelelse med den samme vedhæftning ikke beholde en kopi af den vedhæftede fil – i stedet gemmes en enkelt vedhæftet fil for flere meddelelser og tråde i en postkasse (og en udenlandsk) reference bruges efterfølgende).
Projektet Litestream, som er en SQLite replikerings- og backupløsning, er meget lovende, og vi vil højst sandsynligt bruge det i fremtiden.
- Ikke for at miskreditere forfatteren/forfatterne – fordi vi elsker deres arbejde og bidrag til open source i mere end et årti nu – men ud fra den virkelige verden ser det ud til, at der kan være en masse hovedpine og potentielt datatab ved brug.
Backup-gendannelse skal være friktionsfri og triviel. Brug af en løsning som MongoDB med mongodump og mongoexport er ikke kun trættende, men tidskrævende og har konfigurationskompleksitet.
- SQLite-databaser gør det enkelt (det er en enkelt fil).
- Vi ønskede at designe en løsning, hvor brugerne kunne tage deres postkasse og gå når som helst.
  - Simple Node.js-kommandoer til fs.unlink('mailbox.sqlite')) og det slettes permanent fra disklageret.
  - Vi kan på samme måde bruge en S3-kompatibel API med HTTP DELETE for nemt at fjerne snapshots og sikkerhedskopier for brugere.
- SQLite var den enkleste, hurtigste og mest omkostningseffektive løsning.

Mangel på alternativer

Så vidt vi ved, er ingen andre e-mail-tjenester designet på denne måde, og de er heller ikke open source.

Vi tror det kan skyldes til eksisterende e-mail-tjenester, der har ældre teknologi i produktion med spaghetti kode 🍝.

De fleste, hvis ikke alle, eksisterende e-mail-tjenesteudbydere er enten lukkede kilder eller annoncerer som open source, men i virkeligheden er kun deres front-end open source.

Den mest følsomme del af e-mail (den faktiske lagring/IMAP/SMTP-interaktion) er alt gjort på back-end (server), og ikke på front-end (klient).

Prøv Videresend e-mail

Tilmeld dig i dag kl https://forwardemail.net! 🚀

Krypterede SQLite-postkasser til dit privatliv