Quantum Resistant Email: Hoe we gecodeerde SQLite-mailboxen gebruiken om uw e-mail veilig te houden

Voorwoord

Totdat we IMAP-ondersteuning lanceerden, gebruikten we MongoDB voor onze permanente gegevensopslagbehoeften.

Deze technologie is verbazingwekkend en we gebruiken hem nog steeds. Om echter encryptie-at-rest met MongoDB te gebruiken, moet u een provider gebruiken die MongoDB Enterprise aanbiedt, zoals Digital Ocean of Mongo Atlas. U kunt ook betalen voor een zakelijke licentie (waardoor u vervolgens te maken krijgt met de latentie van het verkoopteam).

Ons team bij E-mail doorsturen had behoefte aan een ontwikkelaarsvriendelijke, schaalbare, betrouwbare en versleutelde opslagoplossing voor IMAP-mailboxen. Als open-sourceontwikkelaars was het gebruik van een technologie waarvoor je licentiekosten moet betalen om de versleuteling in rust te krijgen, tegen onze principes. Daarom experimenteerden, onderzochten en ontwikkelden we een nieuwe oplossing vanaf nul om aan deze behoeften te voldoen.

In plaats van een gedeelde database te gebruiken om uw mailboxen op te slaan, slaan wij uw mailboxen individueel op en versleutelen we ze met uw wachtwoord (dat alleen u kent). Onze e-mailservice is zo veilig dat als u uw wachtwoord vergeet, u uw mailbox kwijtraakt (en u deze moet herstellen met offline back-ups of opnieuw moet beginnen).

Lees verder, want hieronder gaan we dieper in op vergelijking van e-maildienstverleners, hoe onze service werkt, onze technologie stack en meer.

Vergelijking van e-mailproviders

Wij zijn de enige 100% open-source en privacygerichte e-mailprovider die individueel versleutelde SQLite-mailboxen opslaat, een onbeperkt aantal domeinen, aliassen en gebruikers biedt en ondersteuning biedt voor uitgaande SMTP, IMAP en POP3:

In tegenstelling tot andere e-mailproviders hoeft u met Forward Email niet te betalen voor opslag per domein of alias. De opslag wordt gedeeld over uw gehele account. Dus als u meerdere aangepaste domeinnamen en meerdere aliassen per domein hebt, zijn wij de perfecte oplossing voor u. Houd er rekening mee dat u desgewenst nog steeds opslaglimieten per domein of alias kunt instellen.

Lees de vergelijking van e-mailservices

Hoe werkt het

1. Met behulp van uw e-mailclient zoals Apple Mail, Thunderbird, Gmail of Outlook maakt u verbinding met onze beveiligde IMAP-servers met uw gebruikersnaam en wachtwoord:

• Je gebruikersnaam is je volledige alias bij je domein, bijvoorbeeld hello@example.com.
• Je wachtwoord wordt willekeurig gegenereerd en wordt slechts 30 seconden weergegeven wanneer je op Wachtwoord genereren klikt vanuit Mijn Account Domeinen Aliassen.

2. Zodra de verbinding tot stand is gebracht, stuurt uw e-mailclient IMAP-protocolopdrachten naar onze IMAP-server om uw mailbox gesynchroniseerd te houden. Dit omvat het schrijven en opslaan van concept-e-mails en andere acties die u uitvoert (bijvoorbeeld een e-mail als belangrijk markeren of markeren als spam/ongewenste e-mail).

3. Mail Exchange-servers (algemeen bekend als "MX"-servers) ontvangen nieuwe inkomende e-mail en slaan deze op in uw mailbox. Wanneer dit gebeurt, ontvangt uw e-mailclient een melding en synchroniseert uw mailbox. Onze mail Exchange-servers kunnen uw e-mail doorsturen naar een of meer ontvangers (waaronder webhooks), uw e-mail voor u opslaan in uw versleutelde IMAP-opslag bij ons, of beide!

4. Achter de schermen werkt ons veilige e-mailopslagontwerp op twee manieren om uw mailboxen versleuteld en alleen voor u toegankelijk te houden:

• Wanneer wij nieuwe e-mail van een afzender voor u ontvangen, schrijven onze mailuitwisselingsservers e-mails naar een individuele, tijdelijke en gecodeerde mailbox voor u.

  

• Wanneer u met uw e-mailclient verbinding maakt met onze IMAP-server, wordt uw wachtwoord in het geheugen gecodeerd en gebruikt om uw mailbox te lezen en te schrijven. Uw mailbox kan alleen met dit wachtwoord worden gelezen en geschreven. Houd er rekening mee dat, aangezien u de enige bent met dit wachtwoord, alleen u uw mailbox kunt lezen en schrijven wanneer u deze opent. De volgende keer dat uw e-mailclient probeert te pollen voor e-mail of synchronisaties, worden uw nieuwe berichten vanuit deze tijdelijke mailbox verzonden en opgeslagen in uw eigen mailboxbestand met het opgegeven wachtwoord. Houd er rekening mee dat deze tijdelijke mailbox daarna wordt opgeschoond en verwijderd, zodat alleen uw met een wachtwoord beveiligde mailbox de berichten bevat.

• Als u verbonden bent met IMAP (bijvoorbeeld met een e-mailclient zoals Apple Mail of Thunderbird), hoeven we niet naar tijdelijke schijfruimte te schrijven. Uw in-memory gecodeerde IMAP-wachtwoord wordt in plaats daarvan opgehaald en gebruikt. Wanneer een bericht bij u wordt afgeleverd, sturen we in realtime een WebSocket-verzoek naar alle IMAP-servers met de vraag of ze een actieve sessie voor u hebben (dit is het ophalen). Vervolgens geven we dat gecodeerde in-memory wachtwoord door. We hoeven dus niet naar een tijdelijke mailbox te schrijven, maar kunnen met uw gecodeerde wachtwoord naar uw daadwerkelijke gecodeerde mailbox schrijven.

  

5. Back-ups van uw versleutelde mailboxen worden dagelijks gemaakt. U kunt ook op elk moment een nieuwe back-up aanvragen of de nieuwste back-up downloaden via Mijn Account Domeinen Aliassen. Als u besluit over te stappen naar een andere e-mailservice, kunt u uw mailboxen en back-ups op elk moment eenvoudig migreren, downloaden, exporteren en verwijderen.

Technologieën

Databanken

We hebben andere mogelijke databaseopslaglagen onderzocht, maar geen enkele voldeed zo goed aan onze eisen als SQLite:

Databank	Encryptie-in-rust	Sandboxed Postvakken	Licentie	Used Everywhere
SQLite :ster:	✅ Ja met SQLite3MultipleCiphers	:wit_vinkje:	✅ Publiek domein	:wit_vinkje:
MongoDB	❌ "Available in MongoDB Enterprise only"	❌ Relationele database	❌ AGPL en SSPL-1.0	:X:
rqlite	❌ Network only	❌ Relationele database	:wit_vinkje: CELCODE_0	:X:
dqlite	❌ Untested and not yet supported?	❌ Untested and not yet supported?	:wit_vinkje: CELCODE_0	:X:
PostgreSQL	:wit_vinkje: Yes	❌ Relationele database	✅ PostgreSQL (vergelijkbaar met BSD of MIT)	:X:
MariaDB	:wit_vinkje: For InnoDB only	❌ Relationele database	✅ GPLv2 en BUSL-1.1	:X:
CockroachDB	❌ Enterprise-only feature	❌ Relationele database	❌ BUSL-1.1 en anderen	:X:

Hier is een blogpost waarin verschillende SQLite-databaseopslagopties worden vergeleken in de bovenstaande tabel.

Beveiliging

We gebruiken te allen tijde encryptie-in-rust (AES-256), encryptie-in-transit (TLS), DNS over HTTPS ("DoH") met 🍊 Mandarijn en sqleet (ChaCha20-Poly1305) encryptie voor mailboxen. Daarnaast gebruiken we token-gebaseerde tweefactorauthenticatie (in tegenstelling tot sms, dat kwetsbaar is voor man-in-the-middle-aanvallen), geroteerde SSH-sleutels met root-toegang uitgeschakeld, exclusieve toegang tot servers via beperkte IP-adressen, en meer.

In het geval van een aanval van een kwaadaardige meid of malafide medewerker van een externe leverancier, kan uw mailbox nog steeds alleen worden geopend met uw gegenereerde wachtwoord. Wees gerust, we vertrouwen niet op andere externe leveranciers dan onze SOC Type 2-serverproviders Cloudflare, DataPacket, Digital Ocean en Vultr.

Ons doel is om zo min mogelijk enkelvoudig punt van falen te hebben.

Postvakken

tldr; Onze IMAP-servers gebruiken individueel gecodeerde SQLite-databases voor elk van uw mailboxen.

SQLite is een extreem populaire ingesloten database – deze wordt momenteel uitgevoerd op uw telefoon en computer – en wordt gebruikt door bijna alle belangrijke technologieën.

Op onze versleutelde servers is er bijvoorbeeld een SQLite-databasemailbox voor linux@example.com, info@example.com, hello@example.com, enzovoort – één voor elk als een databasebestand .sqlite. We geven de databasebestanden ook geen naam met het e-mailadres – in plaats daarvan gebruiken we een BSON ObjectID en unieke UUID's die niet aangeven van wie de mailbox is of onder welk e-mailadres deze staat (bijvoorbeeld 353a03f21e534321f5d6e267.sqlite).

Elk van deze databases is zelf versleuteld met uw wachtwoord (dat alleen u kent) via sqleet (ChaCha20-Poly1305). Dit betekent dat uw mailboxen individueel versleuteld, autonoom (in de zandbak en draagbaar zijn.

We hebben SQLite verfijnd met de volgende PRAGMA:

PRAGMA	Doel
cipher=chacha20	ChaCha20-Poly1305 SQLite database encryption. Zie better-sqlite3-multiple-ciphers onder Projects voor meer informatie.
key="****************"	Dit is uw gedecodeerde wachtwoord dat alleen in het geheugen staat en via de IMAP-verbinding van uw e-mailclient naar onze server wordt verzonden. Nieuwe database-instanties worden voor elke lees- en schrijfsessie aangemaakt en gesloten (om sandboxing en isolatie te garanderen).
journal_model=WAL	Schrijf-vooruit-logboek ("WAL") which boosts performance and allows concurrent read access.
busy_timeout=5000	Voorkomt schrijfvergrendelingsfouten while other writes are taking place.
synchronous=NORMAL	Verhoogt de duurzaamheid van transacties without data corruption risk.
foreign_keys=ON	Zorgt ervoor dat verwijzingen naar externe sleutels (bijvoorbeeld een relatie van de ene tabel naar de andere) worden afgedwongen. By default this is not turned on in SQLite, maar voor validatie en gegevensintegriteit moet dit worden ingeschakeld.
encoding='UTF-8'	Default encoding om te gebruiken om de geestelijke gezondheid van ontwikkelaars te waarborgen.

Alle andere standaardwaarden komen van SQLite zoals gespecificeerd in officiële PRAGMA-documentatie.

Gelijktijdigheid

tldr; We gebruiken WebSocket voor gelijktijdige lees- en schrijfbewerkingen naar uw gecodeerde SQLite-mailboxen.

Leest

Het is mogelijk dat uw e-mailclient op uw telefoon imap.forwardemail.net omzet in een van onze Digital Ocean IP-adressen. Het is ook mogelijk dat uw desktopclient een geheel ander IP-adres omzet in een ander aanbieder.

Ongeacht met welke IMAP-server uw e-mailclient verbinding maakt, willen we dat de verbinding in realtime en met 100% nauwkeurigheid uit uw database wordt gelezen. Dit gebeurt via WebSockets.

Schrijft

Schrijven naar uw database verloopt iets anders, omdat SQLite een ingebedde database is en uw mailbox standaard in één bestand staat.

We hebben opties zoals litestream, rqlite en dqlite hieronder onderzocht, maar geen van deze voldeed aan onze vereisten.

Om schrijfbewerkingen uit te voeren met write-ahead-logging ("WAL") ingeschakeld, moeten we ervoor zorgen dat slechts één server ("Primair") hiervoor verantwoordelijk is. WAL versnelt de gelijktijdigheid aanzienlijk en staat één schrijver en meerdere lezers toe.

De primaire server draait op de dataservers met de gekoppelde volumes die de versleutelde mailboxen bevatten. Vanuit distributieperspectief kunt u alle individuele IMAP-servers achter imap.forwardemail.net als secundaire servers ("Secondary") beschouwen.

We realiseren tweerichtingscommunicatie met WebSockets:

• Primaire servers gebruiken een instance van de WebSocketServer-server van ws.
• Secundaire servers gebruiken een instance van de WebSocket-client van ws, die is ingepakt met websocket-zoals-beloofd en opnieuw verbinden-websocket. Deze twee wrappers zorgen ervoor dat de WebSocket opnieuw verbinding maakt en gegevens kan verzenden en ontvangen voor specifieke databaseschrijfbewerkingen.

Back-ups

tldr; Er worden dagelijks back-ups gemaakt van uw versleutelde mailboxen. U kunt ook direct een nieuwe back-up aanvragen of de nieuwste back-up downloaden via Mijn Account Domeinen Aliassen.

Voor back-ups voeren we dagelijks de SQLite-opdracht VACUUM INTO uit tijdens de verwerking van IMAP-opdrachten. Hierbij wordt uw gecodeerde wachtwoord van een IMAP-verbinding in het geheugen gebruikt. Back-ups worden opgeslagen als er geen bestaande back-up wordt gedetecteerd of als de hash SHA-256 in het bestand is gewijzigd ten opzichte van de meest recente back-up.

Merk op dat we de opdracht VACUUM INTO gebruiken in plaats van de ingebouwde opdracht backup, omdat een pagina die tijdens een backup-opdracht wordt gewijzigd, opnieuw moet worden gestart. De opdracht VACUUM INTO maakt een momentopname. Zie deze opmerkingen over GitHub en Hacker Nieuws voor meer informatie.

Bovendien gebruiken we VACUUM INTO in plaats van backup, omdat de opdracht backup de database voor een korte periode onversleuteld zou laten, totdat rekey wordt aangeroepen (zie deze GitHub opmerking voor meer informatie).

De secundaire server zal de primaire server via de WebSocket-verbinding instrueren om de back-up uit te voeren. De primaire server zal vervolgens de opdracht ontvangen om dit te doen en zal vervolgens:

1. Maak verbinding met je versleutelde mailbox.
2. Zorg voor een schrijfbeveiliging.
3. Voer een WAL-controlepunt uit via wal_checkpoint(PASSIVE).
4. Voer de SQLite-opdracht VACUUM INTO uit.
5. Zorg ervoor dat het gekopieerde bestand kan worden geopend met het versleutelde wachtwoord (safeguard/dummyproofing).
6. Upload het naar Cloudflare R2 voor opslag (of je eigen provider indien opgegeven).

Houd er rekening mee dat uw mailboxen versleuteld zijn. Hoewel we IP-beperkingen en andere authenticatiemaatregelen hanteren voor WebSocket-communicatie, kunt u er in het geval van een kwaadwillende partij gerust op zijn dat de WebSocket-payload uw IMAP-wachtwoord niet kan openen.

Op dit moment wordt er slechts één back-up per mailbox opgeslagen, maar in de toekomst bieden we mogelijk point-in-time-herstel ("PITR") aan.

Zoeken

Onze IMAP-servers ondersteunen de opdracht SEARCH met complexe query's, reguliere expressies en meer.

Snelle zoekprestaties zijn te danken aan FTS5 en sqlite-regex.

We slaan Date-waarden op in de SQLite-mailboxen als ISO 8601-strings via Date.prototype.toISOString (met UTC-tijdzone zodat gelijkheidsvergelijkingen correct functioneren).

Er worden ook indexen opgeslagen voor alle objecten die in zoekopdrachten voorkomen.

Projecten

Hieronder vindt u een tabel met een overzicht van de projecten die we gebruiken in onze broncode en ons ontwikkelingsproces (in alfabetische volgorde):

Project	Doel
Ansible	DevOps-automatiseringsplatform voor het eenvoudig onderhouden, schalen en beheren van ons volledige serverpark.
Bree	Taakplanner voor Node.js en JavaScript met cron, dates, ms, later en mensvriendelijke ondersteuning.
Cabin	Ontwikkelaarsvriendelijke JavaScript- en Node.js-logbibliotheek met beveiliging en privacy in gedachten.
Lad	Het Node.js-framework dat onze volledige architectuur en technisch ontwerp aanstuurt met MVC en meer.
MongoDB	NoSQL-databaseoplossing die we gebruiken voor het opslaan van alle overige gegevens buiten postvakken (bijvoorbeeld uw account, instellingen, domeinen en aliasconfiguraties).
Mongoose	MongoDB object document modeling ("ODM"), dat we in onze hele stack gebruiken. We hebben speciale helpers geschreven waarmee we Mongoose met SQLite gewoon kunnen blijven gebruiken 🎉
Node.js	Node.js is de open-source, platformonafhankelijke JavaScript-runtimeomgeving die al onze serverprocessen uitvoert.
Nodemailer	Node.js-pakket voor het verzenden van e-mails, het maken van verbindingen en meer. Wij zijn een officiële sponsor van dit project.
Redis	In-memory database voor caching, publicatie-/abonnementskanalen en DNS via HTTPS-verzoeken.
SQLite3MultipleCiphers	Encryptie-uitbreiding voor SQLite waarmee volledige databasebestanden kunnen worden gecodeerd (inclusief de write-ahead-log ("WAL"), journaal, rollback, …).
SQLiteStudio	Visuele SQLite-editor (die u ook kunt gebruiken) om ontwikkelingsmailboxen te testen, downloaden en bekijken.
SQLite	Ingebouwde databaselaag voor schaalbare, zelfstandige, snelle en veerkrachtige IMAP-opslag.
Spam Scanner	Node.js anti-spam, e-mailfilter en phishingpreventietool (ons alternatief voor Spam Assassin en rspamd).
Tangerine	DNS over HTTPS-verzoeken met Node.js en caching met Redis – wat wereldwijde consistentie garandeert en nog veel meer.
Thunderbird	Ons ontwikkelteam gebruikt dit (en raadt dit ook aan) als de voorkeurs-e-mailclient voor gebruik met Forward Email.
UTM	Ons ontwikkelteam gebruikt deze virtuele machines voor iOS en macOS om verschillende e-mailclients (parallel) te testen met onze IMAP- en SMTP-servers.
Ubuntu	Modern open-source Linux-gebaseerd serverbesturingssysteem dat onze gehele infrastructuur aandrijft.
WildDuck	IMAP-serverbibliotheek – zie de opmerkingen over attachment de-duplication en IMAP protocol support.
better-sqlite3-multiple-ciphers	Snelle en eenvoudige API-bibliotheek voor Node.js om programmatisch te communiceren met SQLite3.
email-templates	Ontwikkelaarsvriendelijk e-mailframework waarmee u aangepaste e-mails kunt maken, bekijken en versturen (bijvoorbeeld accountmeldingen en meer).
json-sql-enhanced	SQL-querybuilder met Mongo-stijl syntaxis. Dit bespaart ons ontwikkelteam tijd, omdat we in Mongo-stijl kunnen blijven schrijven over de gehele stack met een database-agnostische aanpak. Het helpt ook om SQL-injectieaanvallen te voorkomen door queryparameters te gebruiken.
knex-schema-inspector	SQL-hulpprogramma om informatie over bestaande databaseschema's te extraheren. Dit stelt ons in staat om eenvoudig te valideren dat alle indices, tabellen, kolommen, beperkingen en meer geldig zijn en de juiste 1:1 hebben. We hebben zelfs geautomatiseerde hulpmiddelen geschreven om nieuwe kolommen en indexen toe te voegen als er wijzigingen in databaseschema's worden aangebracht (met daarnaast zeer gedetailleerde foutmeldingen).
knex	SQL query builder die we alleen gebruiken voor databasemigraties en schemavalidatie via knex-schema-inspector.
mandarin	Automatische vertaling van i18n-zinnen met ondersteuning voor Markdown met behulp van Google Cloud Translation API.
mx-connect	Node.js-pakket voor het oplossen en tot stand brengen van verbindingen met MX-servers en het verwerken van fouten.
pm2	Node.js-productieprocesmanager met ingebouwde load balancer (fine-tuned voor prestaties).
smtp-server	SMTP-serverbibliotheek – deze gebruiken we voor onze e-mailuitwisseling ("MX") en uitgaande SMTP-servers.
ImapTest	Handige tool voor het testen van IMAP-servers aan de hand van benchmarks en de compatibiliteit van het IMAP-protocol met de RFC-specificatie. Dit project is ontwikkeld door het Dovecot team (een actieve open-source IMAP- en POP3-server sinds juli 2002). We hebben onze IMAP-server uitgebreid getest met deze tool.

Andere projecten die wij gebruiken, vindt u in onze broncode op GitHub.

Aanbieders

Aanbieder	Doel
Cloudflare	DNS-provider, gezondheidscontroles, load balancers en back-upopslag met behulp van Cloudflare R2.
Digital Ocean	Dedicated serverhosting en beheerde databases.
Vultr	Hosting van speciale servers.
DataPacket	Hosting van speciale servers.

Gedachten

Principes

Forward Email is ontworpen volgens de volgende principes:

1. Wees altijd ontwikkelaarsvriendelijk, gericht op beveiliging en privacy, en transparant.
2. Houd je aan de richtlijnen van MVC, Unix, KISS, DRY, YAGNI, Twaalf Factor, Het scheermes van Ockham en dogfooding.
3. Richt je op de scrappy, bootstrapped en ramen-winstgevend ontwikkelaar.

Experimenten

tldr; Uiteindelijk zijn S3-compatibele object storage en/of virtuele tabellen technisch niet haalbaar vanwege de prestaties en zijn ze foutgevoelig vanwege geheugenbeperkingen.

We hebben een aantal experimenten uitgevoerd ter voorbereiding op onze uiteindelijke SQLite-oplossing, zoals hierboven besproken.

Eén daarvan was om te proberen rclone en SQLite te gebruiken in combinatie met een S3-compatibele opslaglaag.

Dankzij dit experiment kregen we meer inzicht in en ontdekten we grensgevallen rondom het gebruik van rclone, SQLite en VFS:

• Als u de vlag --vfs-cache-mode writes inschakelt met rclone, zijn leesbewerkingen in orde, maar worden schrijfbewerkingen gecached.
• Als u meerdere IMAP-servers wereldwijd hebt, is de cache over deze servers verdeeld, tenzij u één schrijver en meerdere luisteraars hebt (bijvoorbeeld een pub/sub-aanpak).
• Dit is ongelooflijk complex en het toevoegen van extra complexiteit zoals deze zal resulteren in meer single points of failure.
• S3-compatibele opslagproviders ondersteunen geen gedeeltelijke bestandswijzigingen – wat betekent dat elke wijziging van het bestand .sqlite resulteert in een volledige wijziging en herupload van de database.
• Er bestaan andere oplossingen zoals rsync, maar deze zijn niet gericht op ondersteuning voor write-ahead-logs ("WAL") – daarom hebben we uiteindelijk Litestream beoordeeld. Gelukkig versleutelt ons encryptiegebruik de WAL-bestanden al voor ons, dus hoeven we daarvoor niet op Litestream te vertrouwen. We hadden echter nog geen vertrouwen in Litestream voor productiegebruik en hebben hieronder een paar opmerkingen daarover.
• Met deze optie van --vfs-cache-mode writes (de enige manier om SQLite over rclone te gebruiken voor schrijfbewerkingen) wordt geprobeerd de hele database helemaal opnieuw in het geheugen te kopiëren. Het verwerken van één mailbox van 10 GB is prima, maar het verwerken van meerdere mailboxen met extreem veel opslagruimte zal ervoor zorgen dat de IMAP-servers geheugenbeperkingen en ENOMEM-fouten, segmentatiefouten en gegevenscorruptie tegenkomen. * Als u probeert SQLite Virtuele tafels (bijvoorbeeld s3db) te gebruiken om gegevens live op een S3-compatibele opslaglaag te zetten, zult u nog een aantal problemen tegenkomen:
• Lezen en schrijven zal extreem traag zijn, omdat S3 API-eindpunten moeten worden aangestuurd met de HTTP-methoden .sqlite0, .sqlite1, .sqlite2 en .sqlite3.
• Ontwikkelingstests toonden aan dat het overschrijden van 500.000-1.000+ records op glasvezelinternet nog steeds wordt beperkt door de doorvoersnelheid van schrijven en lezen naar S3-compatibele providers. Onze ontwikkelaars hebben bijvoorbeeld .sqlite4-lussen uitgevoerd om zowel sequentiële SQL .sqlite5-statements als statements die grote hoeveelheden gegevens in bulk wegschreven, uit te voeren. In beide gevallen was de prestatie verbluffend traag. * Virtuele tabellen kunnen geen indexen hebben, .sqlite6 statements en .sqlite7 .sqlite8 statements – wat leidt tot vertragingen van meer dan 1-2 minuten of meer, afhankelijk van de hoeveelheid data.
• Objecten werden ongecodeerd opgeslagen en er is geen native encryptie-ondersteuning direct beschikbaar.
• We hebben ook .sqlite9 onderzocht, wat conceptueel en technisch vergelijkbaar is met het vorige punt (dus dezelfde problemen heeft). Een mogelijkheid zou zijn om een aangepaste rsync0 build te gebruiken die is ingepakt met encryptie, zoals rsync1 (die we momenteel gebruiken in onze bovenstaande oplossing) via rsync2.
• Een andere mogelijke aanpak was om rsync3 te gebruiken, maar dit heeft een limiet van 32 GB en zou complexe bouw- en ontwikkelproblemen met zich meebrengen. * rsync4 statements zijn vereist (dus dit sluit het gebruik van virtuele tabellen volledig uit). We hebben rsync5 statements nodig om onze hook met rsync6 correct te laten werken – dit zorgt ervoor dat gegevens niet beschadigd raken en dat opgehaalde rijen kunnen worden omgezet naar geldige documenten volgens onze rsync7 schemadefinities (inclusief beperking, variabeletype en willekeurige gegevensvalidatie).
• Bijna alle S3-compatibele projecten met betrekking tot SQLite in de open-sourcecommunity zijn in Python (en niet in JavaScript, dat we voor 100% van onze stack gebruiken).
• Compressiebibliotheken zoals rsync8 (zie rsync9) zien er veelbelovend uit, maar __PROTECTED_LINK_189__0. In plaats daarvan zal applicatie-side compressie op gegevenstypen zoals __PROTECTED_LINK_189__1, __PROTECTED_LINK_189__2, __PROTECTED_LINK_189__3, __PROTECTED_LINK_189__4, __PROTECTED_LINK_189__5 en __PROTECTED_LINK_189__6 een schonere en eenvoudigere aanpak zijn (en ook gemakkelijker te migreren, omdat we een __PROTECTED_LINK_189__7-vlag of -kolom kunnen opslaan – of zelfs __PROTECTED_LINK_189__8 __PROTECTED_LINK_189__9 voor compressie of __PROTECTED_LINK_190__0 voor geen compressie als databasemetadata kunnen gebruiken).
• Gelukkig hebben we al deduplicatie van bijlagen geïmplementeerd in onze IMAP-serveropslag – daarom wordt er voor elk bericht met dezelfde bijlage geen kopie van de bijlage bewaard – in plaats daarvan wordt er één bijlage opgeslagen voor meerdere berichten en threads in een mailbox (en wordt er vervolgens een externe referentie gebruikt).
• Het project Litestream, een SQLite-replicatie- en back-upoplossing, is veelbelovend en we zullen het waarschijnlijk in de toekomst gebruiken.
• Om de auteur(s) niet in diskrediet te brengen – we zijn al meer dan tien jaar fan van hun werk en bijdragen aan open source – maar uit praktijkgebruik blijkt dat er __PROTECTED_LINK_190__1 en __PROTECTED_LINK_190__2 zijn.
• Back-upherstel moet probleemloos en triviaal zijn. Het gebruik van een oplossing zoals MongoDB met __PROTECTED_LINK_190__3 en __PROTECTED_LINK_190__4 is niet alleen omslachtig, maar ook tijdrovend en complex qua configuratie.
• SQLite-databases maken het eenvoudig (het is één enkel bestand).
• We wilden een oplossing ontwerpen waarmee gebruikers hun mailbox op elk moment kunnen openen en sluiten.
• Eenvoudige Node.js-opdrachten naar __PROTECTED_LINK_190__5 en het wordt permanent van de schijf verwijderd.
• We kunnen op dezelfde manier een S3-compatibele API met HTTP __PROTECTED_LINK_190__6 gebruiken om eenvoudig snapshots en back-ups voor gebruikers te verwijderen.
• SQLite was de eenvoudigste, snelste en meest kosteneffectieve oplossing.

Gebrek aan alternatieven

Voor zover wij weten, zijn er geen andere e-maildiensten die op deze manier zijn ontworpen en die ook niet open source zijn.

Wij denken dat dit komt doordat bestaande e-mailservices nog steeds oude technologie in productie hebben met spaghetticode 🍝.

De meeste, zo niet alle, bestaande e-mail serviceproviders zijn gesloten-source of adverteren als open-source, maar in werkelijkheid is alleen hun front-end open-source.

Het meest gevoelige deel van e-mail (de daadwerkelijke interactie tussen opslag/IMAP/SMTP) vindt allemaal plaats aan de back-end (server), en niet aan de front-end (client).

Probeer Forward Email

Meld je vandaag nog aan op https://forwardemail.net! 🚀