Self-hosting email dengan cara sulit, dimulai dari blok IPv4 yang dapat dirutekan sendiri

• Infrastruktur email Recoil yang beroperasi sejak 1997 diperbarui menjadi stack self-hosting yang menangani penerimaan, pengiriman, dan akses secara langsung dengan menggabungkan blok IPv4 /24 khusus, Postfix, Dovecot, rspamd, Roundcube, dan lainnya
• Mengoperasikan email sendiri memberi hak akses data dan nilai pembelajaran, tetapi di atas SMTP yang fondasi kepercayaannya lemah, reputasi IP, catatan DNS, dan pertahanan spam harus dikelola sendiri
• Jalur penerimaan dibangun agar lalu lintas bot dan email berbahaya berkurang bertahap melalui postscreen, DNSBL, greylisting, ClamAV, pemfilteran Bayesian, LMTP, dan Sieve
• Keandalan pengiriman bergantung pada SPF, DKIM, DMARC, dan SRS; jika salah konfigurasi, email bisa ditandai sebagai spam atau dibuang diam-diam oleh pemeriksaan penerima seperti Gmail dan Outlook
• Self-hosting email pada 2026 masih memungkinkan, tetapi memerlukan ketersediaan IPv4, berbagai catatan DNS, pembaruan keamanan, dan defense in depth untuk menghadapi eksploitasi kerentanan berbasis AI

---

Mengapa mengoperasikan email sendiri

• Menjalankan server sendiri adalah pengalaman edukatif untuk mempelajari sistem dan jaringan, sekaligus jalur untuk memahami cara kerja internet dan berpartisipasi dalam open source
• Di tengah web yang makin terkonsolidasi pada sedikit penyedia, self-hosting menjadi cara untuk mempertahankan akses berdaulat atas data sendiri
• Analisis tahun 2023 menilai bahwa pihak yang pada akhirnya dapat membaca lalu lintas email pada umumnya bermuara pada Google dan Microsoft
• Email terhubung ke reset kata sandi banyak akun online, sehingga pembajakan akun atau phishing dapat menggoyahkan akses ke layanan lain juga
• Mengoperasikan email sendiri memerlukan pengelolaan jangka panjang, serta hosting internet yang lebih stabil daripada jaringan rumah dan akumulasi reputasi

Arsitektur penerimaan email

• Domain internet menunjuk server SMTP penerima email melalui catatan DNS MX, dan recoil.org memproses email melalui pork.recoil.org
• SMTP berawal dari desain era 1980-an yang lebih berbasis kepercayaan dan pada dasarnya tidak dapat membuktikan identitas pengirim, sehingga pengirim pada email masuk mudah dipalsukan
• Respons IETF berkembang menjadi penumpukan berbagai pemeriksaan identitas, dan jika pemeriksaan ini salah dikonfigurasi, keandalan pengiriman email akan menurun
• Daftar blokir berbasis DNS mengumpulkan informasi botnet, host yang disusupi, dan spammer, sehingga server email dapat melakukan query RBL untuk menyaring IP mencurigakan
• Reputasi email dibangun pada alamat IP, bukan domain, sehingga alamat yang pernah dipakai ulang di cloud atau IP tetangga dalam blok yang sama dapat memengaruhi reputasi

• Mendapatkan blok IPv4 khusus dan merutekannya

  • Recoil mendapatkan blok alamat IPv4 khusus 185.33.27.0/24, sehingga bisa membangun reputasi email secara independen
  • RIPE NCC menghabiskan ruang IPv4 tak teralokasi pada November 2019, dan setelah itu alokasi langsung diproses melalui daftar tunggu /24 skala kecil
  • Blok /24 dialokasikan setelah menunggu sekitar 6 bulan, dan untuk mengajukan langsung di Eropa perlu membayar biaya keanggotaan RIPE NCC dan membuka akun LIR
  • Blok IPv4 yang dialokasikan menetapkan hak perutean dengan membuat RPKI ROA, dan blok Recoil dihubungkan ke Mythic Beasts AS44684
  • Reverse DNS juga bisa dikendalikan langsung, dan 185.33.27.128 dipetakan ke pork.recoil.org sebagai sinyal reputasi email

Pertahanan terhadap bot dan spam

• Memiliki blok IPv4 yang bersih saja tidak cukup; sebagian besar koneksi TCP yang masuk ke port 25 adalah upaya pengiriman spam, pencarian open relay, tebak kredensial, dan pengumpulan data untuk pelatihan AI
• Postfix postscreen melakukan query DNSBL paralel, jeda pre-greet, serta pemeriksaan pipelining dan perintah non-SMTP di depan port 25
• postscreen hanya meneruskan klien yang tampak valid ke smtpd yang sebenarnya, sementara klien yang salah diputus dengan kegagalan sementara agar false positive masih bisa mencoba lagi
• Daftar Spamhaus, Spamcop, dan Barracuda digabungkan dengan bobot, dan dikonfigurasi untuk menolak jika hanya Spamhaus yang cocok atau jika dua daftar yang lebih lemah cocok bersamaan
• Pool MX pengirim Apple iCloud tidak mencoba ulang dari IP yang sama sehingga tidak cocok dengan allowlist postscreen, maka seluruh 17.0.0.0/8 diizinkan lebih dulu agar bisa melewati pemeriksaan

• Greylisting dan pemeriksaan konten

  • Greylisting mengembalikan kegagalan sementara ke sumber pengirim yang baru pertama terlihat, lalu mengizinkannya jika MTA yang valid mencoba lagi beberapa menit kemudian
  • Botnet sekali pakai sering berpindah ke target berikutnya setelah gagal, sehingga dapat dibedakan dari pengirim valid yang mempertahankan antrean retry
  • Setelah melewati postscreen dan greylisting, lebih dari 99% lalu lintas bot awal sudah diblokir dengan biaya CPU rendah
  • rspamd memeriksa semua pesan melalui protokol milter, dan tidak menerima lalu memantulkan email mencurigakan, melainkan menolaknya atau menundanya saat server pengirim masih terhubung
  • ClamAV memeriksa lampiran yang mengandung virus yang sudah dikenal dan segera menolak pesan terinfeksi, sementara pengklasifikasi Bayesian rspamd memberi skor pesan menggunakan korpus spam dan ham yang disimpan di Redis

Pengiriman lokal, penyimpanan, dan pemfilteran

• Pesan masuk diteruskan ke Dovecot setelah melewati postscreen, greylisting, rspamd, ClamAV, dan pengklasifikasi Bayesian
• Alih-alih Postfix menulis langsung ke direktori home pengguna, email diteruskan ke Dovecot melalui LMTP untuk menangani pengindeksan, kuota, pencarian full-text, dan pemfilteran Sieve
• virtual_alias_maps mengubah alamat seperti [e-mail] menjadi alamat yang bisa dikirimkan secara lokal
• Format penyimpanan yang digunakan adalah Maildir sejak 1998, yang menyimpan setiap email sebagai satu file di bawah ~/Maildir milik pengguna
• Maildir menggunakan tiga subdirektori tmp/, new/, dan cur/, serta rename atomik POSIX agar pesan baru dapat dikirim tanpa mengunci seluruh mailbox

• Indeks pencarian dan Sieve

  • Server email modern seperti Stalwart juga dipertimbangkan, tetapi tidak mendukung Maildir dan menuntut penyimpanan database kustom seperti RocksDB, sehingga tidak jadi diadopsi
  • Dovecot memisahkan penyimpanan Maildir dan performa pencarian melalui indeks full-text terpisah bernama Flatcurve
  • Flatcurve adalah wrapper Xapian yang menempatkan indeks Xapian per-mailbox di bawah ~/Maildir/fts-flatcurve dan memperbaruinya otomatis saat email baru tiba
  • Sieve adalah bahasa deklaratif khusus untuk pemfilteran email, dan plugin Pigeonhole Sieve milik Dovecot menjalankan filter pengguna pada saat pengiriman
  • Skrip Sieve tingkat sistem mengirim email yang ditandai rspamd ke Junk, sementara skrip per pengguna menangani klasifikasi folder, aturan liburan, prioritas, pengeditan header, dan lainnya

Pengiriman email yang andal

• Untuk mengirim email dengan stabil, autentikasi pengiriman sama pentingnya dengan pertahanan penerimaan; jika satu saja pemeriksaan penerima besar gagal, email bisa masuk folder spam atau dibuang diam-diam
• SPF adalah catatan DNS TXT di puncak domain yang menyatakan alamat IP mana yang boleh mengklaim sebagai pengirim @recoil.org
• SPF milik Recoil adalah v=spf1 a mx -all, sehingga hanya pork.recoil.org yang dirujuk MX recoil.org yang dianggap sebagai pengirim sah
• Postfix diikat ke alamat sumber tertentu dengan smtp_bind_address dan smtp_bind_address6 agar kernel tidak memilih alamat secara acak pada host dengan banyak IP
• DKIM menambahkan tanda tangan kriptografis pada bentuk yang dinormalisasi dari isi pesan dan header tertentu, lalu menempatkan kunci verifikasi publik di <selector>._domainkey.<domain> pada DNS

• DMARC dan SRS

  • DMARC memeriksa apakah domain yang diautentikasi oleh SPF dan DKIM cocok dengan header From: yang dilihat pengguna, dan memberi tahu penerima bagaimana menangani kegagalan
  • Kebijakan DMARC Recoil adalah p=quarantine, dan laporan agregat diterima melalui alamat rua= untuk membantu men-debug masalah deliverability
  • Penerima besar mengirim laporan XML ringkasan sekali sehari atau sekitar itu untuk pesan yang mengklaim berasal dari recoil.org, termasuk Google, Microsoft, Yahoo, dan Fastmail
  • Email yang diteruskan dapat membuat domain pengirim asli tampak dikirim dari IP Recoil, sehingga SPF bisa gagal
  • SRS menulis ulang alamat envelope pengirim menjadi bentuk seperti SRS0=…=example.com=[e-mail], sehingga pemeriksaan SPF di tujuan dievaluasi berdasarkan domain Recoil

Akses pengguna dan webmail

• Pengguna mengakses email melalui klien IMAP biasa ke server Dovecot, atau membuka webmail self-hosting lewat browser
• Dovecot menangani akses mailbox pada pork dan mengenkripsi listener dengan TLS agar email atau kata sandi plaintext tidak melewati jaringan publik
• Sertifikat menggunakan LetsEncrypt, dan berbagai alias host seperti imap.recoil.org dan smtp.recoil.org disajikan lewat SNI
• Dovecot juga berperan sebagai backend SASL untuk Postfix, sehingga pengguna dapat memakai kata sandi yang sama untuk akses IMAP dan pengiriman SMTP
• Roundcube dijalankan sebagai layanan Docker Compose di belakang reverse proxy TLS Caddy, dan terhubung ke pork melalui TLS/IMAP seperti klien biasa

• Plugin Roundcube

  • Plugin managesieve Roundcube menggunakan protokol ManageSieve agar filter Sieve bisa diedit dari browser
  • Plugin markasjunk mengubah tombol “Junk” di webmail menjadi pemindahan ke folder Junk, dan perpindahan ini diam-diam memicu pembelajaran klasifikasi ham dan spam bagi pengguna
  • UI ManageSieve Roundcube tidak mengekspos DSL Sieve mentah

Pekerjaan yang tersisa dan makna self-hosting

• Konfigurasi saat ini terasa cukup kokoh dalam penggunaan sehari-hari selama beberapa minggu terakhir, tetapi masih ada pekerjaan yang harus diselesaikan
• recoil.org menyusun penerimaan, pengiriman, dan verifikasi email dengan menggabungkan catatan DNS seperti MX, A/AAAA, PTR, SPF TXT, DKIM TXT, dan DMARC TXT
• MTA-STS memberi tahu server email lain untuk hanya berkomunikasi melalui TLS dengan sertifikat yang valid, sehingga membantu memitigasi serangan downgrade STARTTLS
• DANE/TLSA menggunakan hash sertifikat TLS yang dipatok di DNS alih-alih HTTPS, tetapi belum diterapkan karena memerlukan zona DNS yang ditandatangani DNSSEC
• SRS sudah diterapkan sebagian, tetapi belum diverifikasi pada semua jalur penerusan, dan kegagalan terkait INRIA menjadi perhatian karena kemungkinan kegagalan DMARC dan dampak pada reputasi domain

• JMAP, keamanan, dan masa depan self-hosting

  • JMAP adalah protokol akses email yang menggunakan HTTPS dan JSON, sehingga lebih cocok daripada IMAP untuk klien jaringan modern
  • Dovecot tidak mendukung JMAP secara native, dan server JMAP mandiri yang dievaluasi menuntut meninggalkan Maildir serta memakai penyimpanan mailbox mereka sendiri
  • Rencana yang sedang dipertimbangkan adalah menempatkan implementasi JMAP OCaml di depan Dovecot sebagai proxy penerjemah, memetakan permintaan JMAP ke panggilan IMAP lalu mengembalikan respons JSON
  • Untuk menjalankan server email pada 2026, setidaknya enam catatan DNS harus dikonfigurasi dengan tepat, dan memperoleh blok IPv4 dari RIPE memerlukan waktu hampir satu tahun
  • Jeda antara pengungkapan CVE dan masuknya eksploit nyata ke listener SMTP/IMAP kini mungkin diukur dalam hitungan jam, bukan minggu, sehingga diperlukan defense in depth seperti pengikatan ke alamat tertentu, isolasi container webmail, greylisting, dan DNSBL

[GN⁺]

Komentar Lobste.rs

• Saya terus melihat para penjaga gerbang yang dengan yakin menyatakan mustahil melakukan sesuatu yang sebenarnya sudah dikerjakan selama puluhan tahun
  Padahal kenyataannya cukup menyiapkan reverse DNS, SPF, DMARC, dan MTA-STS, dan saya terus mengatakan bahwa itu tidak mahal maupun sulit
  Contoh server email: https://poofydoof.zia.io/

  • Saya sudah menjalankan self-hosting email sendiri sejak sekitar 2008, dan masih bingung karena banyak orang tetap bilang itu mustahil
    Sekarang saya memakai kombinasi Debian + Postfix, Dovecot, rspamd, dan masalah justru lebih sering muncul di Google Workspace kantor daripada di konfigurasi saya
  • Menurut saya, bagian “sudah dikerjakan selama puluhan tahun” itulah poin utamanya
    Pernyataan bahwa cukup menyiapkan reverse DNS, SPF, DMARC, dan MTA-STS itu 100% benar untuk domain dan alamat IP yang reputasinya sudah baik
    Jika Anda menambahkan domain baru ke server email yang sudah dipercaya oleh penyedia besar, reputasinya akan cepat terbentuk; memindahkan domain lama ke IP server email baru sambil menyiapkan DKIM juga biasanya aman
    Namun jika memulai dari nol dengan domain baru dan IP server email baru, saya dengar situasinya cukup berbeda, dan besar kemungkinan otomatis dianggap spam sampai sistem machine learning penyedia besar itu puas
    Tampaknya akan cukup membantu jika para pengguna sistem tersebut mengirim email ke domain saya lalu mengeluarkan balasan dari folder spam
  • Dari pengalaman mengoperasikan server email selama sekitar 3 tahun, bagian sulitnya bukan konfigurasi DNS, SPF, DMARC, atau MTA-STS, melainkan menghindari dihantam daftar blokir saat mengirim email transaksional dan tidak bisa masuk daftar izin di sebagian penyedia email
    Daripada terus menghabiskan waktu mengejar hal-hal seperti itu, menurut saya lebih baik bayar sekitar 5 dolar per bulan dan serahkan ke orang lain
  • Contoh server emailnya keren, dan ini juga bagus
    https://dmesgd.nycbug.org/dmesgd?do=view&id=8929
    Saya penasaran dengan detail lebih lanjut tentang konfigurasi ini
    Mango Pi MQ-Pro tampaknya sulit didapat, jadi saya juga ingin tahu apakah ada perangkat super murah lain dengan dukungan NetBSD/Linux yang bagus

• Alasan lain menjalankan server email sendiri adalah karena Anda bisa menemukan bahwa seseorang sudah mengirim spam dengan domain Anda
  Saat salah satu domain saya dipindahkan ke Squarespace karena penjualan Google Domains, Squarespace otomatis menambahkan record DNS MX/SPF/DKIM untuk Mailgun, padahal saya tidak punya akun Mailgun
  Seseorang mengambil alih akun itu di Mailgun, lalu mengirim spam ke saya seolah-olah berasal dari domain saya
  Terima kasih, Google

• Bagian alokasi IPv4 ini sangat menarik
  Untuk melakukannya sendiri di Eropa, tertulis bahwa Anda perlu membayar iuran tahunan RIPE NCC dan membuka akun local internet registry (LIR), yang menurut https://www.ripe.net/membership/payment/ biayanya 1800 euro per tahun
  Cukup menyakitkan, tetapi kalau lebih murah mungkin para spammer juga akan lebih mudah menyalahgunakannya

  • Memang tidak murah, tetapi hanya sekitar 12 pound per alamat per tahun, jadi kalau dibagi untuk layanan teman dan keluarga di sekitar Anda, sebenarnya tidak terlalu buruk
    Kesenangan menulis server BGP dengan OCaml tak ternilai harganya :-)

• Saya penasaran apakah IPv6 bisa dipakai secara realistis untuk mengirim dan menerima email

  • Pertanyaan bagus
    Saya sempat melihatnya saat menulis artikel itu, tetapi karena IPv6 sudah saya nonaktifkan di server email saya sejak beberapa tahun lalu, saya memutuskan menundanya sampai punya lebih banyak pengalaman
    Menurut https://dn.org/ipv6-and-domain-reputation-in-anti-spam-filters, penyedia email seperti Gmail, Microsoft, dan Yahoo memakai filter spam khusus yang memberi bobot berbeda pada reputasi domain dan reputasi IP, dan dukungan IPv6 mereka juga masih terus matang
    Gmail mewajibkan record PTR yang valid, SPF, dan DKIM untuk email IPv6, serta sangat menganjurkan penggunaan DMARC
    Tanpa faktor-faktor ini, email yang dikirim lewat IPv6 sering masuk folder spam atau mengalami penundaan
    Sistem penyaringan Microsoft memasukkan IPv6 ke dalam program SNDS dan JMRP, tetapi jika reputasi pengirim belum dikenal, email IPv6 bisa dibatasi atau ditunda
    Pada akhirnya IPv6 adalah satu lagi titik kegagalan, dan mungkin bukan ide bagus menyiapkan domain pengiriman campuran IPv4/IPv6 saat baru mulai
    Saya juga belum menemukan endpoint SMTP khusus IPv6