Kotak surat SQLite terenkripsi untuk privasi Anda
Tidak seperti layanan email lainnya , kami memastikan bahwa hanya Anda yang memiliki akses ke kotak surat Anda setiap saat.
- halaman pencarian
- Daftar Isi
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
-
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.
- Nama pengguna Anda adalah alias lengkap dengan domain Anda seperti
-
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).
-
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.
-
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!
-
-
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 data | Enkripsi saat istirahat | Dikotak pasir Kotak surat | Lisensi | Digunakan 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:
PRAGMA | Tujuan |
---|---|
cipher=chacha20 | Enkripsi 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=WAL | Tulis-depan-log ("WAL") yang meningkatkan kinerja dan memungkinkan akses baca secara bersamaan. |
busy_timeout=5000 | Mencegah kesalahan kunci tulis sementara penulisan lainnya sedang berlangsung. |
synchronous=NORMAL | Meningkatkan daya tahan transaksi tanpa risiko korupsi data. |
foreign_keys=ON | Menegakkan 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
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%. Ini dilakukan melalui WebSockets.
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:
- Server utama menggunakan contoh adalah'S
WebSocketServer
server. - Server sekunder menggunakan contoh adalah'S
WebSocket
klien yang dibungkus dengan websocket-seperti yang dijanjikan dan menghubungkan kembali-websocket. Kedua pembungkus ini memastikan bahwaWebSocket
menyambungkan kembali dan dapat mengirim dan menerima data untuk penulisan database tertentu.
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:
- Hubungkan ke kotak surat terenkripsi Anda.
- Dapatkan kunci tulis.
- Jalankan pos pemeriksaan WAL melalui
wal_checkpoint(PASSIVE)
. - Jalankan
VACUUM INTO
perintah SQLite. - Pastikan file yang disalin dapat dibuka dengan kata sandi terenkripsi (safeguard/dummyproofing).
- 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").
Mencari
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):
Proyek | Tujuan |
---|---|
Mungkin | Platform otomatisasi DevOps untuk memelihara, menskalakan, dan mengelola seluruh armada server kami dengan mudah. |
Bree | Penjadwal pekerjaan untuk Node.js dan JavaScript dengan cron, tanggal, ms, versi lebih baru, dan dukungan ramah manusia. |
Kabin | Pustaka logging JavaScript dan Node.js yang ramah pengembang dengan mempertimbangkan keamanan dan privasi. |
Membiarkan | Kerangka kerja Node.js yang mendukung seluruh arsitektur dan desain teknik kami dengan MVC dan banyak lagi. |
MongoDB | Solusi database NoSQL yang kami gunakan untuk menyimpan semua data lain di luar kotak surat (misalnya akun Anda, pengaturan, domain, dan konfigurasi alias). |
Luwak | Pemodelan 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.js | Node.js adalah lingkungan runtime JavaScript lintas platform sumber terbuka yang menjalankan semua proses server kami. |
Nodemailer | Paket Node.js untuk mengirim email, membuat koneksi, dan banyak lagi. Kami adalah sponsor resmi proyek ini. |
ulang | Basis data dalam memori untuk caching, saluran terbitkan/berlangganan, dan DNS melalui permintaan HTTPS. |
SQLite3MultipleCipher | Ekstensi enkripsi untuk SQLite untuk memungkinkan seluruh file database dienkripsi (termasuk write-ahead-log ("WAL"), jurnal, kembalikan,…). |
SQLiteStudio | Editor Visual SQLite (yang juga dapat Anda gunakan) untuk menguji, mengunduh, dan melihat kotak surat pengembangan. |
SQLite | Lapisan database tertanam untuk penyimpanan IMAP yang skalabel, mandiri, cepat, dan tangguh. |
Pemindai Spam | Anti-spam Node.js, pemfilteran email, dan alat pencegahan phishing (alternatif kami untuk Pembunuh Spam dan rsspamd). |
Jeruk keprok | Permintaan DNS melalui HTTPS dengan Node.js dan caching menggunakan Redis – yang memastikan konsistensi global dan banyak lagi. |
Petir | Tim pengembangan kami menggunakan ini (dan merekomendasikannya juga) sebagai klien email pilihan untuk digunakan dengan Forward Email. |
UTM | Tim 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. |
Ubuntu | Sistem operasi server berbasis Linux sumber terbuka modern yang mendukung semua infrastruktur kami. |
Bebek liar | Perpustakaan server IMAP – lihat catatannya di de-duplikasi lampiran dan Dukungan protokol IMAP. |
lebih baik-sqlite3-multiple-cipher | Pustaka API yang cepat dan sederhana untuk Node.js untuk berinteraksi dengan SQLite3 secara terprogram. |
templat email | Kerangka kerja email yang ramah pengembang untuk membuat, melihat pratinjau, dan mengirim email khusus (misalnya pemberitahuan akun dan banyak lagi). |
json-sql | Pembuat 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-inspektur | Utilitas 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). |
knex | Pembuat kueri SQL yang kami gunakan hanya untuk migrasi database dan validasi skema knex-schema-inspector . |
Mandarin | Otomatis i18n terjemahan frasa dengan dukungan untuk penggunaan penurunan harga API Terjemahan Google Cloud. |
mx-koneksi | Paket Node.js untuk menyelesaikan dan membuat koneksi dengan server MX dan menangani kesalahan. |
sore2 | Manajer proses produksi Node.js dengan penyeimbang beban bawaan (disetel dengan baik untuk kinerja). |
server smtp | Pustaka server SMTP – kami menggunakan ini untuk pertukaran email ("MX") dan server SMTP keluar. |
Tes Gambar | Alat 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
Pemberi | Tujuan |
---|---|
awan suar | Penyedia DNS, pemeriksaan kesehatan, penyeimbang beban, dan penggunaan penyimpanan cadangan Cloudflare R2. |
Lautan Digital | Hosting server khusus, penyimpanan blok SSD, dan database terkelola. |
Vultr | Hosting server khusus dan penyimpanan blok SSD. |
Pikiran
Prinsip
Email Teruskan dirancang berdasarkan prinsip-prinsip berikut:
- Selalu ramah pengembang, fokus pada keamanan dan privasi, serta transparan.
- Melekat MVC, Unix, KISS, DRY, YAGNI, Dua Belas Faktor, pisau cukur Occam, dan makanan anjing
- 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 SQLiterclone
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 danENOMEM
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
, danPOST
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 berurutanINSERT
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.
- Membaca dan menulis akan sangat lambat karena titik akhir S3 API perlu menggunakan HTTP
- 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 butuhALTER TABLE
pernyataan agar kita dapat terhubung denganknex-schema-inspector
agar berfungsi dengan baik – yang memastikan bahwa data tidak rusak dan baris yang diambil dapat dikonversi menjadi dokumen yang valid menurut kamimongoose
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
, danBuffer
akan menjadi pendekatan yang lebih bersih dan mudah (dan juga lebih mudah untuk dimigrasikan, karena kita dapat menyimpan aBoolean
bendera atau kolom – atau bahkan digunakanPRAGMA
user_version=1
untuk kompresi atauuser_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.
- Bukan untuk mendiskreditkan penulisnya – karena kami menyukai karya dan kontribusi mereka terhadap open-source selama lebih dari satu dekade – namun dari penggunaan di dunia nyata tampaknya ada mungkin akan banyak sakit kepala dan potensi kehilangan data akibat penggunaan.
- Pemulihan cadangan harus dilakukan tanpa hambatan dan sepele. Menggunakan solusi seperti MongoDB dengan
mongodump
danmongoexport
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.
- Perintah Node.js sederhana untuk
- 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! 🚀