Kvante-resistent e-mail: Hvordan vi bruger krypterede SQLite-mailbokse til at holde din e-mail sikker

Forord

Indtil vi lancerede IMAP-support, 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 enterprise-licens (og efterfølgende skulle håndtere salgsafdelingens ventetid).

Vores team hos Forward Email havde brug for en udviklervenlig, skalerbar, pålidelig og krypteret lagringsløsning til IMAP-mailbokse. Som open-source-udviklere var det imod vores principper at bruge en teknologi, hvor du skal betale en licens for at få kryptering i hvile – så vi eksperimenterede, undersøgte og udviklede en ny løsning fra bunden for at opfylde disse behov.

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

Bliv ved med at læse, mens vi dykker ned i en sammenligning af e-mailudbydere, hvordan vores service fungerer, vores teknologistak og mere.

Sammenligning af e-mailudbydere

Vi er den eneste 100% open-source og privatlivsfokuserede e-mailudbyder, der gemmer individuelt krypterede SQLite-mailbokse, tilbyder ubegrænsede domæner, aliaser og brugere, og har udgående SMTP-, IMAP- og POP3-support:

I modsætning til andre e-mailudbydere behøver du ikke betale for lagerplads pr. domæne eller alias med Forward Email. Lagerplads deles på tværs af hele din konto – så hvis du har flere tilpassede domænenavne og flere aliaser på hver, er vi den perfekte løsning for dig. Bemærk, at du stadig kan håndhæve lagerbegrænsninger, hvis ønsket, pr. domæne eller alias.

Læs Sammenligning af E-mailudbydere

Hvordan fungerer det

1. Ved at bruge din e-mailklient såsom Apple Mail, Thunderbird, Gmail eller Outlook – forbinder du til vores sikre IMAP servere med dit brugernavn og kodeord:

   • Dit brugernavn er dit fulde alias med dit domæne, såsom hello@example.com.
   • Dit kodeord genereres tilfældigt og vises kun for dig i 30 sekunder, når du klikker på Generer Kodeord fra Min Konto Domæner Aliaser.

2. Når du er forbundet, vil din email-klient sende IMAP protokolkommandoer til vores IMAP-server for at holde din postkasse synkroniseret. Dette inkluderer at skrive og gemme kladde-mails og andre handlinger, du måtte udføre (f.eks. mærke en email som Vigtig eller flagge en email som Spam/Skraldespand).

3. Mailudvekslingsservere (almindeligvis kendt som "MX" servere) modtager nye indgående emails og gemmer dem i din postkasse. Når dette sker, bliver din email-klient underrettet og synkroniserer din postkasse. Vores mailudvekslingsservere kan videresende din email til en eller flere modtagere (inklusive webhooks), gemme din email for dig i din krypterede IMAP-lagerplads hos os, eller begge dele!

   Tip

   Interesseret i at lære mere? Læs hvordan du opsætter email videresendelse, hvordan vores mailudvekslingstjeneste fungerer, eller se vores guides.

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

   • Når ny mail modtages til dig fra en afsender, skriver vores mailudvekslingsservere til en individuel, midlertidig og krypteret postkasse til dig.

     

   • Når du forbinder til vores IMAP-server med din email-klient, bliver din adgangskode derefter krypteret i hukommelsen og brugt 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, kan kun du læse og skrive til din postkasse, når du tilgår den. Næste gang din email-klient forsøger at hente mail eller synkronisere, vil dine nye beskeder blive overført fra denne midlertidige postkasse og gemt i din faktiske postkassefil ved brug af din angivne adgangskode. Bemærk, at denne midlertidige postkasse bliver ryddet og slettet bagefter, så kun din adgangskodebeskyttede postkasse har beskederne.

   • Hvis du er forbundet til IMAP (f.eks. ved brug af en email-klient som Apple Mail eller Thunderbird), behøver vi ikke skrive til midlertidig disklager. Din krypterede IMAP-adgangskode i hukommelsen hentes i stedet og bruges. I realtid, når en besked forsøger at blive leveret til dig, sender vi en WebSocket-forespørgsel til alle IMAP-servere og spørger, om de har en aktiv session for dig (dette er hentningen), og derefter vil vi efterfølgende videregive den krypterede adgangskode i hukommelsen – så vi behøver ikke skrive til en midlertidig postkasse, vi kan skrive til din faktiske krypterede postkasse ved brug af din krypterede adgangskode.

     

5. Backups 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 Aliasser. Hvis du beslutter dig for at skifte til en anden email-tjeneste, kan du nemt migrere, downloade, eksportere og slette dine postkasser og backups når som helst.

Teknologier

Databaser

Vi undersøgte andre mulige database-lagerlag, men ingen opfyldte vores krav så godt som SQLite gjorde:

Database	Kryptering i hvile	Sandboxed Postkasser	Licens	Brugt Overalt
SQLite ⭐	✅ Ja med SQLite3MultipleCiphers	✅	✅ Public Domain	✅
MongoDB	❌ "Tilgængelig kun i MongoDB Enterprise"	❌ Relationsdatabase	❌ AGPL og SSPL-1.0	❌
rqlite	❌ Kun netværk	❌ Relationsdatabase	✅ MIT	❌
dqlite	❌ Uafprøvet og endnu ikke understøttet?	❌ Uafprøvet og endnu ikke understøttet?	✅ LGPL-3.0-only	❌
PostgreSQL	✅ Ja	❌ Relationsdatabase	✅ PostgreSQL (ligner BSD eller MIT)	❌
MariaDB	✅ Kun for InnoDB	❌ Relationsdatabase	✅ GPLv2 og BUSL-1.1	❌
CockroachDB	❌ Kun Enterprise-funktion	❌ Relationsdatabase	❌ BUSL-1.1 og andre	❌

Her er et blogindlæg, der sammenligner flere SQLite database lagringsmuligheder i tabellen ovenfor.

Sikkerhed

Vi bruger til enhver tid kryptering i hvile (AES-256), kryptering under overførsel (TLS), DNS over HTTPS ("DoH") ved hjælp af 🍊 Tangerine, og sqleet (ChaCha20-Poly1305) kryptering på postkasser. Derudover bruger vi token-baseret to-faktor autentificering (i modsætning til SMS, som er modtagelig for man-in-the-middle-angreb), roterede SSH-nøgler med root-adgang deaktiveret, eksklusiv adgang til servere gennem begrænsede IP-adresser og mere. I tilfælde af et evil maid attack eller en rogue medarbejder fra en tredjepartsleverandør, kan din postkasse stadig kun åbnes med din genererede adgangskode. Vær sikker på, at vi ikke er afhængige af andre tredjepartsleverandører end vores SOC Type 2-kompatible serverudbydere Cloudflare, DataPacket, Digital Ocean, GitHub og Vultr.

Vores mål er at have så få single point of failures som muligt.

Postkasser

tldr; Vores IMAP-servere bruger individuelt krypterede SQLite-databaser for 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.

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

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

Vi har finjusteret SQLite med følgende PRAGMA:

PRAGMA	Formål
cipher=chacha20	ChaCha20-Poly1305 SQLite databasekryptering. Se better-sqlite3-multiple-ciphers under Projects for mere indsigt.
key="****************"	Dette er din dekrypterede adgangskode, som kun findes i hukommelsen, og 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 tillader samtidig læseadgang.
busy_timeout=5000	Forhindrer skrive-låsefejl mens andre skriver.
synchronous=NORMAL	Øger holdbarheden af transaktioner uden risiko for datakorruption.
foreign_keys=ON	Sikrer, at fremmednøgler (f.eks. en relation fra en tabel til en anden) håndhæves. Som standard er dette ikke aktiveret i SQLite, men for validering og dataintegritet bør det være slået til.
encoding='UTF-8'	Standardkodning der bruges for at sikre udviklerens overblik.

Alle andre standardindstillinger er fra SQLite som specificeret i den officielle PRAGMA dokumentation.

Samtidighed

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

Læsninger

Din email-klient på din telefon kan løse 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 helt.

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

Skrivninger

At skrive til din database er lidt anderledes – da SQLite er en indlejret 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-logging ("WAL") aktiveret – skal vi sikre, at kun én server ("Primary") er ansvarlig for dette. WAL øger drastisk samtidighed og tillader én skriver og flere læsere.

Primary kører på dataserverne med de monterede volumener, der indeholder de krypterede postkasser. Fra et distributionssynspunkt kan du betragte alle de individuelle IMAP-servere bag imap.forwardemail.net som sekundære servere ("Secondary").

Vi opnår tovejskommunikation med WebSockets:

• Primary-servere bruger en instans af ws's WebSocketServer server.
• Secondary-servere bruger en instans af ws's WebSocket klient, som er pakket ind med websocket-as-promised og reconnecting-websocket. Disse to wrappers sikrer, at WebSocket genopretter forbindelsen og kan sende og modtage data til specifikke database-skrivninger.

Backups

tldr; Backups 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 Aliasser.

For backups kører vi simpelthen SQLite-kommandoen VACUUM INTO hver dag under IMAP-kommando-behandling, som udnytter din krypterede adgangskode fra en in-memory IMAP-forbindelse. Backups gemmes, hvis der ikke findes en eksisterende backup, eller hvis SHA-256 hash'en har ændret sig på filen sammenlignet med den seneste backup.

Bemærk, at vi bruger VACUUM INTO-kommandoen i stedet for den indbyggede backup-kommando, fordi hvis en side ændres under en backup-kommando, skal den starte forfra. VACUUM INTO-kommandoen tager et snapshot. Se disse kommentarer på GitHub og Hacker News for mere indsigt.

Derudover bruger vi VACUUM INTO i stedet for backup, fordi backup-kommandoen ville efterlade databasen ukrypteret i en kort periode, indtil rekey bliver kaldt (se denne GitHub kommentar for indsigt).

Secondary vil instruere Primary over WebSocket-forbindelsen til at udføre backup – og Primary vil derefter modtage kommandoen og efterfølgende:

1. Forbinde til din krypterede postkasse.
2. Erhverve en skrive-lås.
3. Køre et WAL checkpoint via wal_checkpoint(PASSIVE).
4. Køre SQLite-kommandoen VACUUM INTO.
5. Sikre, at den kopierede fil kan åbnes med den krypterede adgangskode (sikkerhed/dummyproofing).
6. Uploade den til Cloudflare R2 til lagring (eller din egen udbyder, hvis specificeret).

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

Der gemmes kun én backup pr. postkasse på nuværende tidspunkt, men i fremtiden kan vi tilbyde point-in-time-gendannelse ("PITR").

Søgning

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

Hurtig søgeydelse skyldes 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 lighedsammenligninger fungerer korrekt).

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

Projekter

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

Projekt	Formål
Ansible	DevOps-automatiseringsplatform til nem vedligeholdelse, skalering og styring af hele vores serverflåde.
Bree	Jobplanlægger til Node.js og JavaScript med cron, datoer, ms, senere og menneskevenlig support.
Cabin	Udviklervenligt JavaScript- og Node.js-logningsbibliotek med fokus på sikkerhed og privatliv.
Lad	Node.js-rammeværk, der 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 alias-konfigurationer).
Mongoose	MongoDB objekt-dokumentmodellering ("ODM"), som vi bruger på tværs af hele vores stack. Vi har skrevet specielle hjælpere, der gør det muligt for os blot at fortsætte med at bruge Mongoose med SQLite 🎉
Node.js	Node.js er det open source, tværplatform JavaScript-runtime-miljø, som 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, publish/subscribe-kanaler og DNS over HTTPS-forespørgsler.
SQLite3MultipleCiphers	Krypteringstilføjelse til SQLite, der tillader hele databasefiler at blive krypteret (inklusive write-ahead-log ("WAL"), journal, rollback, …).
SQLiteStudio	Visuel SQLite-editor (som du også kan bruge) til at teste, downloade og se udviklingspostkasser.
SQLite	Indlejret databasedel til skalerbar, selvstændig, hurtig og robust IMAP-lagring.
Spam Scanner	Node.js anti-spam, e-mailfiltrering og phishing-forebyggelsesværktøj (vores alternativ til Spam Assassin og rspamd).
Tangerine	DNS over HTTPS-forespørgsler med Node.js og caching ved brug af Redis – hvilket sikrer global konsistens og meget mere.
Thunderbird	Vores udviklingsteam bruger dette (og anbefaler det også) som den foretrukne e-mailklient til brug med Forward Email.
UTM	Vores udviklingsteam bruger dette 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, som driver hele vores infrastruktur.
WildDuck	IMAP-serverbibliotek – se dets noter om vedhæftnings-duplikering og IMAP-protokolunderstøttelse.
better-sqlite3-multiple-ciphers	Hurtigt og simpelt API-bibliotek til Node.js for programmatisk interaktion med SQLite3.
email-templates	Udviklervenligt e-mail-rammeværk til at oprette, forhåndsvise og sende tilpassede e-mails (f.eks. kontobeskeder 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 stacken 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 databaseskema. Dette gør det muligt for os 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 har endda skrevet automatiserede hjælpere til at tilføje nye kolonner og indekser, hvis der foretages ændringer i databaseskemaer (med ekstremt detaljerede fejlvarsler også).
knex	SQL-forespørgselsbygger, som vi kun bruger til databasemigrationer og skemavalidering gennem knex-schema-inspector.
mandarin	Automatisk i18n fraseoversættelse med support for Markdown ved brug af Google Cloud Translation API.
mx-connect	Node.js-pakke til at løse og etablere forbindelser med MX-servere og håndtere fejl.
pm2	Node.js produktionsprocesmanager med indbygget load balancer (finjusteret for ydeevne).
smtp-server	SMTP-serverbibliotek – vi bruger dette til vores mailudvekslings- ("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 oprettet af Dovecot-teamet (en aktiv open source IMAP- og POP3-server fra juli 2002). Vi har testet 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, helbredstjek, load balancers og backup-lagring ved brug af Cloudflare R2.
GitHub	Hosting af kildekode, CI/CD og projektstyring.
Digital Ocean	Dedikeret serverhosting og administrerede databaser.
Vultr	Dedikeret serverhosting.
DataPacket	Dedikeret serverhosting.

Tanker

Principper

Forward Email er designet efter disse principper:

1. Vær altid udviklervenlig, sikkerheds- og privatlivsfokuseret samt gennemsigtig.
2. Overhold MVC, Unix, KISS, DRY, YAGNI, Twelve Factor, Occam's razor og dogfooding
3. Målret mod den seje, bootstrappede og ramen-profitable udvikler

Eksperimenter

tldr; I sidste ende er brugen af S3-kompatibel objektlagring og/eller Virtual Tables ikke teknisk gennemførlig af præstationsmæssige årsager og er tilbøjelig til fejl på grund af hukommelsesbegrænsninger.

Vi har lavet nogle få eksperimenter frem til vores endelige SQLite-løsning som diskuteret ovenfor.

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

Dette eksperiment førte os til yderligere forståelse og opdagelse af kanttilfælde omkring rclone, SQLite og VFS brug:

• Hvis du aktiverer --vfs-cache-mode writes flaget med rclone, så vil læsninger være OK, men skrivninger vil blive cachet.
  • Hvis du har flere IMAP-servere distribueret globalt, vil cachen være forskellig 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 denne vil resultere i flere enkeltfejlspunkter.
  • S3-kompatible lagringsudbydere understøtter ikke delvise filændringer – hvilket betyder, at enhver ændring af .sqlite filen vil resultere i en komplet ændring og gen-upload af databasen.
  • Andre løsninger som rsync findes, men de fokuserer ikke på write-ahead-log ("WAL") understøttelse – 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. Dog var vi endnu ikke sikre på Litestream til produktionsbrug og har nogle noter nedenfor om det.
  • Brug af denne mulighed --vfs-cache-mode writes (den eneste måde at bruge SQLite over rclone til skrivninger) 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 ekstremt højt lagerforbrug 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 Virtual Tables (f.eks. ved brug af s3db) for at have data liggende på et S3-kompatibelt lagringslag, vil du støde på flere problemer:
  • Læsninger og skrivninger vil være ekstremt langsomme, da S3 API-endpoints skal rammes med HTTP GET, PUT, HEAD og POST metoder.
  • Udviklingstest viste, at overskridelse af 500K-1M+ poster på fiberinternet stadig er begrænset af gennemstrømningen ved skrivning og læsning til S3-kompatible udbydere. For eksempel kørte vores udviklere for loops til både sekventielle SQL INSERT udsagn og dem, der bulk-skrevet store mængder data. I begge tilfælde var ydelsen overraskende langsom.
  • Virtuelle tabeller kan ikke have indekser, ALTER TABLE udsagn og andre begrænsninger – hvilket fører til forsinkelser på op til 1-2 minutter eller mere afhængigt af datamængden.
  • Objekter blev gemt ukrypteret, og der findes ikke indbygget krypteringsunderstøttelse.
• Vi undersøgte også brugen af sqlite-s3vfs, som konceptuelt og teknisk ligner det foregående punkt (så det har de samme problemer). En mulighed ville være at bruge en tilpasset sqlite3 build pakket med kryptering som wxSQLite3 (som vi i øjeblikket bruger i vores løsning ovenfor) gennem redigering af setup-filen.
• En anden potentiel tilgang var at bruge multiplex extension, men denne har en begrænsning på 32 GB og ville kræve kompleks bygning og udviklingsbesvær.
• ALTER TABLE udsagn er nødvendige (så dette udelukker fuldstændigt brugen af Virtual Tables). Vi har brug for ALTER TABLE udsagn for at vores hook med knex-schema-inspector fungerer korrekt – hvilket sikrer, at data ikke bliver korrupte, og at rækker, der hentes, kan konverteres til gyldige dokumenter i henhold til vores mongoose skemadefinitioner (som inkluderer begrænsninger, variabeltype og vilkårlig datavalidering).
• Næsten alle S3-kompatible projekter relateret til SQLite i open source-fællesskabet er i Python (og ikke JavaScript, som vi bruger til 100% af vores stack).
• Komprimeringsbiblioteker som sqlite-zstd (se kommentarer) ser lovende ud, men er muligvis ikke klar til produktionsbrug endnu. I stedet vil applikationsside-komprimering på datatyper som String, Object, Map, Array, Set og Buffer være en renere og nemmere tilgang (og er også nemmere at migrere, da vi kunne gemme et Boolean flag eller kolonne – eller endda bruge PRAGMA user_version=1 for komprimering eller user_version=0 for ingen komprimering som databasemetadata).
  • Heldigvis har vi allerede implementeret vedhæftnings-duplikering i vores IMAP-serverlagring – derfor vil hver besked med samme vedhæftning ikke beholde en kopi af vedhæftningen – i stedet gemmes en enkelt vedhæftning for flere beskeder og tråde i en postkasse (og en fremmed reference bruges efterfølgende).
• Projektet Litestream, som er en SQLite replikations- og backup-lø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 fra virkelighedens brug ser det ud til, at der kan være mange hovedpiner og potentielt datatab ved brug.
• Backup-gendannelse skal være gnidningsfri og trivial. Brug af en løsning som MongoDB med mongodump og mongoexport er ikke kun besværligt, men tidskrævende og har konfigurationskompleksitet.
  • SQLite databaser gør det simpelt (det er en enkelt fil).
  • Vi ønskede at designe en løsning, hvor brugere kunne tage deres postkasse og forlade når som helst.
    • Enkle Node.js kommandoer til fs.unlink('mailbox.sqlite')) og den er permanent slettet fra disklager.
    • Vi kan tilsvarende bruge en S3-kompatibel API med HTTP DELETE for nemt at fjerne snapshots og backups for brugere.
  • SQLite var den simpleste, hurtigste og mest omkostningseffektive løsning.

Manglende alternativer

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

Vi tror, det kan skyldes, at eksisterende e-mailtjenester har ældre teknologi i produktion med spaghetti-kode 🍝.

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

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

Prøv Forward Email

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