Email Tahan Kuantum: Bagaimana kami menggunakan kotak surat SQLite terenkripsi untuk menjaga keamanan email Anda

Kata Pengantar

Sampai kami meluncurkan Dukungan IMAP, kami menggunakan MongoDB untuk kebutuhan penyimpanan data persisten kami.

Teknologi ini luar biasa dan kita masih menggunakannya hingga saat ini – tetapi untuk memiliki enkripsi yang 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, menggunakan teknologi yang mengharuskan Anda membayar biaya lisensi untuk mendapatkan fitur enkripsi-saat-diam bertentangan dengan prinsip-prinsip kami – sehingga kami bereksperimen, meneliti, dan mengembangkan solusi baru dari awal untuk memenuhi kebutuhan ini.

Alih-alih menggunakan database bersama untuk menyimpan kotak surat Anda, kami menyimpan dan mengenkripsi kotak surat Anda secara individual dengan kata sandi Anda (yang hanya Anda yang tahu). Layanan email kami sangat aman sehingga jika Anda lupa kata sandi, Anda akan kehilangan kotak surat Anda (dan perlu memulihkannya dengan cadangan offline atau memulai dari awal).

Teruslah membaca selagi kami membahasnya lebih dalam di bawah ini dengan perbandingan penyedia layanan email, cara kerja layanan kami, tumpukan teknologi kami, dan banyak lagi.

Perbandingan penyedia layanan email

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

Tidak seperti penyedia email lainnya, Anda tidak perlu membayar biaya penyimpanan per domain atau alias dengan Forward Email. Penyimpanan digunakan bersama di seluruh akun Anda – jadi jika Anda memiliki beberapa nama domain kustom dan beberapa alias di setiap domain, kami adalah solusi yang tepat. Perlu diketahui bahwa Anda masih dapat menerapkan batas penyimpanan jika diinginkan per 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 server IMAP kami yang aman menggunakan nama pengguna dan kata sandi Anda:

• Nama pengguna Anda adalah alias lengkap dengan domain Anda, misalnya hello@example.com.
• Kata sandi Anda dibuat secara acak dan hanya ditampilkan selama 30 detik ketika Anda mengklik Buat Kata Sandi dari Akun Saya Domain Alias.

2. Setelah terhubung, klien email Anda akan mengirimkan Perintah protokol IMAP ke server IMAP kami agar kotak surat Anda tetap sinkron. Ini termasuk menulis dan menyimpan draf email dan tindakan lain yang mungkin Anda lakukan (misalnya, memberi label email sebagai Penting atau menandai email sebagai Spam/Sampah).

3. Server pertukaran email (umumnya dikenal sebagai server "MX") menerima email masuk baru dan menyimpannya di kotak surat Anda. Saat ini terjadi, klien email Anda akan menerima notifikasi dan menyinkronkan kotak surat Anda. Server pertukaran email kami dapat meneruskan email Anda ke satu atau beberapa penerima (termasuk kait web), menyimpan email Anda di penyimpanan IMAP terenkripsi kami, atau keduanya!

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

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

  

• Saat Anda terhubung ke server IMAP kami dengan klien email Anda, kata sandi Anda akan 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. Perlu diingat bahwa karena Anda satu-satunya yang memiliki kata sandi ini, hanya Anda yang dapat membaca dan menulis ke kotak surat Anda saat mengaksesnya. Saat klien email Anda mencoba memeriksa email atau sinkronisasi berikutnya, pesan baru Anda akan ditransfer dari kotak surat sementara ini dan disimpan di berkas kotak surat Anda yang sebenarnya menggunakan kata sandi yang Anda berikan. Harap dicatat bahwa kotak surat sementara ini akan dihapus setelahnya sehingga hanya kotak surat Anda yang dilindungi kata sandi yang menyimpan pesan-pesan tersebut.

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

  

5. Pencadangan 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 menghapus kotak surat dan cadangan Anda kapan saja.

Teknologi

Basis Data

Kami menjajaki kemungkinan lapisan penyimpanan basis data lainnya, namun tidak ada yang memenuhi persyaratan kami sebanyak SQLite:

Basis Data	Enkripsi-saat-diam	Sandboxed Kotak Surat	Lisensi	Used Everywhere
SQLite :bintang:	✅ Ya dengan SQLite3MultipleCiphers	:tanda_centang_putih:	✅ Domain Publik	:tanda_centang_putih:
MongoDB	❌ "Available in MongoDB Enterprise only"	❌ Basis data relasional	❌ AGPL dan SSPL-1.0	:X:
rqlite	❌ Network only	❌ Basis data relasional	:tanda_centang_putih: KODE_SEL_0	:X:
dqlite	❌ Untested and not yet supported?	❌ Untested and not yet supported?	:tanda_centang_putih: KODE_SEL_0	:X:
PostgreSQL	:tanda_centang_putih: Yes	❌ Basis data relasional	✅ PostgreSQL (mirip dengan BSD atau MIT)	:X:
MariaDB	:tanda_centang_putih: For InnoDB only	❌ Basis data relasional	✅ GPLv2 dan BUSL-1.1	:X:
CockroachDB	❌ Enterprise-only feature	❌ Basis data relasional	❌ BUSL-1.1 dan lainnya	:X:

Berikut adalah postingan blog yang membandingkan beberapa opsi penyimpanan database SQLite pada tabel di atas.

Keamanan

Kami selalu menggunakan enkripsi-saat-diam (AES-256), enkripsi-dalam-transit (TLS), DNS melalui HTTPS ("DoH") menggunakan enkripsi 🍊 Jeruk keprok, dan sqleet (ChaCha20-Poly1305) di kotak surat. Selain itu, kami menggunakan autentikasi dua faktor berbasis token (berbeda dengan SMS yang rentan terhadap serangan perantara), kunci SSH yang dirotasi dengan akses root dinonaktifkan, akses eksklusif ke server melalui alamat IP terbatas, dan banyak lagi.

Jika terjadi serangan pembantu jahat atau karyawan nakal dari vendor pihak ketiga, kotak surat Anda tetap hanya dapat dibuka dengan kata sandi yang Anda buat. Yakinlah, kami tidak bergantung pada vendor pihak ketiga mana pun selain penyedia server keluhan SOC Tipe 2 kami, yaitu Cloudflare, DataPacket, Digital Ocean, dan Vultr.

Sasaran kami adalah memiliki titik kegagalan tunggal sesedikit mungkin.

Kotak Surat

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

SQLite adalah salah satu 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 basis data SQLite untuk linux@example.com, info@example.com, hello@example.com, dan seterusnya – satu untuk masing-masing sebagai berkas basis data .sqlite. Kami juga tidak memberi nama berkas basis data dengan alamat email – sebagai gantinya, kami menggunakan ID Objek BSON dan UUID unik yang dihasilkan, yang tidak membagikan siapa pemilik kotak surat tersebut atau alamat emailnya (misalnya, 353a03f21e534321f5d6e267.sqlite).

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

Kami telah menyempurnakan SQLite dengan PRAGMA berikut:

PRAGMA	Tujuan
cipher=chacha20	ChaCha20-Poly1305 SQLite database encryption. Lihat better-sqlite3-multiple-ciphers di bawah Projects untuk informasi lebih lanjut.
key="****************"	Ini adalah kata sandi terdekripsi khusus di dalam memori Anda yang diteruskan melalui koneksi IMAP klien email Anda ke server kami. Instans basis data baru dibuat dan ditutup untuk setiap sesi baca dan tulis (untuk memastikan sandboxing dan isolasi).
journal_model=WAL	Catatan-tulis-depan ("WAL") which boosts performance and allows concurrent read access.
busy_timeout=5000	Mencegah kesalahan kunci tulis while other writes are taking place.
synchronous=NORMAL	Meningkatkan daya tahan transaksi without data corruption risk.
foreign_keys=ON	Menegakkan bahwa referensi kunci asing (misalnya relasi dari satu tabel ke tabel lain) ditegakkan. By default this is not turned on in SQLite, tetapi untuk validasi dan integritas data harus diaktifkan.
encoding='UTF-8'	Default encoding digunakan untuk memastikan kewarasan pengembang.

Semua default lainnya berasal dari SQLite seperti yang ditetapkan dari dokumentasi resmi PRAGMA.

Konkurensi

tldr; Kami menggunakan WebSocket untuk pembacaan dan penulisan serentak ke kotak surat SQLite Anda yang terenkripsi.

Membaca

Klien email di ponsel Anda mungkin menyelesaikan imap.forwardemail.net ke salah satu alamat IP Digital Ocean kami – dan klien desktop Anda mungkin menyelesaikan IP terpisah dari penyedia yang berbeda sama sekali.

Apa pun server IMAP yang terhubung dengan klien email Anda, kami ingin koneksi tersebut membaca dari basis data Anda secara real-time dengan akurasi 100%. Hal 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 menjajaki opsi seperti litestream, rqlite, dan dqlite di bawah ini – namun tidak satu pun memenuhi persyaratan kami.

Untuk menyelesaikan penulisan dengan pencatatan awal ("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 beberapa pembaca.

Server Utama berjalan di server data dengan volume terpasang yang berisi kotak surat terenkripsi. Dari sudut pandang distribusi, Anda dapat menganggap semua server IMAP individual di belakang imap.forwardemail.net sebagai server sekunder ("Sekunder").

Kami melakukan komunikasi dua arah dengan Soket Web:

• Server utama menggunakan instans server WebSocketServer dari ws.
• Server sekunder menggunakan instans klien WebSocket dari ws yang dibungkus dengan websocket-seperti-yang-dijanjikan dan menghubungkan kembali-websocket. Kedua pembungkus ini memastikan bahwa WebSocket terhubung kembali dan dapat mengirim serta menerima data untuk penulisan basis data tertentu.

Cadangan

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

Untuk pencadangan, kami cukup menjalankan perintah SQLite VACUUM INTO 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 hash SHA-256 pada berkas telah berubah dibandingkan dengan cadangan terbaru.

Perhatikan bahwa kami menggunakan perintah VACUUM INTO, bukan perintah bawaan backup. Jika suatu halaman dimodifikasi selama operasi perintah backup, maka halaman tersebut harus dimulai ulang. Perintah VACUUM INTO akan mengambil snapshot. Lihat komentar tentang GitHub dan Berita Peretas untuk informasi lebih lanjut.

Selain itu, kami menggunakan VACUUM INTO dan bukan backup, karena perintah backup akan membiarkan basis data tidak terenkripsi untuk beberapa saat hingga rekey dipanggil (lihat GitHub komentar ini untuk wawasan).

Secondary akan memerintahkan Primary melalui koneksi WebSocket untuk menjalankan pencadangan – dan Primary kemudian akan menerima perintah untuk melakukannya dan selanjutnya akan:

1. Hubungkan ke kotak surat terenkripsi Anda.
2. Dapatkan kunci tulis.
3. Jalankan titik pemeriksaan WAL melalui wal_checkpoint(PASSIVE).
4. Jalankan perintah SQLite VACUUM INTO.
5. Pastikan berkas yang disalin dapat dibuka dengan kata sandi terenkripsi (pengamanan/pengamanan dummy).
6. Unggah ke Cloudflare R2 untuk penyimpanan (atau penyedia Anda sendiri jika ditentukan).

Ingatlah bahwa kotak surat Anda dienkripsi – dan meskipun kami memiliki batasan IP dan langkah-langkah autentikasi lain untuk komunikasi WebSocket – jika terjadi pelaku jahat, Anda dapat yakin bahwa kecuali muatan WebSocket memiliki kata sandi IMAP Anda, ia tidak dapat membuka basis data Anda.

Saat ini, hanya satu cadangan yang disimpan per kotak surat, tetapi di masa mendatang kami mungkin menawarkan pemulihan titik waktu ("PITR").

Cari

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

Kinerja pencarian yang cepat berkat FTS5 dan sqlite-regex.

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

Indeks juga disimpan untuk semua properti yang ada dalam kueri penelusuran.

Proyek

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

Proyek	Tujuan
Ansible	Platform otomatisasi DevOps untuk memelihara, meningkatkan skala, dan mengelola seluruh armada server kami dengan mudah.
Bree	Penjadwal pekerjaan untuk Node.js dan JavaScript dengan cron, tanggal, ms, nanti, dan dukungan yang ramah manusia.
Cabin	Pustaka pencatatan JavaScript dan Node.js yang mudah dikembangkan dengan mempertimbangkan keamanan dan privasi.
Lad	Kerangka kerja Node.js yang mendukung seluruh arsitektur dan desain teknik kami dengan MVC dan banyak lagi.
MongoDB	Solusi basis data NoSQL yang kami gunakan untuk menyimpan semua data lain di luar kotak surat (misalnya akun, pengaturan, domain, dan konfigurasi alias Anda).
Mongoose	Pemodelan dokumen objek MongoDB ("ODM") yang kami gunakan di seluruh tumpukan kami. Kami menulis helper khusus yang memungkinkan kami untuk tetap menggunakan Mongoose 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.
Redis	Basis data dalam memori untuk caching, saluran publikasi/berlangganan, dan permintaan DNS melalui HTTPS.
SQLite3MultipleCiphers	Ekstensi enkripsi untuk SQLite yang memungkinkan seluruh file basis data dienkripsi (termasuk write-ahead-log ("WAL"), jurnal, rollback, …).
SQLiteStudio	Editor Visual SQLite (yang juga dapat Anda gunakan) untuk menguji, mengunduh, dan melihat kotak surat pengembangan.
SQLite	Lapisan basis data tertanam untuk penyimpanan IMAP yang dapat diskalakan, mandiri, cepat, dan tangguh.
Spam Scanner	Alat anti-spam, penyaringan email, dan pencegahan phishing Node.js (alternatif kami untuk Spam Assassin dan rspamd).
Tangerine	Permintaan DNS melalui HTTPS dengan Node.js dan caching menggunakan Redis – yang memastikan konsistensi global dan banyak lagi.
Thunderbird	Tim pengembangan kami menggunakan ini (dan merekomendasikan ini juga) sebagai klien email pilihan untuk digunakan dengan Forward Email.
UTM	Tim pengembangan kami menggunakan ini untuk membuat mesin virtual untuk iOS dan macOS guna menguji berbagai klien email (secara paralel) dengan server IMAP dan SMTP kami.
Ubuntu	Sistem operasi server modern berbasis Linux sumber terbuka yang mendukung seluruh infrastruktur kami.
WildDuck	Pustaka server IMAP – lihat catatannya pada attachment de-duplication dan IMAP protocol support.
better-sqlite3-multiple-ciphers	Pustaka API yang cepat dan sederhana untuk Node.js untuk berinteraksi dengan SQLite3 secara terprogram.
email-templates	Kerangka kerja email yang mudah dikembangkan untuk membuat, melihat pratinjau, dan mengirim email khusus (misalnya pemberitahuan akun dan lainnya).
json-sql-enhanced	Pembangun kueri SQL menggunakan sintaksis bergaya Mongo. Ini menghemat waktu tim pengembangan kami karena kami dapat terus menulis dalam gaya Mongo di seluruh tumpukan dengan pendekatan yang tidak bergantung pada basis data. Ini juga membantu menghindari serangan injeksi SQL dengan menggunakan parameter kueri.
knex-schema-inspector	Utilitas SQL untuk mengekstrak informasi tentang skema basis data yang ada. Hal ini memungkinkan kami untuk dengan mudah memvalidasi bahwa semua indeks, tabel, kolom, batasan, dan lainnya valid dan sesuai dengan 1:1 sebagaimana mestinya. Kami bahkan menulis helper otomatis untuk menambahkan kolom dan indeks baru jika ada perubahan pada skema basis data (dilengkapi dengan peringatan kesalahan yang sangat detail).
knex	Pembangun kueri SQL yang kami gunakan hanya untuk migrasi basis data dan validasi skema melalui knex-schema-inspector.
mandarin	Terjemahan frasa i18n otomatis dengan dukungan untuk Markdown menggunakan Google Cloud Translation API.
mx-connect	Paket Node.js untuk menyelesaikan dan membuat koneksi dengan server MX dan menangani kesalahan.
pm2	Manajer proses produksi Node.js dengan penyeimbang beban bawaan (fine-tuned untuk kinerja).
smtp-server	Pustaka server SMTP – kami menggunakan ini untuk pertukaran surat elektronik ("MX") dan server SMTP keluar.
ImapTest	Alat yang berguna untuk menguji server IMAP berdasarkan tolok ukur dan kompatibilitas protokol IMAP berdasarkan spesifikasi RFC. Proyek ini dibuat oleh tim Dovecot (server IMAP dan POP3 sumber terbuka yang aktif sejak Juli 2002). Kami telah menguji server IMAP kami secara ekstensif dengan alat ini.

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

Penyedia

Penyedia	Tujuan
Cloudflare	Penyedia DNS, pemeriksaan kesehatan, penyeimbang beban, dan penyimpanan cadangan menggunakan Cloudflare R2.
Digital Ocean	Hosting server khusus dan basis data terkelola.
Vultr	Hosting server khusus.
DataPacket	Hosting server khusus.

Pikiran

Prinsip

Email Terusan dirancang berdasarkan prinsip-prinsip berikut:

1. Selalu ramah pengembang, berfokus pada keamanan dan privasi, serta transparan.
2. Patuhi MVC, Unix, KISS, DRY, YAGNI, Dua Belas Faktor, Pisau cukur Occam, dan makanan anjing
3. Targetkan pengembang yang scrappy, bootstrapped, dan ramen-menguntungkan

Eksperimen

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

Kami telah melakukan beberapa percobaan menjelang solusi SQLite akhir kami seperti dibahas di atas.

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

Percobaan itu membawa kami untuk lebih memahami dan menemukan kasus-kasus khusus seputar penggunaan rclone, SQLite, dan VFS:

• Jika Anda mengaktifkan flag --vfs-cache-mode writes dengan rclone, pembacaan akan baik-baik saja, namun penulisan akan di-cache.
• Jika Anda memiliki beberapa server IMAP yang terdistribusi 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 mengakibatkan lebih banyak titik kegagalan tunggal.
• Penyedia penyimpanan yang kompatibel dengan S3 tidak mendukung perubahan berkas parsial – yang berarti setiap perubahan pada berkas .sqlite akan mengakibatkan perubahan total dan pengunggahan ulang basis data.
• Solusi lain seperti rsync memang ada, tetapi tidak berfokus pada dukungan write-ahead-log ("WAL") – jadi kami akhirnya meninjau Litestream. Untungnya, penggunaan enkripsi kami sudah mengenkripsi berkas WAL, jadi kami tidak perlu bergantung pada Litestream untuk itu. Namun, kami belum yakin dengan Litestream untuk penggunaan produksi dan berikut beberapa catatannya.
• Menggunakan opsi --vfs-cache-mode writes ini (satu-satunya cara untuk menggunakan SQLite daripada rclone untuk penulisan) akan mencoba menyalin seluruh basis data dari awal ke dalam memori – menangani satu kotak surat berukuran 10 GB tidak masalah, namun menangani beberapa kotak surat dengan penyimpanan yang sangat tinggi akan menyebabkan server IMAP mengalami keterbatasan memori dan kesalahan ENOMEM, kesalahan segmentasi, dan kerusakan data. * Jika Anda mencoba menggunakan SQLite Tabel Virtual (misalnya menggunakan s3db) agar data tersimpan di lapisan penyimpanan yang kompatibel dengan S3, Anda akan mengalami beberapa masalah tambahan:
• Proses baca dan tulis akan sangat lambat karena titik akhir API S3 perlu diakses dengan metode HTTP .sqlite0, .sqlite1, .sqlite2, dan .sqlite3.
• Uji pengembangan menunjukkan bahwa melebihi 500 ribu-1 juta rekaman di internet fiber masih dibatasi oleh throughput penulisan dan pembacaan ke penyedia yang kompatibel dengan S3. Misalnya, pengembang kami menjalankan loop .sqlite4 untuk melakukan pernyataan SQL .sqlite5 berurutan dan pernyataan yang menulis data dalam jumlah besar secara massal. Dalam kedua kasus tersebut, kinerjanya sangat lambat.
• Tabel virtual tidak boleh memiliki indeks, pernyataan .sqlite6, dan .sqlite7 .sqlite8 – yang menyebabkan penundaan hingga 1-2 menit atau lebih, tergantung pada jumlah data.
• Objek disimpan tanpa enkripsi dan tidak ada dukungan enkripsi asli yang tersedia.
• Kami juga menjajaki penggunaan .sqlite9 yang secara konseptual dan teknis serupa dengan poin sebelumnya (sehingga memiliki masalah yang sama). Salah satu kemungkinannya adalah menggunakan build rsync0 kustom yang dibungkus dengan enkripsi seperti rsync1 (yang saat ini kami gunakan dalam solusi kami di atas) hingga rsync2.
• Pendekatan potensial lainnya adalah menggunakan rsync3, namun ini memiliki batasan 32 GB dan akan memerlukan kerumitan dalam proses build dan pengembangan. * Pernyataan rsync4 diperlukan (jadi ini sepenuhnya mengesampingkan penggunaan Tabel Virtual). Kita memerlukan pernyataan rsync5 agar hook kita dengan rsync6 berfungsi dengan baik – yang memastikan bahwa data tidak rusak dan baris yang diambil dapat dikonversi menjadi dokumen yang valid sesuai dengan definisi skema rsync7 kita (yang mencakup batasan, tipe variabel, dan validasi data arbitrer).
• Hampir semua proyek yang kompatibel dengan S3 terkait SQLite di komunitas sumber terbuka menggunakan Python (dan bukan JavaScript yang kami gunakan untuk 100% tumpukan kami).
• Pustaka kompresi seperti rsync8 (lihat rsync9) terlihat menjanjikan, tetapi __PROTECTED_LINK_189__0. Sebaliknya, kompresi sisi aplikasi pada tipe data seperti __PROTECTED_LINK_189__1, __PROTECTED_LINK_189__2, __PROTECTED_LINK_189__3, __PROTECTED_LINK_189__4, __PROTECTED_LINK_189__5, dan __PROTECTED_LINK_189__6 akan menjadi pendekatan yang lebih bersih dan mudah (dan juga lebih mudah dimigrasikan, karena kita dapat menyimpan flag atau kolom __PROTECTED_LINK_189__7 – atau bahkan menggunakan __PROTECTED_LINK_189__8 __PROTECTED_LINK_189__9 untuk kompresi atau __PROTECTED_LINK_190__0 tanpa kompresi sebagai metadata basis data).
• Untungnya, kami telah menerapkan deduplikasi lampiran di penyimpanan server IMAP kami – sehingga setiap pesan dengan lampiran yang sama tidak akan menyimpan salinan lampiran tersebut – sebagai gantinya, satu lampiran disimpan untuk beberapa pesan dan utas dalam satu kotak surat (dan referensi asing selanjutnya digunakan). * Proyek Litestream, yang merupakan solusi replikasi dan pencadangan SQLite, sangat menjanjikan dan kemungkinan besar kami akan menggunakannya di masa mendatang.
• Bukan bermaksud meremehkan penulisnya – karena kami mengapresiasi karya dan kontribusi mereka terhadap sumber terbuka selama lebih dari satu dekade – namun, dari penggunaan di dunia nyata, tampaknya terdapat __PROTECTED_LINK_190__1 dan __PROTECTED_LINK_190__2.
• Pemulihan cadangan harus mudah dan sederhana. Menggunakan solusi seperti MongoDB dengan __PROTECTED_LINK_190__3 dan __PROTECTED_LINK_190__4 tidak hanya membosankan, tetapi juga memakan waktu dan memiliki kompleksitas konfigurasi.
• Basis data SQLite membuatnya sederhana (berkas tunggal).
• Kami ingin merancang solusi yang memungkinkan pengguna mengambil kotak surat mereka dan pergi kapan saja.
• Perintah Node.js sederhana untuk __PROTECTED_LINK_190__5 dan akan dihapus secara permanen dari penyimpanan disk. * Kita juga dapat menggunakan API yang kompatibel dengan S3 dengan HTTP __PROTECTED_LINK_190__6 untuk menghapus snapshot dan cadangan bagi pengguna dengan mudah.
• SQLite adalah solusi paling sederhana, tercepat, dan paling hemat biaya.

Kurangnya alternatif

Sepengetahuan kami, tidak ada layanan email lain yang dirancang dengan cara ini dan juga bukan layanan sumber terbuka.

Kami berpikir ini mungkin terjadi karena layanan email yang ada memiliki teknologi lama dalam produksi dengan kode spageti 🍝.

Sebagian besar, jika tidak semua, penyedia layanan email yang ada bersifat sumber tertutup atau mengiklankan sebagai sumber terbuka, tetapi kenyataannya hanya antarmuka pengguna mereka yang merupakan sumber terbuka.

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

Coba Teruskan Email

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