Penjelasan lebih mendalam: Cara kami menggunakan kotak surat SQLite terenkripsi kuantum aman untuk layanan email kami yang berfokus pada privasi dan aman

Tidak seperti layanan email lainnya , kami memastikan bahwa hanya Anda yang memiliki akses ke kotak surat Anda setiap saat.

Forward Email Tim
Ditulis oleh
Forward Email TimVerified
Diterbitkan
4/1/24
Waktunya membaca
Kurang dari 5 menit

Kata pengantar

tldr; Layanan email kami adalah 100% sumber terbuka dan berfokus pada privasi melalui kotak surat SQLite yang aman dan terenkripsi.

Sampai kami meluncurkannya dukungan IMAP, kami menggunakan MongoDB untuk kebutuhan penyimpanan data persisten kami.

Teknologi ini luar biasa dan kami masih menggunakannya sampai sekarang – tetapi untuk memiliki enkripsi yang tidak aktif dengan MongoDB Anda perlu menggunakan penyedia yang menawarkan MongoDB Enterprise, seperti Digital Ocean atau Mongo Atlas – atau membayar lisensi perusahaan (dan selanjutnya harus bekerja dengan latensi tim penjualan).

Tim kami di Teruskan Email membutuhkan solusi penyimpanan yang ramah pengembang, skalabel, andal, dan terenkripsi untuk kotak surat IMAP. Sebagai pengembang sumber terbuka, dalam menggunakan teknologi, Anda perlu membayar biaya lisensi untuk mendapatkan fitur enkripsi saat tidak digunakan. prinsip kami – jadi kami bereksperimen, meneliti, dan mengembangkan solusi baru dari awal untuk memenuhi kebutuhan ini.

Daripada menggunakan database bersama untuk menyimpan kotak surat Anda, kami menyimpan dan mengenkripsi kotak surat Anda satu per satu dengan kata sandi Anda (yang hanya Anda miliki). Layanan email kami sangat aman sehingga jika Anda lupa kata sandi, Anda kehilangan kotak surat Anda (dan perlu memulihkan dengan cadangan offline atau memulai dari awal).

Teruslah membaca selagi kita mendalami lebih dalam di bawah ini dengan a perbandingan penyedia layanan email, bagaimana layanan kami bekerja, tumpukan teknologi kami, dan banyak lagi.

Perbandingan penyedia layanan email

Kami adalah satu-satunya penyedia layanan email sumber terbuka dan berfokus pada privasi yang 100% menyimpan kotak surat SQLite yang dienkripsi secara individual, menawarkan domain, alias, dan pengguna tanpa batas, dan memiliki dukungan SMTP, IMAP, dan POP3 keluar:

Berbeda dengan penyedia email lainnya, Anda tidak perlu membayar penyimpanan per domain atau alias dengan Forward Email. Penyimpanan digunakan bersama di seluruh akun Anda – jadi jika Anda memiliki beberapa nama domain khusus dan beberapa alias di setiap nama domain, maka kami adalah solusi yang tepat untuk Anda. Perhatikan bahwa Anda masih dapat menerapkan batas penyimpanan jika diinginkan berdasarkan domain atau alias.

Baca Perbandingan Layanan Email

bagaimana cara kerjanya

  1. Menggunakan klien email Anda seperti Apple Mail, Thunderbird, Gmail, atau Outlook – Anda terhubung ke keamanan kami IMAP server menggunakan nama pengguna dan kata sandi Anda:

    • Nama pengguna Anda adalah alias lengkap dengan domain Anda seperti hello@example.com.
    • Kata sandi Anda dibuat secara acak dan hanya ditampilkan kepada Anda selama 30 detik saat Anda mengklik Hasilkan Kata Sandi dari Akun saya Domain Alias.

  2. Setelah terhubung, klien email Anda akan mengirim Perintah protokol IMAP ke server IMAP kami agar kotak surat Anda tetap sinkron. Hal ini mencakup menulis dan menyimpan draf email serta tindakan lain yang mungkin Anda lakukan (misalnya memberi label email sebagai Penting atau menandai email sebagai Spam/Junk Mail).

  3. Server pertukaran surat (umumnya dikenal sebagai server "MX") menerima email masuk baru dan menyimpannya ke kotak surat Anda. Ketika ini terjadi, klien email Anda akan diberitahu dan menyinkronkan kotak surat Anda. Server pertukaran surat kami dapat meneruskan email Anda ke satu atau lebih penerima (termasuk webhook), simpan email Anda di penyimpanan IMAP terenkripsi bersama kami, atau keduanya!

    Tertarik untuk mempelajari lebih lanjut? Membaca cara mengatur penerusan email, cara kerja layanan pertukaran surat kami, atau lihat pemandu kami.

  4. Di balik layar, desain penyimpanan email kami yang aman berfungsi dengan dua cara untuk menjaga kotak surat Anda tetap terenkripsi dan hanya dapat diakses oleh Anda:

    • Ketika surat baru diterima untuk Anda dari pengirim, server pertukaran surat kami menulis ke kotak surat individual, sementara, dan terenkripsi untuk Anda.

      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!

    • Saat Anda terhubung ke server IMAP kami dengan klien email Anda, kata sandi Anda kemudian dienkripsi di dalam memori dan digunakan untuk membaca dan menulis ke kotak surat Anda. Kotak surat Anda hanya dapat dibaca dan ditulis dengan kata sandi ini. Ingatlah bahwa karena Anda satu-satunya yang memiliki kata sandi ini, hanya kamu dapat membaca dan menulis ke kotak surat Anda saat Anda mengaksesnya. Saat berikutnya klien email Anda mencoba melakukan polling untuk email atau sinkronisasi, pesan baru Anda akan ditransfer dari kotak surat sementara ini dan disimpan dalam file kotak surat Anda yang sebenarnya menggunakan kata sandi yang Anda berikan. Perhatikan bahwa kotak surat sementara ini akan dibersihkan dan dihapus setelahnya sehingga hanya kotak surat Anda yang dilindungi kata sandi yang memiliki pesan-pesan tersebut.

    • Jika Anda terhubung ke IMAP (misalnya menggunakan klien email seperti Apple Mail atau Thunderbird), maka kita tidak perlu menulis ke penyimpanan disk sementara. Kata sandi IMAP terenkripsi dalam memori Anda malah diambil dan digunakan. Secara real-time, ketika sebuah pesan mencoba dikirimkan kepada Anda, kami mengirimkan permintaan WebSocket ke semua server IMAP menanyakan apakah mereka memiliki sesi aktif untuk Anda (ini adalah bagian pengambilan), dan selanjutnya akan meneruskannya. kata sandi dalam memori terenkripsi – jadi kami tidak perlu menulis ke kotak surat sementara, kami dapat menulis ke kotak surat terenkripsi Anda yang sebenarnya menggunakan kata sandi terenkripsi Anda.

      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. Cadangan kotak surat terenkripsi Anda dibuat setiap hari. Anda juga dapat meminta cadangan baru kapan saja atau mengunduh cadangan terbaru dari Akun saya Domain Alias. Jika Anda memutuskan untuk beralih ke layanan email lain, Anda dapat dengan mudah memigrasikan, mengunduh, mengekspor, dan membersihkan kotak surat serta cadangan Anda kapan saja.

Teknologi

Basis Data

Kami menjelajahi kemungkinan lapisan penyimpanan basis data lainnya, namun tidak ada yang memenuhi persyaratan kami seperti yang dilakukan SQLite:

Basis dataEnkripsi saat istirahatDikotak pasir Kotak suratLisensiDigunakan Di Mana Saja
SQLite ⭐✅ Ya dengan SQLite3MultipleCipher✅✅ Domain Publik✅
MongoDB❌ "Hanya tersedia di MongoDB Enterprise"❌ Basis data relasional❌ AGPL dan SSPL-1.0❌
rqlite❌ Hanya jaringan❌ Basis data relasional✅ MIT❌
dqlite❌ Belum teruji dan belum didukung?❌ Belum teruji dan belum didukung?✅ LGPL-3.0-only❌
PostgreSQL✅ Iya❌ Basis data relasional✅ PostgreSQL (mirip dengan BSD atau MIT)❌
MariaDB✅ Hanya untuk InnoDB❌ Basis data relasional✅ GPLv2 dan BUSL-1.1❌
KecoaDB❌ Fitur khusus perusahaan❌ Basis data relasional❌ BUSL-1.1 dan lain-lain❌

Ini sebuah posting blog yang membandingkan beberapa opsi penyimpanan database SQLite pada tabel di atas.

Keamanan

Setiap saat kami menggunakannya enkripsi saat istirahat (AES-256), enkripsi-dalam-transit (TLS), DNS melalui HTTPS ("DoH") menggunakan 🍊 Jeruk keprok, dan persegi (ChaCha20-Poli1305) enkripsi pada kotak surat. Selain itu kami menggunakan otentikasi dua faktor berbasis token (sebagai lawan dari SMS yang dicurigai serangan man-in-the-middle), kunci SSH yang diputar dengan akses root dinonaktifkan, akses eksklusif ke server melalui alamat IP terbatas, dan banyak lagi.

Dalam hal sebuah serangan pelayan jahat atau karyawan nakal dari vendor pihak ketiga, kotak surat Anda masih hanya dapat dibuka dengan kata sandi yang Anda buat. Yakinlah, kami tidak bergantung pada vendor pihak ketiga mana pun selain penyedia server pengaduan SOC Tipe 2 kami yaitu Cloudflare, Digital Ocean, dan Vultr.

Tujuan kami adalah memiliki sesedikit mungkin satu titik kegagalan mungkin.

Kotak surat

tldr; Server IMAP kami menggunakan database SQLite yang dienkripsi secara individual untuk setiap kotak surat Anda.

SQLite adalah yang sangat populer basis data tertanam – saat ini berjalan di ponsel dan komputer Anda – dan digunakan oleh hampir semua teknologi utama.

Misalnya, di server terenkripsi kami terdapat kotak surat database SQLite linux@example.com, info@example.com, hello@example.com dan seterusnya – satu untuk masing-masing sebagai a .sqlite berkas basis data. Kami juga tidak memberi nama file database dengan alamat email – sebagai gantinya kami menggunakan BSON ObjectID dan UUID unik yang dihasilkan yang tidak membagikan milik siapa kotak surat tersebut atau alamat email mana yang digunakan (mis. 353a03f21e534321f5d6e267.sqlite).

Masing-masing database ini dienkripsi sendiri menggunakan kata sandi Anda (yang hanya Anda miliki) yang menggunakan persegi (ChaCha20-Poli1305). Ini berarti kotak surat Anda dienkripsi secara individual, mandiri, kotak pasir, dan portabel.

Kami telah menyempurnakan SQLite dengan yang berikut ini PRAGMA:

PRAGMATujuan
cipher=chacha20Enkripsi basis data SQLite ChaCha20-Poly1305. Referensi better-sqlite3-multiple-ciphers di bawah Proyek untuk lebih banyak wawasan.
key="****************"Ini adalah kata sandi dalam memori Anda yang telah didekripsi dan diteruskan melalui koneksi IMAP klien email Anda ke server kami. Instance database baru dibuat dan ditutup untuk setiap sesi baca dan tulis (untuk memastikan sandboxing dan isolasi).
journal_model=WALTulis-depan-log ("WAL") yang meningkatkan kinerja dan memungkinkan akses baca secara bersamaan.
busy_timeout=5000Mencegah kesalahan kunci tulis sementara penulisan lainnya sedang berlangsung.
synchronous=NORMALMeningkatkan daya tahan transaksi tanpa risiko korupsi data.
foreign_keys=ONMenegakkan bahwa referensi kunci asing (misalnya relasi dari satu tabel ke tabel lainnya) diterapkan. Secara default ini tidak diaktifkan di SQLite, namun untuk validasi dan integritas data, ini harus diaktifkan.
encoding='UTF-8'Pengkodean bawaan untuk digunakan untuk memastikan kewarasan pengembang.

Semua default lainnya berasal dari SQLite sebagaimana ditentukan dari dokumentasi resmi PRAGMA.

Konkurensi

tldr; Kita gunakan rclone dan WebSocket untuk membaca dan menulis secara bersamaan ke kotak surat SQLite terenkripsi Anda.

Membaca

Klien email di ponsel Anda mungkin teratasi imap.forwardemail.net ke salah satu alamat IP Digital Ocean kami – dan klien desktop Anda dapat menentukan IP terpisah dari IP lain pemberi sama sekali.

Terlepas dari server IMAP mana yang terhubung dengan klien email Anda, kami ingin koneksi tersebut membaca dari database Anda secara real-time dengan akurasi 100%:

  • Hal ini dicapai dengan menggunakan rclone dengan --vfs-cache-mode off (standarnya).

  • Daripada menggunakan cache disk lokal, cache dibaca langsung dari remote mount (database Anda) secara real-time.

  • Jika file lokal tidak dapat ditemukan, ini menunjukkan hal itu rclone gagal dipasang atau mengalami masalah. Dalam hal ini kita menggunakan a WebSocket fallback untuk pembacaan (yang sedikit menurunkan kinerja, namun tetap menjaga integritas layanan).

  • Masing-masing server kami dikonfigurasikan untuk dipasang dengan konsistensi dan memberi tahu kami secara real-time jika ada kesalahan.

Menulis

Menulis ke database Anda sedikit berbeda – karena SQLite adalah database tertanam dan kotak surat Anda berada dalam satu file secara default.

Kami telah mengeksplorasi opsi seperti litestream, rqlite, dan dqlite di bawah ini – namun tidak satupun yang memenuhi persyaratan kami.

Untuk menyelesaikan penulisan dengan write-ahead-logging ("WAL") diaktifkan – kita perlu memastikan bahwa hanya satu server ("Utama") yang bertanggung jawab untuk melakukannya. WAL secara drastis mempercepat konkurensi dan memungkinkan satu penulis dan banyak pembaca.

Primer berjalan di server data dengan volume terpasang yang berisi kotak surat terenkripsi. Dari sudut pandang distribusi, Anda dapat mempertimbangkan semua server IMAP individual di belakangnya imap.forwardemail.net menjadi server sekunder (“Sekunder”).

Kami mencapai komunikasi dua arah dengan soket web:

Cadangan

tldr; Cadangan kotak surat terenkripsi Anda dibuat setiap hari. Anda juga dapat langsung meminta cadangan baru atau mengunduh cadangan terbaru kapan saja dari Akun saya Domain Alias.

Untuk backup, kita cukup menjalankan SQLite VACUUM INTO perintah setiap hari selama pemrosesan perintah IMAP, yang memanfaatkan kata sandi terenkripsi Anda dari koneksi IMAP dalam memori. Cadangan disimpan jika tidak ada cadangan yang terdeteksi atau jika SHA-256 hash pada file telah berubah dibandingkan dengan cadangan terbaru.

Perhatikan bahwa kami menggunakan VACUUM INTO perintah sebagai lawan dari bawaan backup perintah karena jika suatu halaman diubah selama a backup operasi perintah, maka harus dimulai dari awal. Itu VACUUM INTO perintah akan mengambil snapshot. Lihat komentar ini di GitHub dan Berita Peretas untuk lebih banyak wawasan.

Selain itu kami menggunakan VACUUM INTO sebagai lawan backup, karena backup perintah akan membiarkan database tidak terenkripsi untuk waktu yang singkat sampai rekey dipanggil (lihat GitHub ini komentar untuk wawasan).

Sekunder akan menginstruksikan Pratama atas WebSocket koneksi untuk menjalankan pencadangan – dan Primer kemudian akan menerima perintah untuk melakukannya dan selanjutnya akan:

  1. Hubungkan ke kotak surat terenkripsi Anda.
  2. Dapatkan kunci tulis.
  3. Jalankan pos pemeriksaan WAL melalui wal_checkpoint(PASSIVE).
  4. Jalankan VACUUM INTO perintah SQLite.
  5. Pastikan file yang disalin dapat dibuka dengan kata sandi terenkripsi (safeguard/dummyproofing).
  6. Unggah ke Cloudflare R2 untuk penyimpanan (atau penyedia Anda sendiri jika ditentukan).
  7. Kompres file cadangan yang dihasilkan dengan gzip.
  8. Unggah ke Cloudflare R2 untuk penyimpanan (atau penyedia Anda sendiri jika ditentukan).

Ingatlah bahwa kotak surat Anda dienkripsi – dan meskipun kami menerapkan pembatasan IP dan tindakan autentikasi lainnya untuk komunikasi WebSocket – jika ada pelaku jahat, Anda dapat yakin bahwa kecuali muatan WebSocket memiliki kata sandi IMAP Anda, maka ia tidak dapat membuka database Anda .

Hanya satu cadangan yang disimpan per kotak surat saat ini, namun di masa mendatang kami mungkin menawarkan pemulihan point-in-time ("PITR").

Server IMAP kami mendukung SEARCH perintah dengan kueri kompleks, ekspresi reguler, dan banyak lagi.

Performa pencarian yang cepat berkat FTS5 dan sqlite-regex.

Kami menyimpan Date nilai di kotak surat SQLite sebagai ISO 8601 string melalui Date.prototype.toISOString (dengan zona waktu UTC agar perbandingan kesetaraan berfungsi dengan baik).

Indeks juga disimpan untuk semua properti yang ada dalam permintaan pencarian.

Proyek

Berikut tabel yang menguraikan proyek yang kami gunakan dalam kode sumber dan proses pengembangan (diurutkan berdasarkan abjad):

ProyekTujuan
MungkinPlatform otomatisasi DevOps untuk memelihara, menskalakan, dan mengelola seluruh armada server kami dengan mudah.
BreePenjadwal pekerjaan untuk Node.js dan JavaScript dengan cron, tanggal, ms, versi lebih baru, dan dukungan ramah manusia.
KabinPustaka logging JavaScript dan Node.js yang ramah pengembang dengan mempertimbangkan keamanan dan privasi.
MembiarkanKerangka kerja Node.js yang mendukung seluruh arsitektur dan desain teknik kami dengan MVC dan banyak lagi.
MongoDBSolusi database NoSQL yang kami gunakan untuk menyimpan semua data lain di luar kotak surat (misalnya akun Anda, pengaturan, domain, dan konfigurasi alias).
LuwakPemodelan dokumen objek MongoDB ("ODM") yang kami gunakan di seluruh tumpukan kami. Kami menulis pembantu khusus yang memungkinkan kami untuk terus menggunakan Luwak dengan SQLite 🎉
Node.jsNode.js adalah lingkungan runtime JavaScript lintas platform sumber terbuka yang menjalankan semua proses server kami.
Catatan suratPaket Node.js untuk mengirim email, membuat koneksi, dan banyak lagi. Kami adalah sponsor resmi proyek ini.
ulangBasis data dalam memori untuk caching, saluran terbitkan/berlangganan, dan DNS melalui permintaan HTTPS.
SQLite3MultipleCipherEkstensi enkripsi untuk SQLite untuk memungkinkan seluruh file database dienkripsi (termasuk write-ahead-log ("WAL"), jurnal, kembalikan,…).
SQLiteStudioEditor Visual SQLite (yang juga dapat Anda gunakan) untuk menguji, mengunduh, dan melihat kotak surat pengembangan.
SQLiteLapisan database tertanam untuk penyimpanan IMAP yang skalabel, mandiri, cepat, dan tangguh.
Pemindai SpamAnti-spam Node.js, pemfilteran email, dan alat pencegahan phishing (alternatif kami untuk Pembunuh Spam dan rspamd).
Jeruk keprokPermintaan DNS melalui HTTPS dengan Node.js dan caching menggunakan Redis – yang memastikan konsistensi global dan banyak lagi.
PetirTim pengembangan kami menggunakan ini (dan merekomendasikannya juga) sebagai klien email pilihan untuk digunakan dengan Forward Email.
UTMTim pengembangan kami menggunakan mesin virtual buatan ini untuk iOS dan macOS untuk menguji klien email yang berbeda (secara paralel) dengan server IMAP dan SMTP kami.
UbuntuSistem operasi server berbasis Linux sumber terbuka modern yang mendukung semua infrastruktur kami.
Bebek liarPerpustakaan server IMAP – lihat catatannya di de-duplikasi lampiran dan Dukungan protokol IMAP.
lebih baik-sqlite3-multiple-cipherPustaka API yang cepat dan sederhana untuk Node.js untuk berinteraksi dengan SQLite3 secara terprogram.
templat emailKerangka kerja email yang ramah pengembang untuk membuat, melihat pratinjau, dan mengirim email khusus (misalnya pemberitahuan akun dan banyak lagi).
json-sqlPembuat kueri SQL menggunakan sintaksis gaya Mongo. Ini menghemat waktu tim pengembangan kami karena kami dapat terus menulis dalam gaya Mongo di seluruh tumpukan dengan pendekatan database agnostik. Ini juga membantu menghindari serangan injeksi SQL dengan menggunakan parameter kueri.
knex-skema-inspekturUtilitas SQL untuk mengekstrak informasi tentang skema database yang ada. Hal ini memungkinkan kami dengan mudah memvalidasi bahwa semua indeks, tabel, kolom, batasan, dan lainnya valid dan valid 1:1 dengan bagaimana seharusnya. Kami bahkan menulis pembantu otomatis untuk menambahkan kolom dan indeks baru jika ada perubahan pada skema database (dengan peringatan kesalahan yang sangat rinci juga).
knexPembuat kueri SQL yang kami gunakan hanya untuk migrasi database dan validasi skema knex-schema-inspector.
MandarinOtomatis i18n terjemahan frasa dengan dukungan untuk penggunaan penurunan harga API Terjemahan Google Cloud.
mx-koneksiPaket Node.js untuk menyelesaikan dan membuat koneksi dengan server MX dan menangani kesalahan.
sore2Manajer proses produksi Node.js dengan penyeimbang beban bawaan (disetel dengan baik untuk kinerja).
server smtpPustaka server SMTP – kami menggunakan ini untuk pertukaran email ("MX") dan server SMTP keluar.
Tes GambarAlat yang berguna untuk menguji server IMAP terhadap tolok ukur dan kompatibilitas protokol IMAP spesifikasi RFC. Proyek ini dibuat oleh Tempat perlindungan merpati tim (server IMAP dan POP3 sumber terbuka aktif mulai Juli 2002). Kami menguji server IMAP kami secara ekstensif dengan alat ini.

Anda dapat menemukan proyek lain yang kami gunakan kode sumber kami di GitHub.

Penyedia

PemberiTujuan
awan suarPenyedia DNS, pemeriksaan kesehatan, penyeimbang beban, dan penggunaan penyimpanan cadangan Cloudflare R2.
Lautan DigitalHosting server khusus, penyimpanan blok SSD, dan database terkelola.
VultrHosting server khusus dan penyimpanan blok SSD.

Pikiran

Prinsip

Email Teruskan dirancang berdasarkan prinsip-prinsip berikut:

  1. Selalu ramah pengembang, fokus pada keamanan dan privasi, serta transparan.
  2. Melekat MVC, Unix, KISS, DRY, YAGNI, Dua Belas Faktor, pisau cukur Occam, dan makanan anjing
  3. Targetkan mereka yang suka berkelahi, bootstrap, dan menguntungkan ramen pengembang

Eksperimen

tldr; Pada akhirnya menggunakan penyimpanan objek yang kompatibel dengan S3 dan/atau Tabel Virtual secara teknis tidak layak karena alasan kinerja dan rentan terhadap kesalahan karena keterbatasan memori.

Kami telah melakukan beberapa percobaan yang mengarah pada solusi akhir SQLite seperti yang dibahas di atas.

Salah satunya adalah mencoba menggunakan rclone dan SQLite bersama dengan lapisan penyimpanan yang kompatibel dengan S3.

Eksperimen tersebut membawa kami untuk lebih memahami dan menemukan kasus-kasus edge seputar rclone, SQLite, dan VFS penggunaan:

  • Jika Anda mengaktifkan --vfs-cache-mode writes tandai dengan rclone, maka pembacaan akan baik-baik saja, namun penulisan akan di-cache.
    • Jika Anda memiliki beberapa server IMAP yang didistribusikan secara global, maka cache akan dinonaktifkan di seluruh server tersebut kecuali Anda memiliki satu penulis dan beberapa pendengar (misalnya pendekatan pub/sub).
    • Ini sangat rumit dan menambahkan kerumitan tambahan seperti ini akan menghasilkan lebih banyak titik kegagalan.
    • Penyedia penyimpanan yang kompatibel dengan S3 tidak mendukung perubahan sebagian file – yang berarti perubahan apa pun pada file .sqlite file akan menghasilkan perubahan total dan pengunggahan ulang database.
    • Solusi lain seperti rsync ada, tetapi mereka tidak fokus pada write-ahead-log ("WAL") dukungan – jadi kami akhirnya meninjau Litestream. Untungnya penggunaan enkripsi kami sudah mengenkripsinya WAL file untuk kami, jadi kami tidak perlu bergantung pada Litestream untuk itu. Namun kami belum yakin dengan Litestream untuk penggunaan produksi dan memiliki beberapa catatan di bawah ini.
    • Menggunakan opsi ini --vfs-cache-mode writes (itu hanya cara menggunakan SQLite rclone untuk penulisan) akan mencoba menyalin seluruh database dari awal ke dalam memori – menangani satu kotak surat 10 GB boleh saja, namun menangani beberapa kotak surat dengan penyimpanan yang sangat tinggi akan menyebabkan server IMAP mengalami keterbatasan memori dan ENOMEM kesalahan, kesalahan segmentasi, dan kerusakan data.
  • Jika Anda mencoba menggunakan SQLite Tabel Virtual (misalnya menggunakan s3db) agar data tetap aktif di lapisan penyimpanan yang kompatibel dengan S3, Anda akan mengalami beberapa masalah lagi:
    • Membaca dan menulis akan sangat lambat karena titik akhir S3 API perlu menggunakan HTTP GET, PUT, HEAD, dan POST metode.
    • Uji pengembangan menunjukkan bahwa melebihi 500 ribu-1 juta+ catatan pada internet fiber masih dibatasi oleh throughput penulisan dan pembacaan pada penyedia yang kompatibel dengan S3. Misalnya, pengembang kami menjalankan for loop untuk melakukan kedua SQL berurutan INSERT pernyataan dan pernyataan yang menulis data dalam jumlah besar secara massal. Dalam kedua kasus tersebut, kinerjanya sangat lambat.
    • Tabel virtual tidak dapat memiliki indeks, ALTER TABLE pernyataan, dan lainnya keterbatasan – yang menyebabkan penundaan hingga 1-2 menit atau lebih tergantung pada jumlah data.
    • Objek disimpan tidak terenkripsi dan tidak ada dukungan enkripsi asli yang tersedia.
  • Kami juga mengeksplorasi menggunakan sqlite-s3vfs yang secara konseptual dan teknis mirip dengan poin-poin sebelumnya (sehingga mempunyai permasalahan yang sama). Kemungkinannya adalah menggunakan kebiasaan sqlite3 build dibungkus dengan enkripsi seperti wxSQLite3 (yang saat ini kami gunakan dalam solusi kami di atas) melalui mengedit file pengaturan.
  • Pendekatan potensial lainnya adalah dengan menggunakan ekstensi multipleks, namun ini memiliki batasan sebesar 32 GB dan memerlukan kerumitan pembangunan dan pengembangan yang rumit.
  • ALTER TABLE pernyataan diperlukan (jadi ini sepenuhnya mengesampingkan penggunaan Tabel Virtual). Kita butuh ALTER TABLE pernyataan agar kita dapat terhubung dengan knex-schema-inspector agar berfungsi dengan baik – yang memastikan bahwa data tidak rusak dan baris yang diambil dapat dikonversi menjadi dokumen yang valid menurut kami mongoose definisi skema (yang mencakup batasan, tipe variabel, dan validasi data arbitrer).
  • Hampir semua proyek kompatibel S3 yang terkait dengan SQLite di komunitas sumber terbuka menggunakan Python (dan bukan JavaScript yang kami gunakan untuk 100% tumpukan kami).
  • Perpustakaan kompresi seperti sqlite-zstd (melihat komentar) terlihat menjanjikan, tapi mungkin belum siap untuk penggunaan produksi. Sebaliknya kompresi sisi aplikasi pada tipe data seperti String, Object, Map, Array, Set, dan Buffer akan menjadi pendekatan yang lebih bersih dan mudah (dan juga lebih mudah untuk dimigrasikan, karena kita dapat menyimpan a Boolean bendera atau kolom – atau bahkan digunakan PRAGMA user_version=1 untuk kompresi atau user_version=0 tanpa kompresi sebagai metadata database).
    • Untungnya kami sudah menerapkan penghapusan duplikasi lampiran di penyimpanan server IMAP kami – oleh karena itu setiap pesan dengan lampiran yang sama tidak akan menyimpan salinan lampiran – sebagai gantinya, satu lampiran disimpan untuk beberapa pesan dan rangkaian pesan di kotak surat (dan lampiran asing). referensi selanjutnya digunakan).
  • Proyek Litestream, yang merupakan solusi replikasi dan pencadangan SQLite, sangat menjanjikan dan kemungkinan besar kami akan menggunakannya di masa mendatang.
  • Pemulihan cadangan harus dilakukan tanpa hambatan dan sepele. Menggunakan solusi seperti MongoDB dengan mongodump dan mongoexport tidak hanya membosankan, tetapi juga memakan waktu dan memiliki kompleksitas konfigurasi.
    • Database SQLite membuatnya sederhana (ini adalah satu file).
    • Kami ingin merancang solusi di mana pengguna dapat mengambil kotak surat mereka dan keluar kapan saja.
      • Perintah Node.js sederhana untuk fs.unlink('mailbox.sqlite')) dan itu terhapus secara permanen dari penyimpanan disk.
      • Kita juga dapat menggunakan API yang kompatibel dengan S3 dengan HTTP DELETE untuk dengan mudah menghapus snapshot dan cadangan bagi pengguna.
    • SQLite adalah solusi paling sederhana, tercepat, dan paling hemat biaya.

Kurangnya alternatif

Sepengetahuan kami, tidak ada layanan email lain yang dirancang seperti ini dan juga tidak bersumber terbuka.

Kami pikir ini mungkin disebabkan ke layanan email yang sudah ada yang memiliki teknologi lama dalam produksinya kode spageti 🍝.

Sebagian besar, jika tidak semua, penyedia layanan email yang ada adalah sumber tertutup atau beriklan sebagai sumber terbuka, namun kenyataannya hanya front-end mereka yang bersifat open-source.

Bagian paling sensitif dari email (interaksi penyimpanan/IMAP/SMTP sebenarnya) semuanya dilakukan di back-end (server), dan bukan di front-end (klien).

Cobalah Teruskan Email

Daftar hari ini di https://forwardemail.net! 🚀