Kvantebestandig e-mail: Sådan bruger vi krypterede SQLite-postkasser til at holde din e-mail sikker

Forord

Indtil vi lancerede IMAP-understøttelse, brugte vi MongoDB til vores behov for vedvarende datalagring.

Denne teknologi er fantastisk, og vi bruger den stadig i dag – men for at have kryptering i hvile 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 arbejde med salgsteamets latenstid).

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

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

Fortsæt med at læse, mens vi dykker ned i detaljer med sammenligning af e-mailudbydere, hvordan vores service fungerer, vores teknologistak og mere nedenfor.

Sammenligning af e-mailudbydere

Vi er den eneste 100 % open source- og privatlivsfokuserede e-mailudbyder, der lagrer individuelt krypterede SQLite-postkasser, tilbyder et ubegrænset antal domæner, aliasser og brugere og understøtter udgående SMTP-, IMAP- og POP3-tjenester:

I modsætning til andre e-mailudbydere behøver du ikke at 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 brugerdefinerede domænenavne og flere aliasser på hvert enkelt, er vi den perfekte løsning for dig. Bemærk, at du stadig kan håndhæve lagergrænser, hvis det ønskes, pr. domæne eller alias.

Læs sammenligning af e-mailtjenester

Hvordan fungerer det

1. Ved at bruge din e-mailklient, f.eks. Apple Mail, Thunderbird, Gmail eller Outlook, opretter du forbindelse til vores sikre IMAP-servere med dit brugernavn og din adgangskode:

• Dit brugernavn er dit fulde alias med dit domæne, f.eks. hello@example.com.
• Din adgangskode genereres tilfældigt og vises kun i 30 sekunder, når du klikker på Generer adgangskode fra Min konto Domæner Aliaser.

2. Når der er oprettet forbindelse, sender din e-mailklient IMAP-protokolkommandoer til vores IMAP-server for at holde din postkasse synkroniseret. Dette inkluderer at skrive og gemme kladdemails og andre handlinger, du måtte foretage dig (f.eks. markere en e-mail som vigtig eller markere en e-mail som spam/uønsket post).

3. Mail Exchange-servere (almindeligvis kendt som "MX"-servere) modtager nye indgående e-mails og gemmer dem i din postkasse. Når dette sker, får din e-mailklient besked og synkroniserer din postkasse. Vores mail Exchange-servere kan videresende din e-mail til en eller flere modtagere (inklusive webhooks), gemme din e-mail for dig i dit krypterede IMAP-lager hos os, eller begge dele!

4. Bag kulisserne fungerer vores sikre e-maillagringsdesign på to måder for at holde dine postkasser krypterede og kun tilgængelige for dig:

• Når vi modtager ny post fra en afsender, skriver vores mailudvekslingsservere til en individuel, midlertidig og krypteret postkasse for dig.

  

• Når du opretter forbindelse til vores IMAP-server med din e-mailklient, 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, er det kun dig, der kan læse og skrive til din postkasse, når du tilgår den. Næste gang din e-mailklient forsøger at forespørge om e-mails eller synkronisere, overføres dine nye beskeder fra denne midlertidige postkasse og gemmes i din faktiske postkassefil ved hjælp af din angivne adgangskode. Bemærk, at denne midlertidige postkasse ryddes og slettes bagefter, så kun din adgangskodebeskyttede postkasse har beskederne.

Hvis du er forbundet til IMAP (f.eks. bruger en e-mailklient som Apple Mail eller Thunderbird), behøver vi ikke at skrive til midlertidig disklagring. Din krypterede IMAP-adgangskode i hukommelsen hentes og bruges i stedet. I realtid, når en besked forsøges 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 hentningsdelen), og derefter videregiver vi den krypterede adgangskode i hukommelsen – så vi ikke behøver at skrive til en midlertidig postkasse, vi kan skrive til din faktiske krypterede postkasse ved hjælp af din krypterede adgangskode.

 ```mermaid
 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. Sikkerhedskopier af dine krypterede postkasser laves dagligt. Du kan også anmode om en ny sikkerhedskopi når som helst eller downloade den seneste sikkerhedskopi fra Min Konto Domæner Aliaser. Hvis du beslutter dig for at skifte til en anden e-mailtjeneste, kan du nemt migrere, downloade, eksportere og rydde dine postkasser og sikkerhedskopier når som helst.

Teknologier

Databaser

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

Database	Kryptering i hvile	Sandboxed Postkasser	Licens	Used Everywhere
SQLite :stjerne:	✅ Ja med SQLite3MultipleCiphers	:hvidt_flueben:	✅ Offentligt domæne	:hvidt_flueben:
MongoDB	❌ "Available in MongoDB Enterprise only"	❌ Relationel database	❌ AGPL og SSPL-1.0	❌
rqlite	❌ Network only	❌ Relationel database	:hvidt_flueben: MIT	❌
dqlite	❌ Untested and not yet supported?	❌ Untested and not yet supported?	:hvidt_flueben: LGPL-3.0-only	❌
PostgreSQL	:hvidt_flueben: Yes	❌ Relationel database	✅ PostgreSQL (ligner BSD eller MIT)	❌
MariaDB	:hvidt_flueben: For InnoDB only	❌ Relationel database	:hvidt_flueben: GPLv2 og BUSL-1.1	❌
CockroachDB	❌ Enterprise-only feature	❌ Relationel database	❌ BUSL-1.1 og andre	❌

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

Sikkerhed

Vi bruger altid kryptering-i-hvile (AES-256), kryptering under transit (TLS), DNS over HTTPS ("DoH") ved hjælp af 🍊 Mandarin og sqleet (ChaCha20-Poly1305) kryptering på postkasser. Derudover bruger vi tokenbaseret tofaktorgodkendelse (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 ond tjenestepigeangreb eller en uautoriseret medarbejder fra en tredjepartsleverandør, kan din postkasse stadig kun åbnes med din genererede adgangskode. Du kan være sikker på, at vi ikke er afhængige af andre tredjepartsleverandører end vores SOC Type 2-klageserverudbydere Cloudflare, DataPacket, Digital Ocean og Vultr.

Vores mål er at have så få enkeltstående fejl som muligt.

Postkasser

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

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

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

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

Vi har finjusteret SQLite med følgende PRAGMA:

PRAGMA	Formål
cipher=chacha20	ChaCha20-Poly1305 SQLite database encryption. Se better-sqlite3-multiple-ciphers under Projects for mere indsigt.
key="****************"	Dette er din dekrypterede adgangskode, der kun er gemt i hukommelsen, og som sendes via 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	Forhåndsskrivningslog ("WAL") which boosts performance and allows concurrent read access.
busy_timeout=5000	Forhindrer skrivelåsfejl while other writes are taking place.
synchronous=NORMAL	Øger holdbarheden af transaktioner without data corruption risk.
foreign_keys=ON	Håndhæver at fremmednøglereferencer (f.eks. en relation fra en tabel til en anden) håndhæves. By default this is not turned on in SQLite, men af hensyn til validering og dataintegritet bør det være aktiveret.
encoding='UTF-8'	Default encoding at bruge for at sikre udviklerens fornuft.

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

Samtidighed

tldr; Vi bruger WebSocket til samtidig læsning og skrivning til dine krypterede SQLite-postkasser.

Læser

Din e-mailklient på din telefon kan muligvis omdanne imap.forwardemail.net til en af vores Digital Ocean IP-adresser – og din desktopklient kan muligvis omdanne en separat IP fra en helt anden udbyder.

Uanset hvilken IMAP-server din e-mailklient opretter forbindelse til, ønsker vi, at forbindelsen læser fra din database i realtid med 100% nøjagtighed. Dette gøres via WebSockets.

Skriver

Det er lidt anderledes at skrive til din database – da SQLite er en integreret database, og din postkasse som standard ligger i en enkelt fil.

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

For at udføre skrivninger med write-ahead-logning ("WAL") aktiveret – skal vi sikre os, 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 server kører på dataserverne med de monterede volumener, der indeholder de krypterede postkasser. Fra et distributionssynspunkt kan man betragte alle de individuelle IMAP-servere bag imap.forwardemail.net som sekundære servere ("Sekundær").

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 ind med websocket-som-lovet og genforbindelse-websocket. Disse to wrappere sikrer, at WebSocket genopretter forbindelsen og kan sende og modtage data til specifikke databaseskrivninger.

Sikkerhedskopier

tldr; Der tages daglige sikkerhedskopier af dine krypterede postkasser. Du kan også anmode om en ny sikkerhedskopi med det samme eller downloade den seneste sikkerhedskopi når som helst fra Min konto Domæner Aliaser.

Til sikkerhedskopier kører vi blot SQLite VACUUM INTO-kommandoen hver dag under IMAP-kommandobehandling, som udnytter din krypterede adgangskode fra en IMAP-forbindelse i hukommelsen. Sikkerhedskopier gemmes, hvis der ikke registreres nogen eksisterende sikkerhedskopi, eller hvis SHA-256-hashen er ændret på filen i forhold til den seneste sikkerhedskopi.

Bemærk, at vi bruger kommandoen VACUUM INTO i modsætning til den indbyggede backup-kommando, fordi hvis en side ændres under en backup-kommandohandling, skal den starte forfra. VACUUM INTO-kommandoen tager et snapshot. Se disse kommentarer om GitHub og Hackernyheder for mere indsigt.

Derudover bruger vi VACUUM INTO i modsætning til backup, fordi kommandoen backup ville efterlade databasen ukrypteret i en kort periode, indtil rekey kaldes (se GitHub kommentar for indsigt).

Sekundæren vil instruere primæren via WebSocket-forbindelsen om at udføre backup'en – og primæren vil derefter modtage kommandoen til at gøre det og vil efterfølgende:

1. Opret forbindelse til din krypterede postkasse.
2. Få en skrivelås.
3. Kør et WAL-checkpoint via wal_checkpoint(PASSIVE).
4. Kør SQLite-kommandoen VACUUM INTO.
5. Sørg for, at den kopierede fil kan åbnes med den krypterede adgangskode (safeguard/dummyproofing).
6. Upload den til Cloudflare R2 til lagring (eller din egen udbyder, hvis angivet).

Husk at dine postkasser er krypterede – og selvom vi har IP-begrænsninger og andre godkendelsesforanstaltninger på plads for WebSocket-kommunikation – kan du i tilfælde af en uønsket aktør 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 gendannelse på et bestemt tidspunkt ("PITR").

Søg

Vores IMAP-servere understøtter SEARCH-kommandoen 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 for at lighedssammenligninger kan fungere korrekt).

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

Projekter

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

Projekt	Formål
Ansible	DevOps-automatiseringsplatform til nem vedligeholdelse, skalering og administration af hele vores serverflåde.
Bree	Jobplanlægger til Node.js og JavaScript med cron, dates, ms, later og brugervenlig support.
Cabin	Udviklervenligt JavaScript- og Node.js-logbibliotek med sikkerhed og privatliv i tankerne.
Lad	Node.js-frameworket, der driver hele vores arkitektur og tekniske design 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 giver os mulighed for blot at fortsætte med at bruge Mongoose med SQLite 🎉
Node.js	Node.js er det open source, cross-platform JavaScript runtime-miljø, der kører alle vores serverprocesser.
Nodemailer	Node.js-pakke til at sende e-mails, oprette forbindelser og mere. Vi er officiel sponsor af dette projekt.
Redis	In-memory-database til caching, publicerings-/abonnementskanaler og DNS over HTTPS-anmodninger.
SQLite3MultipleCiphers	Krypteringsudvidelse til SQLite, der tillader kryptering af hele databasefiler (inklusive write-ahead-loggen ("WAL"), journal, rollback osv.).
SQLiteStudio	Visuel SQLite-editor (som du også kan bruge) til at teste, downloade og se udviklingspostkasser.
SQLite	Integreret databaselag til skalerbar, selvstændig, hurtig og robust IMAP-lagring.
Spam Scanner	Node.js anti-spam, e-mail-filtrering og phishing-forebyggelsesværktøj (vores alternativ til Spam Assassin og rspamd).
Tangerine	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-mailklient til brug med videresendelse af e-mail.
UTM	Vores udviklingsteam bruger denne metode til at oprette virtuelle maskiner til iOS og macOS for at teste forskellige e-mailklienter (parallelt) med vores IMAP- og SMTP-servere.
Ubuntu	Moderne open source Linux-baseret serveroperativsystem, der driver hele vores infrastruktur.
WildDuck	IMAP-serverbibliotek – se dets noter om attachment de-duplication og IMAP protocol support.
better-sqlite3-multiple-ciphers	Hurtigt og enkelt API-bibliotek til Node.js, så den kan interagere programmatisk med SQLite3.
email-templates	Udviklervenligt e-mail-framework til at oprette, forhåndsvise og sende brugerdefinerede e-mails (f.eks. kontonotifikationer og mere).
json-sql-enhanced	SQL-forespørgselsbygger med Mongo-stil syntaks. 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-schema-inspector	SQL-værktøj til at udtrække information om eksisterende databaseskemaer. Dette giver os mulighed for nemt at validere, at alle indekser, tabeller, kolonner, begrænsninger og mere er gyldige og er 1:1, som de skal være. Vi har endda skrevet automatiserede hjælpere til at tilføje nye kolonner og indekser, hvis der foretages ændringer i databaseskemaer (med ekstremt detaljerede fejlalarmer også).
knex	SQL-forespørgselsbygger, som vi kun bruger til databasemigreringer og skemavalidering via knex-schema-inspector.
mandarin	Automatisk i18n oversættelse af sætninger med understøttelse af Markdown ved hjælp af Google Cloud Translation API.
mx-connect	Node.js-pakken til at løse og etablere forbindelser med MX-servere og håndtere fejl.
pm2	Node.js produktionsproceshåndtering med indbygget load balancer (fine-tuned for ydeevne).
smtp-server	SMTP-serverbibliotek – vi bruger dette til vores mailudveksling ("MX") og udgående SMTP-servere.
ImapTest	Nyttigt værktøj til test af IMAP-servere mod benchmarks og RFC-specifikationer for IMAP-protokolkompatibilitet. Dette projekt blev oprettet af Dovecot-teamet (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, load balancers og backup-lager ved hjælp af Cloudflare R2.
Digital Ocean	Dedikeret serverhosting og administrerede databaser.
Vultr	Dedikeret serverhosting.
DataPacket	Dedikeret serverhosting.

Tanker

Principper

Videresendt e-mail er designet efter disse principper:

1. Vær altid udviklervenlig, sikkerheds- og privatlivsfokuseret og transparent.

2. Overhold MVC, Unix, KISS, DRY, YAGNI, Tolv Faktor, Occams barberkniv og dogfooding.

3. Målret dig mod den scrappy, bootstrappede og ramen-profitabel-udvikler.

Eksperimenter

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

Vi har udført et par eksperimenter, der har ført op til vores endelige SQLite-løsning, som beskrevet ovenfor.

En af disse var at forsøge at bruge rclone og SQLite sammen med et S3-kompatibelt lagringslag.

Dette eksperiment førte os til en dybere forståelse og opdagelse af edge cases omkring brugen af rclone, SQLite og VFS:

• Hvis du aktiverer --vfs-cache-mode writes-flaget med rclone, vil læsning være OK, men skrivninger vil blive cachelagret.

• Hvis du har flere IMAP-servere distribueret globalt, vil cachen være slået fra på tværs af dem, medmindre du har en enkelt skriver og flere lyttere (f.eks. en pub/sub-tilgang).

• Dette er utroligt komplekst, og tilføjelse af yderligere kompleksitet som dette vil resultere i flere enkeltstående fejlpunkter.

• S3-kompatible lagerudbydere understøtter ikke delvise filændringer – hvilket betyder, at enhver ændring af .sqlite-filen vil resultere i en komplet ændring og genupload af databasen.

• Andre løsninger som rsync findes, men de fokuserer ikke på write-ahead-log ("WAL")-support – så vi endte med at gennemgå Litestream. Heldigvis krypterer vores krypteringsbrug allerede WAL-filerne for os, så vi behøver ikke at stole på Litestream til det. Vi var dog endnu ikke sikre på Litestream til produktionsbrug og har et par noter nedenfor om det.

• Brug af denne indstilling --vfs-cache-mode writes (den eneste måde at bruge SQLite frem for rclone til skrivninger) vil forsøge at kopiere hele databasen fra bunden til hukommelsen – håndtering af én 10 GB postkasse er OK, men håndtering af flere postkasser med ekstremt høj lagerplads vil medføre, at IMAP-serverne løber ind i hukommelsesbegrænsninger og ENOMEM-fejl, segmenteringsfejl og datakorruption.

• Hvis du forsøger at bruge SQLite Virtuelle borde (f.eks. 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-slutpunkter skal rammes med HTTP .sqlite0, .sqlite1, .sqlite2 og .sqlite3-metoder.

• Udviklingstests viste, at det stadig er begrænset at overstige 500.000-1.000+ poster på fiberinternet af gennemløbshastigheden for skrivning og læsning til S3-kompatible udbydere. For eksempel kørte vores udviklere .sqlite4-løkker for at udføre både sekventielle SQL .sqlite5-sætninger og løkker, der skrev store mængder data i massevis. I begge tilfælde var ydeevnen svimlende langsom.

• Virtuelle tabeller kan ikke have indeks, .sqlite6-sætninger og .sqlite7 .sqlite8 – hvilket fører til forsinkelser på op til 1-2 minutter eller mere afhængigt af datamængden.

• Objekter blev gemt ukrypteret, og der er ingen native krypteringsunderstøttelse tilgængelig.

• Vi undersøgte også brugen af .sqlite9, som konceptuelt og teknisk set ligner det foregående punkt (så det har de samme problemer). En mulighed ville være at bruge et brugerdefineret rsync0-build pakket ind i kryptering, såsom rsync1 (som vi i øjeblikket bruger i vores løsning ovenfor) gennem rsync2.

• En anden potentiel tilgang var at bruge rsync3, men dette har en begrænsning på 32 GB og ville kræve komplekse bygge- og udviklingsproblemer.

• rsync4-sætninger er påkrævet (så dette udelukker fuldstændigt brugen af virtuelle tabeller). Vi har brug for rsync5-sætninger for at vores hook med rsync6 fungerer korrekt – hvilket sikrer, at data ikke beskadiges, og at hentede rækker kan konverteres til gyldige dokumenter i henhold til vores rsync7-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).

• Komprimeringsbiblioteker som rsync8 (se rsync9) ser lovende ud, men __PROTECTED_LINK_189__0. I stedet vil applikationssidekomprimering på datatyper som __PROTECTED_LINK_189__1, __PROTECTED_LINK_189__2, __PROTECTED_LINK_189__3, __PROTECTED_LINK_189__4, __PROTECTED_LINK_189__5 og __PROTECTED_LINK_189__6 være en renere og nemmere tilgang (og er også nemmere at migrere, da vi kunne gemme et __PROTECTED_LINK_189__7-flag eller en kolonne – eller endda bruge __PROTECTED_LINK_189__8 __PROTECTED_LINK_189__9 til komprimering eller __PROTECTED_LINK_190__0 uden komprimering som databasemetadata).

• Heldigvis har vi allerede deduplikering af vedhæftede filer implementeret i vores IMAP-serverlager – derfor vil hver besked med den samme vedhæftede fil ikke gemme en kopi af den vedhæftede fil – i stedet gemmes en enkelt vedhæftet fil til flere beskeder og tråde i en postkasse (og en fremmed 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(e) – fordi vi elsker deres arbejde og bidrag til open source i over et årti nu – men ud fra den praktiske brug ser det ud til, at der findes __PROTECTED_LINK_190__1 og __PROTECTED_LINK_190__2.

• Gendannelse af backup skal være friktionsfri og triviel. Brug af en løsning som MongoDB med __PROTECTED_LINK_190__3 og __PROTECTED_LINK_190__4 er ikke kun kedeligt, men også 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 forlade den når som helst.

• Enkle Node.js-kommandoer til __PROTECTED_LINK_190__5, og den slettes permanent fra disklageret.

• Vi kan på samme måde bruge en S3-kompatibel API med HTTP __PROTECTED_LINK_190__6 til nemt at fjerne snapshots og sikkerhedskopier for brugerne.

• SQLite var den enkleste, hurtigste og mest omkostningseffektive løsning.

Mangel på alternativer

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

Vi tror, at dette kan skyldes, at eksisterende e-mailtjenester har ældre teknologi i produktion med spaghettikode 🍝.

De fleste, hvis ikke alle, eksisterende e-mailudbydere er enten closed source eller reklamerer som open source, men i virkeligheden er det kun deres frontend, der er open source.

Den mest følsomme del af e-mail (den faktiske lagring/IMAP/SMTP-interaktion) foregår udelukkende på backend'en (serveren) og ikke på frontend'en (klienten).

Prøv at videresende e-mail

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