Menjalankan server email sendiri seperti tahun 1984
(maxadamski.com)- Mengoperasikan server email sendiri memungkinkan otomasi dan pengelolaan mailing list dengan biaya rendah
- Ada masalah nyata terkait keandalan pengiriman, sehingga email ke/dari layanan besar bisa gagal terkirim atau diterima
- Hanya dengan konfigurasi Postfix dan OpenDKIM, sistem SMTP dasar dan pengiriman email terautentikasi dapat dibangun
- Dengan pengaturan sertifikat SSL, DKIM, SPF, DMARC, kepercayaan email dan keamanan pengiriman dapat ditingkatkan
- Jika rekaman PTR (reverse DNS) juga dikonfigurasi, tingkat keterkiriman ke layanan email besar dapat meningkat
Gambaran umum
Mengoperasikan server email sendiri berguna untuk otomasi seperti mailing list, newsletter, API verifikasi email
Namun tantangan paling nyata adalah keandalan pengiriman email, karena ada risiko email tidak sampai dengan benar atau gagal diterima
Penulis menerapkan pendekatan ini pada proyek pribadi dengan menerima risiko tersebut
Keuntungan menjalankannya sendiri adalah hampir tidak ada biaya tambahan, karena cukup memasang perangkat lunak pada situs web yang sudah ada, dan kebutuhan ruang penyimpanan maupun konsumsi energinya juga sangat kecil
Awalnya server email dianggap terlalu sulit, tetapi kenyataannya tingkat kesulitannya tidak jauh berbeda dengan menyiapkan layanan email bergaya SaaS
Untuk kemudahan konfigurasi dan penyederhanaan, webmail dan lingkungan multi-pengguna untuk sementara dihilangkan sehingga tidak perlu menyiapkan akun pengguna, database, atau antarmuka web
Konfigurasi kali ini cocok untuk pengoperasian satu akun, dan bila perlu email dapat dikirim/diterima melalui SSH serta mailx, sendmail, mutt
Ke depan, perluasan dan penambahan webmail juga dapat dipertimbangkan sesuai kebutuhan
Postfix
Pada dasarnya cukup membuka port 25, lalu memasang dan mengonfigurasi Postfix serta OpenDKIM untuk membangun server SMTP dasar
Agar email dapat dikirim secara andal ke sebagian besar layanan email (seperti Gmail), OpenDKIM (autentikasi email) diperlukan
Penulis membiarkan master.cf pada nilai bawaan, dan pada contoh konfigurasi utama (main.cf) hanya menampilkan pengaturan inti seperti enkripsi TLS dan integrasi DKIM
POP3/IMAP tidak dikonfigurasi, dan pengaturannya disederhanakan agar bila perlu pengguna bisa langsung masuk ke server melalui SSH lalu mengirim/ menerima email dengan perintah seperti mailx
TLS (enkripsi transport)
Sertifikat SSL diperlukan untuk mengenkripsi transfer data ke/dari server SMTP
Tidak perlu menerbitkan sertifikat untuk setiap domain; cukup satu host tempat server email berada (untuk rekaman MX) yang memiliki sertifikat
Misalnya, jika rekaman MX adalah mx.example.com, maka cukup ambil sertifikat gratis dari Let’s Encrypt untuk domain tersebut dan terapkan
TLS hanya mengenkripsi segmen pengiriman antarserver, dan terpisah dari autentikasi nama domain pengirim yang sebenarnya
Karena itu, nilai yang diinginkan tetap bisa diatur bebas pada header From alamat email
DKIM, SPF, DMARC
DKIM digunakan untuk membuktikan bahwa email benar-benar berasal dari domain sendiri dan untuk meningkatkan kepercayaan terhadap email
Dengan OpenDKIM, pasangan kunci dibuat untuk setiap domain, lalu kunci publik didaftarkan sebagai rekaman DNS TXT
Kunci tidak kedaluwarsa secara otomatis, tetapi disarankan untuk diganti secara berkala
Rekaman TXT SPF dan DMARC juga ditambahkan ke DNS untuk menentukan host mana yang boleh mengirim email serta kebijakan DMARC (misalnya ditolak jika autentikasi gagal)
Pada contoh berkas konfigurasi (opendkim.conf, KeyTable, SigningTable, TrustedHosts), cara mengatur tiap item dapat dilihat dengan jelas
Di DNS, cukup tambahkan rekaman terkait MX, SPF, DKIM, dan DMARC
Reverse DNS (PTR)
Rekaman PTR (reverse DNS) meningkatkan kepercayaan terhadap server email sehingga peluang email diblokir oleh layanan besar (seperti Gmail) menjadi lebih kecil
Perlu menghubungi ISP untuk meminta pengaturan rekaman PTR bagi server email
Di lingkungan produksi nyata, meskipun tanpa rekaman PTR, email tetap diterima dengan normal oleh Gmail, GMX, Outlook, dan lainnya, serta memperoleh skor 10/10 di mail-tester.com
Memang ada pengurangan nilai karena PTR belum diatur, tetapi mendapat nilai tambah sebagai "trusted relay"
IP pengirim juga dinilai baik karena tidak terdaftar dalam blacklist
Uji pengiriman ke Gmail
Email uji (pesan HTML) dikirim ke Gmail dengan perintah sendmail
Di Gmail, email langsung tiba, dan enkripsi TLS terkonfirmasi
Saat melihat email asli lewat "Show original", autentikasi SPF, DKIM, dan DMARC semuanya lolos
Isi email yang diterima dapat diperiksa secara lokal (di server) menggunakan mailx
Jika ada masalah konfigurasi, perlu memeriksa ulang DNS, sertifikat, hak akses kunci DKIM, dan sebagainya; khususnya berkas konfigurasi OpenDKIM sangat sensitif terhadap salah ketik
Langkah berikutnya
Pada tulisan berikutnya, akan diperkenalkan cara membuat aplikasi email dengan Python
Jika ada pertanyaan atau masukan, dapat menghubungi max@idx.cy
1 komentar
Komentar Hacker News
Saya bangga sudah meng-host email sendiri selama lebih dari 20 tahun, dan berencana terus melakukannya. Ironisnya, pemerintah atau lembaga terkait justru tidak bisa menjalankan sistem email sendiri, dan hanya badan keamanan negara yang melakukan hosting sendiri. Mungkin saya beruntung, tetapi hampir tidak pernah mengalami masalah pengiriman email; yang paling saya ingat belakangan ini adalah saat Microsoft menelan email saya, dan itu ternyata karena kekusutan autentikasi TLS antara exim lama dan outlook. Cukup ubah satu pengaturan dan selesai. Perawatannya sendiri tidak terlalu menyita tenaga, jadi setiap kali saya menyentuh sesuatu, saya anggap itu sebagai kesempatan mempelajari hal baru. Tahun ini saya mengganti Debian jessie ke Arch Linux dan memindahkan seluruh pekerjaan cron ke timer systemd. Saat mengirim email penting, saya selalu memeriksa log server, dan menurut saya itu juga kebiasaan baik untuk membiasakan diri meninjau log secara langsung. Kalau mau memberi saran, anggap self-hosting sebagai hobi dan nikmati prosesnya. Terakhir, orang yang merancang konfigurasi Exim di Debian benar-benar penyebab banyak waktu terbuang. Kalau membangun Exim di Debian, solusinya adalah ganti ke konfigurasi resmi Upstream lalu kustomisasi sesuai kebutuhan
Sekarang banyak SNS membanggakan diri dengan kata-kata seperti “terdesentralisasi” atau “terbuka”, padahal sebenarnya kita sudah punya alat yang memungkinkan kita benar-benar mandiri secara independen. Sering kali orang lupa bahwa atas nama perbaikan UX, kendali pengguna justru menghilang. Pada akhirnya, jika kita terus terbiasa dengan sistem yang terlalu disederhanakan, masa depan bisa jadi seperti dunia tempat seseorang di negeri lain harus mengizinkan “transaksi” sebelum kita bahkan bisa memasang satu aplikasi pun
Saya pertama kali memakai email saat kuliah, sebelum era WWW, lalu menggunakan akun ISP dengan ruang penyimpanan yang sangat terbatas dan hanya mendukung POP, jadi saya akhirnya menjalankan server email sendiri. Waktu itu saya tidak selalu terhubung ke internet, jadi saya menerima email melalui relay dan dynamic DNS. Sekarang saya memakai VPS sebagai perantara untuk menerima dan menyimpan email di server rumah. Selama bertahun-tahun ada kalanya saya harus meminta pembukaan blokir IP atau domain ke layanan email besar seperti Outlook, tetapi itu tidak terlalu sering. Saya tidak ingin hidup di dunia di mana dua atau tiga perusahaan menguasai email seluruh dunia, jadi saya menganggap self-hosting seperti ini sebagai bentuk perlawanan kecil
Saya berharap masih punya setidaknya 1% motivasi yang dulu saya miliki 20 tahun lalu. Sekarang saya sudah tidak punya waktu untuk pekerjaan seperti itu karena ada pekerjaan penuh waktu dan keluarga, istri dan anak
Saya juga pernah menjauh dari self-hosting, tetapi sekarang saya mulai bertanya-tanya apakah ini layak dilakukan lagi karena keseimbangan waktu/biaya sudah berubah. Kekhawatiran terbesar saya untuk hosting email adalah pengelolaan spam. Bagaimana kondisinya sekarang, dan kalau ada tips, tolong dibagikan
Bagi saya, email adalah layanan yang sangat penting. Saya berhenti setelah 15 tahun self-hosting karena 1) saya tidak cukup baik dalam backup/pemulihan dan pemantauan rutin, 2) saya tidak punya rencana pemulihan bencana sehingga biayanya jadi lebih tinggi dibanding layanan lain, dan 3) saya tidak selalu bisa fokus pada keamanan. Server teman saya kena ransomware dan semua datanya hilang, tetapi saya selamat karena memakai FreeBSD, jadi bukan target serangannya. Secara umum perawatannya tidak terlalu rumit, tetapi kalau sekali kusut, penderitaannya bisa benar-benar berat dan bahkan fatal
Dulu saya meng-host email sendiri, tetapi saya menyerah bukan karena reputasi, melainkan karena saya tidak bisa menghindari tuntutan uptime 100%, yang menimbulkan risiko kehilangan email atau masuk daftar hitam. Secara protokol email memang tahan terhadap downtime, tetapi dalam praktiknya penyedia email besar langsung menolak email saat ada satu kali masalah dan tidak mencoba lagi. GitHub dulu juga begitu: sekali bounce, alamat langsung ditandai “tidak bisa menerima” dan email berikutnya sama sekali tidak dikirim. Sekarang memang sudah membaik, tetapi sistem email modern dibangun dengan asumsi “selalu online”
Server email saya sengaja memakai greylisting yang menolak email pertama kali datang. Saya sudah menerima sangat banyak email, tetapi tidak pernah ada satu pun email sah yang gagal terkirim. Pengiriman ulang sudah menjadi bagian dari standar email, jadi kalau khawatir, tinggal tambahkan server penerima cadangan dan lakukan backhaul lewat LMTP. Sistem email memang sejak awal dirancang untuk era ketika koneksi 24 jam penuh belum menjadi hal biasa
Cerita seperti ini dibesar-besarkan. Dalam kasus saya, kalau email tidak datang, biasanya beberapa jam atau sehari kemudian akan sampai juga, dan umumnya tidak ada cara untuk tahu di mana tepatnya masalah terjadi. Kalau autentikasi dilakukan dengan benar, misalnya dkim dan spf, self-hosting bisa tetap mencapai kemungkinan pengantaran di atas 99%. Tidak perlu ciut dulu karena kerumitannya. Bonusnya, caldav juga bisa dipakai secara privat
Saya penasaran kenapa orang khawatir soal “kehilangan email” hanya karena server mati beberapa jam. Server saya sudah uptime 219 hari berturut-turut. Dibanding banyak hal lain yang biasa kita kerjakan, menjalankan server email itu sebenarnya sangat mudah
Melihat sistem email zaman sekarang benar-benar terasa seperti, “apa yang kalian lakukan terhadap anakku?”
Saran untuk yang ingin mulai self-hosting email: coba dulu gunakan email self-hosting hanya untuk pendaftaran akun. Tidak perlu langsung dipakai untuk kontak pribadi. Dengan “Mail-in-a-box” https://mailinabox.email./, cukup ikuti panduan instalasinya dan dalam beberapa jam sistemnya bisa jadi dan berjalan baik. Pakai dulu 1–2 tahun, lalu saat sudah benar-benar nyaman, baru pindahkan penggunaan kontak pribadi ke sana
Saya merekomendasikan Stalwart https://github.com/stalwartlabs/stalwart. Ini layanan email lengkap dalam satu biner, jadi tidak ada dependensi dan instalasi/pembaruan jadi sangat mudah. Saya sudah mencoba banyak proyek lain, tetapi Stalwart yang paling praktis dan berjalan tanpa masalah
Saya sudah menjalankan MIAB di cloud selama bertahun-tahun. Selama reputasi IP bersih, pengiriman keluar tidak masalah, tetapi kalau email tidak sampai ke Outlook, saya menyelesaikannya dengan langsung menghubungi Microsoft postmaster. Saya merekomendasikannya karena bagus untuk belajar hal-hal seperti pengaturan DKIM/SPF/DMARC. Namun menerima email untuk pendaftaran akun benar-benar sulit. Greylisting MIAB menolak pengirim yang baru pertama kali datang dan menunggu percobaan ulang, tetapi banyak situs yang sebenarnya sah pun tidak mencoba lagi. Email verifikasi atau kode autentikasi dua faktor jadi datang sangat lama, dan juga tidak ada cara mudah untuk menonaktifkan filter spam sementara waktu
Sekarang email dari ISP, bahkan Google Gmail sekalipun, kadang juga bermasalah dalam hal penyaringan spam. Contohnya, kalau memesan melalui Shopify, email dari Shopify terus dianggap spam oleh Gmail. Sampai-sampai sulit dipahami kenapa itu terjadi, padahal DMARC, SPF, dan DKIM semuanya lolos. Mengirim dan menerima email sendiri secara teknis sebenarnya tidak terlalu sulit, dan layanan mana pun tidak akan pernah 100% sempurna. Pengguna jahat, yaitu spammer, jumlahnya begitu banyak sampai-sampai mengagumkan bahwa sistem ini masih bisa berjalan sebaik ini
DMARC, SPF, DKIM, dan semacamnya hanyalah pengaturan terkait autentikasi, bukan penentu langsung apakah sebuah email itu spam atau bukan. Ada email sampah yang diautentikasi dengan sempurna, dan ada email berharga yang tidak diautentikasi
Alasan email Shopify diklasifikasikan sebagai spam adalah karena banyak orang menandai email Shopify sebagai spam, atau ada pengguna bereputasi buruk di server email bersama yang mereka gunakan. Walau saya terus menandainya sebagai bukan spam, kalau reputasi pengirim secara keseluruhan terlalu buruk, email itu tetap tidak akan keluar dari folder spam
Saya sudah self-hosting email sekitar 20 tahun. Selama 10–15 tahun saya meneruskan semua email ke Gmail, tetapi setelah muak dengan filter spam yang bahkan menghilangkan email penting, saya mulai menjalankan imapd sendiri. Jika hal-hal seperti SPF disetel dengan benar, saya merasa self-hosting jauh lebih baik
Kebijakan filtering seperti inilah justru masalahnya. Jika Anda self-hosting atau memakai layanan email kecil, kemungkinan email Anda diblokir, terutama oleh filter ketat seperti Gmail, justru jauh lebih kecil. Google tetap bersikeras memakai kebijakan filtering yang agresif padahal banyak pelaku spam utama juga pengguna Gmail
Belakangan ini filter spam Gmail terlalu sensitif terhadap email pemasaran. Sepuluh tahun lalu masalahnya kebalikannya, tetapi sekarang terlalu banyak yang masuk folder spam sampai menyebalkan. Justru sebagian besar spam saat ini adalah cold email dari alamat email kecil yang baru. Untuk email pemasaran, fitur “unsubscribe” Gmail bekerja dengan baik, tetapi untuk cold email seperti itu tidak banyak gunanya
Jika ingin setup yang lengkap dan server IMAP yang bisa terhubung dengan berbagai klien, panduan https://workaround.org/ispmail-bookworm/ lebih cocok. Saya sendiri menjalankannya secara sederhana memakai file teks biasa alih-alih database. Kalau penggunanya hanya saya, cara seperti ini sudah cukup, dan panduan itu sendiri cukup bisa diskalakan bahkan untuk perusahaan besar
Promosi langsung: kami sedang beta test Hyvor Relay https://github.com/hyvor/relay, alternatif self-hosting yang kami bangun. Fokusnya pada visibilitas seperti pemantauan DKIM/SPF dan otomatisasi DNS. Cukup satu kali
docker compose updan langsung bisa dijalankan https://relay.hyvor.com/hosting/deploy-easySelama 10–15 tahun saya self-hosting email dengan opensmtp, dovecot, dan rspamd di box kimsufi murah. Tidak ada masalah besar; hanya pernah sekali server saya diblokir oleh telekom.de, tetapi setelah saya menjelaskan lewat email resmi, mereka langsung memasukkannya ke whitelist. Mungkin karena saya sudah lama memakai IP yang sama, saya pribadi tidak merasakan masalah-masalah yang sering diceritakan orang. Namun server dan IP itu memang milik saya sendiri atas nama saya
Saya membagikan tulisan berbahasa Jerman tentang self-hosting email berbasis Debian trixie di https://krei.se/Doc. Kalau dibangun dengan benar, self-hosting itu benar-benar menyenangkan. Saya menerima laporan status harian lewat email berkat pembaruan otomatis, reboot otomatis, dan systemd yang disesuaikan. Selama 2–3 tahun, atau sampai 5 tahun kalau memakai trixie, sistemnya stabil dan nyaris tak perlu disentuh. Perangkat lunak server email sudah cukup matang. Saya merekomendasikan self-hosting. Otonomi, ketenangan, dan kontrol langsung itu sangat berharga
Saya sudah menjalankan email sendiri lebih dari 10 tahun, dan kadang meninggalkan tautan ke komentar HN lama saya juga, misalnya 39891262, 38471262. Karena IP Digital Ocean saya ditandai buruk, saya mengganti pengiriman keluar dengan Amazon SES, dan memakai Gmail sebagai pelatih spam gratis untuk filter saya sendiri (38843288). Seperti yang banyak disebut orang, greylisting sangat membantu. Server email yang sah pasti akan mencoba lagi, jadi memang merepotkan untuk hal seperti 2FA, tetapi secara sistem ini cukup bisa dipercaya. Downtime beberapa hari pun tidak jadi masalah, dan server penerima/penyimpanan bisa dipisah sehingga backup juga lebih mudah (38512732). Untuk email 2FA saya juga memakai https://github.com/stevejenkins/postwhite, tetapi sejujurnya saya tidak ingin merekomendasikan email untuk keperluan 2FA sama sekali, meski itu topik diskusi terpisah
Baru-baru ini saya gagal menerima email penting yang dikirim lewat Amazon SES karena daftar blokir spam (bl.spamcop.net). Amazon mencoba ulang lewat beberapa IP, lalu bertemu greylisting, dan akhirnya salah satunya benar-benar ditolak. Untuk pengiriman antar penyedia besar, dari MX ke MX, mungkin ini bukan masalah besar, tetapi struktur seperti ini pun bukan solusi yang 100% sempurna
Kalau pada akhirnya dibahas panjang lebar, kesimpulannya tetap terasa seperti: lebih baik pakai layanan email besar seperti Gmail saja
Di mana UUCP, kenapa alamatnya bukan bang path, dan ke mana sendmail.cf?
Betul. Kalau mau self-hosting gaya 1984, email klasik, Anda akan berakhir dengan open relay yang meneruskan semua email, dan sangat berisiko karena terbuka pada berbagai kerentanan
Ngomong-ngomong soal masa itu, saya punya kenangan di lab universitas dengan 6 workstation Unix, saat email berpindah dari satu server ke server lain dan saya bisa merasakan lalu lintas email dari suara disk yang bekerja
Saya juga langsung teringat bang path dan alamat “killer!jolet!” saat membaca judulnya. Zaman yang benar-benar dirindukan
Setuju. Saya datang karena terpancing judul ‘1984’, tetapi ternyata isinya cuma soal ‘konfigurasi postfix’, jadi agak kecewa