Beste kvantesikre krypterte e-posttjeneste i 2024

Forord

tldr; Vår e-posttjeneste er 100 % åpen kildekode og personvernfokusert gjennom sikre og krypterte SQLite-postbokser.

Helt til vi lanserte IMAP-støtte, brukte vi MongoDB for våre vedvarende datalagringsbehov.

Denne teknologien er fantastisk, og vi bruker den fortsatt i dag – men for å ha encryption-at-rest med MongoDB må du bruke en leverandør som tilbyr MongoDB Enterprise, som Digital Ocean eller Mongo Atlas – eller betale for en bedriftslisens (og må deretter jobbe med salgsteamets ventetid).

Teamet vårt kl Videresend E-post trengte en utviklervennlig, skalerbar, pålitelig og kryptert lagringsløsning for IMAP-postbokser. Som åpen kildekode-utviklere må du ved å bruke en teknologi betale en lisensavgift for å få funksjonen kryptering i hvile. våre prinsipper – så vi eksperimenterte, undersøkte og utviklet en ny løsning fra bunnen av for å løse disse behovene.

I stedet for å bruke en delt database for å lagre postkassene dine, lagrer og krypterer vi postkassene dine individuelt med passordet ditt (som bare du har). Vår e-posttjeneste er så sikker at hvis du glemmer passordet ditt, så mister du postkassen (og må gjenopprette med offline sikkerhetskopier eller starte på nytt).

Fortsett å lese mens vi tar et dypdykk nedenfor med en sammenligning av e-postleverandører, hvordan tjenesten vår fungerer, teknologistabelen vår, og mer.

Sammenligning av e-posttjenesteleverandører

Vi er den eneste 100 % åpen kildekode og personvernfokuserte e-posttjenesteleverandør som lagrer individuelt krypterte SQLite-postbokser, tilbyr ubegrensede domener, aliaser og brukere, og har utgående SMTP-, IMAP- og POP3-støtte:

I motsetning til andre e-postleverandører, trenger du ikke betale for lagring per domene eller alias med Forward Email. Lagring deles på tvers av hele kontoen din – så hvis du har flere tilpassede domenenavn og flere aliaser på hver, så er vi den perfekte løsningen for deg. Vær oppmerksom på at du fortsatt kan håndheve lagringsgrenser om ønskelig på en per domene- eller aliasbasis.

Les sammenligning av e-posttjenester

Hvordan virker det

Ved å bruke e-postklienten din som Apple Mail, Thunderbird, Gmail eller Outlook – kobler du til vår sikre IMAP servere som bruker ditt brukernavn og passord:
- Brukernavnet ditt er ditt fulle alias med domenet ditt som f.eks hello@example.com.
- Passordet ditt genereres tilfeldig og vises kun til deg i 30 sekunder når du klikker Generer passord fra Min konto domener Aliaser.
Når du er koblet til, vil e-postklienten din sende IMAP-protokollkommandoer til vår IMAP-server for å holde postkassen din synkronisert. Dette inkluderer å skrive og lagre e-postutkast og andre handlinger du kan gjøre (f.eks. merke en e-post som viktig eller flagge en e-post som søppelpost/søppelpost).
E-postutvekslingsservere (ofte kjent som "MX"-servere) mottar ny innkommende e-post og lagrer den i postkassen din. Når dette skjer vil e-postklienten din bli varslet og synkronisere postkassen din. Våre e-postutvekslingsservere kan videresende e-posten din til en eller flere mottakere (inkludert webhooks), lagre e-posten din for deg i din krypterte IMAP-lagring hos oss, eller begge!

Interessert i å lære mer? Lese hvordan sette opp videresending av e-post, hvordan vår postutvekslingstjeneste fungerer, eller se våre guider.
Bak kulissene fungerer vårt sikre e-postlagringsdesign på to måter for å holde postboksene dine kryptert og bare tilgjengelig for deg:
- Når ny e-post mottas for deg fra en avsender, skriver våre e-postutvekslingsservere til en individuell, midlertidig og kryptert postboks for deg.
```
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 kobler til IMAP-serveren vår med e-postklienten din, krypteres passordet ditt i minnet og brukes til å lese og skrive til postboksen din. Din postkasse kan kun leses fra og skrives til med dette passordet. Husk at siden du er den eneste med dette passordet, bare deg kan lese og skrive til postkassen når du har tilgang til den. Neste gang e-postklienten din prøver å spørre etter e-post eller synkroniseres, vil de nye meldingene dine bli overført fra denne midlertidige postkassen og lagret i den faktiske postkassefilen ved hjelp av passordet du har oppgitt. Merk at denne midlertidige postkassen blir tømt og slettet etterpå, slik at bare den passordbeskyttede postkassen din har meldingene.
- Hvis du er koblet til IMAP (f.eks. ved å bruke en e-postklient som Apple Mail eller Thunderbird), trenger vi ikke å skrive til midlertidig disklagring. Ditt krypterte IMAP-passord i minnet blir i stedet hentet og brukt. I sanntid, når en melding prøver å bli levert til deg, sender vi en WebSocket-forespørsel til alle IMAP-servere og spør dem om de har en aktiv sesjon for deg (dette er hente-delen), og vil deretter sende den videre kryptert passord i minnet – så vi trenger ikke å skrive til en midlertidig postkasse, vi kan skrive til den faktiske krypterte postkassen din ved å bruke ditt krypterte passord.
```
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!
```
Sikkerhetskopier av dine krypterte postbokser lages daglig. Du kan også be om en ny sikkerhetskopi når som helst eller laste ned den siste sikkerhetskopien fra Min konto domener Aliaser. Hvis du bestemmer deg for å bytte til en annen e-posttjeneste, kan du enkelt migrere, laste ned, eksportere og tømme postboksene og sikkerhetskopiene dine når som helst.

teknologier

Databaser

Vi utforsket andre mulige databaselagringslag, men ingen tilfredsstilte kravene våre så mye som SQLite gjorde:

Database	Kryptering i hvile	Sandkasse Postkasser	Tillatelse	Brukt overalt
SQLite ⭐	✅ Ja med SQLite3MultipleCiphers	✅	✅ Offentlig domene	✅
MongoDB	❌ "Kun tilgjengelig i MongoDB Enterprise"	❌ Relasjonsdatabase	❌ AGPL og `SSPL-1.0`	❌
rqlite	❌ Bare nettverk	❌ Relasjonsdatabase	✅ `MIT`	❌
dqlite	❌ Utestet og ikke støttet ennå?	❌ Utestet og ikke støttet ennå?	✅ `LGPL-3.0-only`	❌
PostgreSQL	✅ Ja	❌ Relasjonsdatabase	✅ `PostgreSQL` (lik `BSD` eller `MIT`)	❌
MariaDB	✅ Kun for InnoDB	❌ Relasjonsdatabase	✅ `GPLv2` og `BUSL-1.1`	❌
KakerlakkDB	❌ Kun bedriftsfunksjon	❌ Relasjonsdatabase	❌ `BUSL-1.1` og andre	❌

Her er en blogginnlegg som sammenligner flere SQLite-databaselagringsalternativer i tabellen ovenfor.

Sikkerhet

Til enhver tid bruker vi kryptering i hvile (AES-256), kryptering under transport (TLS), DNS over HTTPS ("DoH") ved å bruke 🍊 Mandarin, og sqleet (ChaCha20-Poly1305) kryptering på postkasser. I tillegg bruker vi token-basert tofaktorautentisering (i motsetning til SMS som er mistenkt for mann-i-midten-angrep), roterte SSH-nøkler med rottilgang deaktivert, eksklusiv tilgang til servere gjennom begrensede IP-adresser og mer.

I tilfelle av en onde tjenestepiken angrep eller useriøs ansatt fra en tredjepartsleverandør, postkassen din kan fortsatt bare åpnes med ditt genererte passord. Vær trygg på at vi ikke stoler på noen tredjepartsleverandører andre enn våre SOC Type 2-klageserverleverandører av Cloudflare, Digital Ocean og Vultr.

Målet vårt er å ha så få enkelt punkt med feil som mulig.

Postkasser

tldr; Våre IMAP-servere bruker individuelt krypterte SQLite-databaser for hver av postboksene dine.

SQLite er en ekstremt populær innebygd database – den kjører for øyeblikket på telefonen og datamaskinen din – og brukes av nesten alle viktige teknologier.

For eksempel, på våre krypterte servere er det en SQLite-databasepostboks for linux@example.com, info@example.com, hello@example.com og så videre – en for hver som en .sqlite databasefil. Vi navngir heller ikke databasefilene med e-postadressen – i stedet bruker vi BSON ObjectID og unike UUID-er generert som ikke deler hvem postkassen tilhører eller hvilken e-postadresse den er under (f.eks. 353a03f21e534321f5d6e267.sqlite).

Hver av disse databasene er selv kryptert ved å bruke passordet ditt (som bare du har). sqleet (ChaCha20-Poly1305). Dette betyr at postkassene dine er individuelt kryptert, selvforsynt, sandkasse, og bærbar.

Vi har finjustert SQLite med følgende PRAGMA:

`PRAGMA`	Hensikt
`cipher=chacha20`	ChaCha20-Poly1305 SQLite databasekryptering. Henvisning `better-sqlite3-multiple-ciphers` under Prosjekter for mer innsikt.
`key="****************"`	Dette er ditt dekrypterte passord som kun er i minnet som sendes gjennom e-postklientens IMAP-tilkobling til serveren vår. Nye databaseforekomster opprettes og lukkes for hver lese- og skriveøkt (for å sikre sandboxing og isolasjon).
`journal_model=WAL`	Write-ahead-log ("WAL") som øker ytelsen og gir samtidig lesetilgang.
`busy_timeout=5000`	Forhindrer skrivelåsfeil mens andre skriverier finner sted.
`synchronous=NORMAL`	Øker varigheten av transaksjoner uten risiko for datakorrupsjon.
`foreign_keys=ON`	Håndhever at fremmednøkkelreferanser (f.eks. en relasjon fra en tabell til en annen) håndheves. Som standard er dette ikke slått på i SQLite, men for validering og dataintegritet bør den være aktivert.
`encoding='UTF-8'`	Standardkoding å bruke for å sikre utviklerens fornuft.

Alle andre standarder er fra SQLite som spesifisert fra offisiell PRAGMA-dokumentasjon.

Samtidighet

tldr; Vi bruker rclone og WebSocket for samtidig lesing og skriving til dine krypterte SQLite-postbokser.

Leser

E-postklienten på telefonen din kan løse seg imap.forwardemail.net til en av våre Digital Ocean IP-adresser – og skrivebordsklienten din kan løse en separat IP fra en annen forsørger totalt.

Uansett hvilken IMAP-server e-postklienten din kobler til, vil vi at tilkoblingen skal lese fra databasen din i sanntid med 100 % nøyaktighet:

Dette oppnås ved å bruke rclone med --vfs-cache-mode off (Standaren).
I stedet for å bruke lokal diskbuffer, leses hurtigbufferen direkte fra fjernmonteringen (databasen din) i sanntid.
I tilfelle den lokale filen ikke kan bli funnet, indikerer dette det rclone kunne ikke montere eller har et problem. I dette tilfellet bruker vi en WebSocket fallback for lesninger (som reduserer ytelsen litt, men fortsatt opprettholder integriteten til tjenesten).
Hver av våre servere er konfigurert til å montere med konsistens og varsler oss i sanntid om eventuelle feil.

Skriver

Å skrive til databasen din er litt annerledes - siden SQLite er en innebygd database og postkassen din lever i en enkelt fil som standard.

Vi hadde utforsket alternativer som f.eks litestream, rqlite, og dqlite nedenfor – men ingen av disse tilfredsstilte kravene våre.

For å få til skriving med forutgående logging ("WAL") aktivert – vi må sørge for at bare én server ("Primær") er ansvarlig for å gjøre det. WAL øker drastisk samtidighet og tillater én forfatter og flere lesere.

Primæren kjører på dataserverne med de monterte volumene som inneholder de krypterte postboksene. Fra et distribusjonssynspunkt kan du vurdere alle de individuelle IMAP-serverne bak imap.forwardemail.net å være sekundære servere ("sekundær").

Vi oppnår toveis kommunikasjon med WebSockets:

Primære servere bruker en forekomst av ws's WebSocketServer server.
Sekundære servere bruker en forekomst av ws's WebSocket klient som er pakket med websocket-som-lovet og reconnecting-websocket. Disse to omslagene sørger for at WebSocket kobler til igjen og kan sende og motta data for spesifikke databaseskrivinger.

Sikkerhetskopier

tldr; Sikkerhetskopier av dine krypterte postbokser lages daglig. Du kan også umiddelbart be om en ny sikkerhetskopi eller laste ned den siste sikkerhetskopien når som helst fra Min konto domener Aliaser.

For sikkerhetskopiering kjører vi ganske enkelt SQLite VACUUM INTO kommando hver dag under IMAP-kommandobehandling, som utnytter det krypterte passordet ditt fra en IMAP-tilkobling i minnet. Sikkerhetskopier lagres hvis ingen eksisterende sikkerhetskopi oppdages eller hvis SHA-256 hash har endret seg på filen sammenlignet med den siste sikkerhetskopien.

Merk at vi bruker VACUUM INTO kommando i motsetning til den innebygde backup kommando fordi hvis en side endres i løpet av en backup kommandooperasjon, så må den starte på nytt. De VACUUM INTO kommandoen tar et øyeblikksbilde. Se disse kommentarene på GitHub og Hacker Nyheter for mer innsikt.

I tillegg bruker vi VACUUM INTO i motsetning til backup, fordi det backup kommando ville la databasen være ukryptert i en kort periode til rekey påkalles (se denne GitHub kommentar for innsikt).

Sekundæren vil instruere Primæren over WebSocket tilkobling for å utføre sikkerhetskopien – og primæren vil da motta kommandoen om å gjøre det og vil deretter:

Koble til din krypterte postkasse.
Skaff deg en skrivelås.
Kjør et WAL-sjekkpunkt via wal_checkpoint(PASSIVE).
Kjør VACUUM INTO SQLite kommando.
Sørg for at den kopierte filen kan åpnes med det krypterte passordet (safeguard/dummyproofing).
Last den opp til Cloudflare R2 for lagring (eller din egen leverandør hvis spesifisert).
Komprimer den resulterende sikkerhetskopifilen med gzip.
Last den opp til Cloudflare R2 for lagring (eller din egen leverandør hvis spesifisert).

Husk at postboksene dine er kryptert – og mens vi har IP-restriksjoner og andre autentiseringstiltak på plass for WebSocket-kommunikasjon – i tilfelle en dårlig aktør kan du være trygg på at med mindre WebSocket-nyttelasten har ditt IMAP-passord, kan den ikke åpne databasen din .

Bare én sikkerhetskopi er lagret per postboks for øyeblikket, men i fremtiden kan vi tilby punkt-i-tids-gjenoppretting ("PITR").

Søk

Våre IMAP-servere støtter SEARCH kommando med komplekse spørringer, regulære uttrykk og mer.

Rask søkeytelse er takket være FTS5 og sqlite-regex.

Vi lagrer Date verdier i SQLite-postboksene som ISO 8601 strenger via Date.prototype.toISOString (med UTC-tidssone for at likhetssammenlikninger skal fungere skikkelig).

Indekser lagres også for alle eiendommer som er i søk.

Prosjekter

Her er en tabell som viser prosjekter vi bruker i kildekoden og utviklingsprosessen (sortert alfabetisk):

Prosjekt	Hensikt
Ansible	DevOps automatiseringsplattform for å vedlikeholde, skalere og administrere hele serverflåten vår på en enkel måte.
Bree	Jobbplanlegger for Node.js og JavaScript med cron, datoer, ms, senere og menneskevennlig støtte.
Hytte	Utviklervennlig JavaScript og Node.js loggbibliotek med sikkerhet og personvern i tankene.
La	Node.js-rammeverket som driver hele vår arkitektur og ingeniørdesign med MVC og mer.
MongoDB	NoSQL-databaseløsning som vi bruker for å lagre alle andre data utenfor postbokser (f.eks. din konto, innstillinger, domener og aliaskonfigurasjoner).
Mongoose	MongoDB objektdokumentmodellering ("ODM") som vi bruker på tvers av hele stabelen vår. Vi skrev spesialhjelpere som lar oss bare fortsette å bruke Mongoose med SQLite 🎉
node.js	Node.js er åpen kildekode, kryssplattform JavaScript-runtime-miljøet som kjører alle serverprosessene våre.
Notat mailer	Node.js-pakke for å sende e-poster, opprette tilkoblinger og mer. Vi er offisiell sponsor for dette prosjektet.
Redis	In-memory database for caching, publiserings-/abonnementskanaler og DNS over HTTPS-forespørsler.
SQLite3MultipleCiphers	Krypteringsutvidelse for SQLite for å tillate at hele databasefiler krypteres (inkludert skrive-ahead-loggen ("WAL"), journal, tilbakeføring, ...).
SQLiteStudio	Visual SQLite editor (som du også kan bruke) for å teste, laste ned og se utviklingspostbokser.
SQLite	Innebygd databaselag for skalerbar, selvstendig, rask og spenstig IMAP-lagring.
Spam-skanner	Node.js anti-spam, e-postfiltrering og phishing-forebyggingsverktøy (vårt alternativ til Spammorder og rspamd).
Mandarin	DNS over HTTPS-forespørsler med Node.js og caching ved hjelp av Redis – som sikrer global konsistens og mye mer.
Thunderbird	Utviklingsteamet vårt bruker dette (og anbefaler dette også) som den foretrukne e-postklienten som skal brukes med Videresend e-post.
UTM	Utviklingsteamet vårt bruker dette til å lage virtuelle maskiner for iOS og macOS for å teste forskjellige e-postklienter (parallelt) med våre IMAP- og SMTP-servere.
Ubuntu	Moderne åpen kildekode Linux-basert serveroperativsystem som driver all vår infrastruktur.
Villand	IMAP-serverbibliotek – se notatene om de-duplisering av vedlegg og Støtte for IMAP-protokoll.
bedre-sqlite3-flere siffer	Rask og enkelt API-bibliotek for Node.js for å samhandle med SQLite3 programmatisk.
e-postmaler	Utviklervennlig e-postrammeverk for å lage, forhåndsvise og sende tilpassede e-poster (f.eks. kontovarsler og mer).
json-sql	SQL-spørringsbygger som bruker Mongo-stilsyntaks. Dette sparer utviklingsteamet vårt for tid siden vi kan fortsette å skrive i Mongo-stil over hele stabelen med en databaseagnostisk tilnærming. Det hjelper også å unngå SQL-injeksjonsangrep ved å bruke spørringsparametere.
knex-skjema-inspektør	SQL-verktøy for å trekke ut informasjon om eksisterende databaseskjema. Dette lar oss enkelt validere at alle indekser, tabeller, kolonner, begrensninger og mer er gyldige og er `1:1` med hvordan de skal være. Vi skrev til og med automatiserte hjelpere for å legge til nye kolonner og indekser hvis det gjøres endringer i databaseskjemaer (med ekstremt detaljert feilvarsling også).
knex	SQL spørringsbygger som vi kun bruker for databasemigrering og skjemavalidering gjennom `knex-schema-inspector`.
mandarin	Automatisk i18n setningsoversettelse med støtte for Markdown-bruk Google Cloud Translation API.
mx-connect	Node.js-pakke for å løse og etablere forbindelser med MX-servere og håndtere feil.
pm2	Node.js produksjonsprosessleder med innebygd lastbalanser (finjustert for ytelse).
smtp-server	SMTP-serverbibliotek – vi bruker dette til vår e-postutveksling ("MX") og utgående SMTP-servere.
ImapTest	Nyttig verktøy for å teste IMAP-servere mot benchmarks og RFC-spesifikasjon IMAP-protokollkompatibilitet. Dette prosjektet ble opprettet av Dueslag team (en aktiv åpen kildekode IMAP- og POP3-server fra juli 2002). Vi testet IMAP-serveren vår grundig med dette verktøyet.

Du kan finne andre prosjekter vi bruker i kildekoden vår på GitHub.

Leverandører

Forsørger	Hensikt
Cloudflare	DNS-leverandør, helsesjekker, lastbalansere og sikkerhetskopiering ved hjelp av Cloudflare R2.
Digitalt hav	Dedikert serverhosting, SSD-blokklagring og administrerte databaser.
Vultr	Dedikert serverhosting og SSD-blokklagring.

tanker

Prinsipper

Videresend e-post er utformet i henhold til disse prinsippene:

Vær alltid utviklervennlig, sikkerhets- og personvernfokusert, og gjennomsiktig.
overholde MVC, Unix, KISS, DRY, YAGNI, Tolvfaktor, Occams barberhøvel, og dogfooding
Målrett de skrappe, støvlete og ramen-lønnsomt utvikler

Eksperimenter

tldr; Til syvende og sist er det ikke teknisk mulig å bruke S3-kompatibel objektlagring og/eller virtuelle tabeller av ytelsesgrunner og utsatt for feil på grunn av minnebegrensninger.

Vi har gjort noen eksperimenter frem til vår endelige SQLite-løsning som diskutert ovenfor.

En av disse var å prøve å bruke rclone og SQLite sammen med et S3-kompatibelt lagringslag.

Dette eksperimentet førte oss til å forstå og oppdage edge-tilfeller rundt rclone, SQLite og VFS bruk:

Hvis du aktiverer --vfs-cache-mode writes flagg med rclone, så vil lesinger være OK, men skrivinger blir bufret.
- Hvis du har flere IMAP-servere distribuert globalt, vil hurtigbufferen være av på tvers av dem med mindre du har en enkelt skribent og flere lyttere (f.eks. en pub/sub-tilnærming).
- Dette er utrolig komplekst, og å legge til ekstra kompleksitet som dette vil resultere i flere enkeltpunkter for feil.
- S3-kompatible lagringsleverandører støtter ikke delvise filendringer – noe som betyr enhver endring av .sqlite filen vil resultere i en fullstendig endring og ny opplasting av databasen.
- Andre løsninger som rsync eksisterer, men de er ikke fokusert på write-ahead-log ("WAL") støtte – så vi endte opp med å vurdere Litestream. Heldigvis krypterer krypteringsbruken vår allerede WAL filer for oss, så vi trenger ikke stole på Litestream for det. Imidlertid var vi ennå ikke sikre på Litestream for produksjonsbruk, og har noen merknader nedenfor om det.
- Ved å bruke dette alternativet til --vfs-cache-mode writes (de bare måte å bruke SQLite over rclone for writes) vil forsøke å kopiere hele databasen fra bunnen av i minnet – håndtering av én 10 GB postboks er OK, men håndtering av flere postbokser med ekstremt høy lagringsplass vil føre til at IMAP-serverne får minnebegrensninger og ENOMEM feil, segmenteringsfeil og datakorrupsjon.
Hvis du prøver å bruke SQLite Virtuelle bord (f.eks. ved å bruke s3db) for å ha data live på et S3-kompatibelt lagringslag, vil du få flere problemer:
- Lesing og skriving vil være ekstremt sakte ettersom S3 API-endepunkter må treffes med HTTP GET, PUT, HEAD, og POST metoder.
- Utviklingstester viste at overskridelse av 500K-1M+ poster på fiberinternett fortsatt er begrenset av gjennomstrømmingen av skriving og lesing til S3-kompatible leverandører. For eksempel løp utviklerne våre for løkker for å gjøre både sekvensiell SQL INSERT uttalelser og de som bulk skrev store mengder data. I begge tilfeller var ytelsen svimlende treg.
- Virtuelle bord kan ikke ha indekser, ALTER TABLE uttalelser, og annen begrensninger – noe som fører til forsinkelser på opptil 1-2 minutter eller mer avhengig av datamengden.
- Objekter ble lagret ukryptert og ingen innebygd krypteringsstøtte er lett tilgjengelig.
Vi har også utforsket å bruke sqlite-s3vfs som er konseptuelt og teknisk lik det forrige punktpunktet (så det har de samme problemene). En mulighet ville være å bruke en egendefinert sqlite3 bygge innpakket med kryptering som f.eks wxSQLite3 (som vi for øyeblikket bruker i løsningen vår ovenfor) gjennom redigere oppsettfilen.
En annen potensiell tilnærming var å bruke multipleks utvidelse, men dette har en begrensning på 32 GB og vil kreve kompleks bygge- og utviklingshodepine.
ALTER TABLE uttalelser er påkrevd (så dette utelukker fullstendig bruk av virtuelle tabeller). Vi trenger ALTER TABLE uttalelser i orden for vår krok med knex-schema-inspector å fungere ordentlig – noe som sikrer at data ikke blir ødelagt og rader som hentes kan konverteres til gyldige dokumenter i henhold til våre mongoose skjemadefinisjoner (som inkluderer begrensning, variabeltype og vilkårlig datavalidering).
Nesten alle de S3-kompatible prosjektene relatert til SQLite i åpen kildekode-fellesskapet er i Python (og ikke JavaScript som vi bruker for 100 % av stabelen vår).
Kompresjonsbiblioteker som f.eks sqlite-zstd (se kommentarer) ser lovende ut, men er kanskje ikke klar for produksjonsbruk ennå. I stedet for komprimering på applikasjonssiden på datatyper som f.eks String, Object, Map, Array, Set, og Buffer kommer til å være en renere og enklere tilnærming (og er lettere å migrere også, siden vi kunne lagre en Boolean flagg eller kolonne – eller til og med bruk PRAGMA user_version=1 for kompresjon eller user_version=0 for ingen komprimering som databasemetadata).
- Heldigvis har vi allerede implementert deduplisering av vedlegg i IMAP-serverlagringen vår – derfor vil ikke hver melding med samme vedlegg beholde en kopi av vedlegget – i stedet lagres et enkelt vedlegg for flere meldinger og tråder i en postboks (og en utenlandsk) referanse brukes senere).
Prosjektet Litestream, som er en SQLite-replikerings- og backupløsning er svært lovende og vi vil mest sannsynlig bruke det i fremtiden.
- For ikke å diskreditere forfatteren(e) – fordi vi elsker deres arbeid og bidrag til åpen kildekode i godt over et tiår nå – men ut fra bruk i den virkelige verden ser det ut til at det kan være mye hodepine og potensielt tap av data fra bruk.
Sikkerhetskopiering må være friksjonsfri og triviell. Bruke en løsning som MongoDB med mongodump og mongoexport er ikke bare kjedelig, men tidkrevende og har konfigurasjonskompleksitet.
- SQLite-databaser gjør det enkelt (det er en enkelt fil).
- Vi ønsket å designe en løsning der brukerne kunne ta postkassen sin og gå når som helst.
  - Enkle Node.js-kommandoer til fs.unlink('mailbox.sqlite')) og den slettes permanent fra disklagring.
  - Vi kan på samme måte bruke en S3-kompatibel API med HTTP DELETE for enkelt å fjerne øyeblikksbilder og sikkerhetskopier for brukere.
- SQLite var den enkleste, raskeste og mest kostnadseffektive løsningen.

Mangel på alternativer

Så vidt vi vet er ingen andre e-posttjenester utformet på denne måten, og de er heller ikke åpen kildekode.

Vi tror dette kan skyldes til eksisterende e-posttjenester som har eldre teknologi i produksjon med spaghetti kode 🍝.

De fleste om ikke alle eksisterende e-posttjenesteleverandører er enten lukket kildekode eller annonserer som åpen kildekode, men i virkeligheten er bare front-end deres åpen kildekode.

Den mest sensitive delen av e-post (den faktiske lagring/IMAP/SMTP-interaksjonen) alt gjøres på back-end (server), og ikke på front-end (klient).

Prøv Videresend e-post

Meld deg på i dag kl https://forwardemail.net! 🚀

Dypdykk: Hvordan vi bruker kvantesikre krypterte SQLite-postbokser for vår personvernfokuserte og sikre e-posttjeneste