Tips & Share : MTA/SMTP Server untuk Broadcast Email Massal

Beberapa pekerjaan project di Excellent di bulan Desember adalah melakukan migrasi sistem mail server dengan jumlah user rata-rata > 1000 user. Sebagian diantaranya merupakan perusahaan besar yang membutuhkan akses email server yang handal namun dengan biaya yang relatif lebih rendah; baik biaya instalasi, implementasi, support maupun lisensinya.

Salah satu feature major yang diinginkan adalah kemampuan sistem mail server dalam menangani pengiriman email dalam jumlah massal sekaligus handal dalam menangani trafik dan akses email dengan jumlah account yang cukup banyak.

Secara prinsip, berikut adalah beberapa tips yang saya pergunakan untuk melakukan implementasi mail server dalam formasi large deployment :

1. Menggunakan Zimbra Mail Server dalam skema multi server. Zimbra mail server handal, modular dan mampu menangani ratusan ribu hingga jutaan transaksi email per hari dan mudah diextend kemampuannya secara online (tidak perlu melakukan restart service) serta tersedia skema free-open source maupun versi Network Edition dengan feature yang lebih banyak
2. Memisahkan antara LDAP, Mailbox dan MTA server sesuai dengan skema multi server. Dengan cara ini, MTA Server dapat berfungsi dengan baik tanpa dibebani oleh konfigurasi dan service LDAP maupun Mailbox (webmail, POP3 dan IMAP). MTA server juga bisa bersifat independen, restart service atau gangguan pada mailbox server tidak akan berimplikasi pada MTA Server. Saya juga memisahkan MTA server untuk penerimaan dengan MTA server untuk pengiriman email serta memisahkan MTA server untuk private (internal) dengan MTA server eksternal.
3. Memisahkan MTA Server dengan anti spam dan anti virus. Untuk MTA Server yang dipergunakan untuk broadcast email keluar dan hanya digunakan oleh aplikasi/IP tertentu, saya tidak memerlukan anti spam dan anti virus. Tentu ini ada syaratnya, yaitu pengirimnya benar-benar trusted (hanya IP tertentu yang dijamin bisa mengirimkan queue). Saya juga mendisable seluruh akses public termasuk port 25 incoming karena yang saya perlukan hanya port 25 outgoing. Biasanya, sebagian besar sumber daya sistem MTA Server sebagian besar digunakan untuk  menjalankan Amavis anti spam dan anti virus. Jika dinonaktifkan, tugas MTA Server hanya 1 yaitu mengirim email ke tujuan secepat mungkin
4. Menggunakan harddisk minimal, biasanya ukuran harddisk yang digunakan sekitar 15-25 GB karena hanya dijadikan sebagai penampung queue saja. Jumlah kapasitas yang disediakan bisa diperhitungkan dari maksimal jumlah queue dan jumlah attachment tiap queue. Artinya jika ada 10 ribu queue dengan masing-masing attachment sebesar 2 MB maka akan diperlukan sekitar 20 GB kapasitas disk, in case ke 10 ribu queue email tersebut “nyangkut” di antrian
5. Tidak menggunakan RAID. Atas pertimbangan kecepatan dan kemudahan replacement, saya tidak menggunakan RAID khusus untuk harddisk yang dipergunakan untuk MTA Server. Resikonya adalah, jika sampai terjadi crash, queue tidak bisa direcover. Dari sisi sistem sendiri, proses replacement termasuk mudah karena tidak perlu menyalin data mailbox
6. Menggunakan Virtualization Technology. Atas pertimbangan kemudahan deployment dan replacement, saya melakukan instalasi MTA Server diatas VMWare vSphere atau Proxmox. Andai kata terjadi crash pada harddisk, saya cukup mereplace dengan pre-configured MTA Server yang merupakan salinan sistem yang sedang berjalan
7. Instalasi diatas harddisk SSD dan processor multi core. Agar bisa responsif dalam menangani antrian email, saya lebih merekomendasikan  penggunaan harddisk SSD dengan processor quad core. Harddisk SSD lebih cepat dalam melakukan proses baca dan tulis (meski saat ini cukup mahal untuk ukuran harddisk yang tidak terlalu besar). Core yang banyak akan menyediakan thread yang lebih banyak dalam menangani antrian diwaktu bersamaan
8. Menggunakan beberapa MTA Server. Jika email yang harus dikirim jumlahnya sangat banyak, saya biasanya membuat beberapa MTA Server yang akan melakukan load balancing diantara MTA server yang ada. Jika salah satu MTA Server overload dan tidak menerima proses incoming queue, MTA Server lain akan bisa melayani antrian email yang tersisa. Cara termudah membuat multiple MTA Server adalah dengan membuatkan A records yang sama di DNS Server internal (misalnya nama : smtp.excellent.co.id) yang merujuk ke beberapa IP private yang digunakan oleh MTA Server
9. Kapasitas bandwidth dedicated. MTA server sepowerful apapun tidak akan berfungsi dengan baik jika kapasitas bandwidth yang disediakan tidak mencukupi. Saya lebih cenderung untuk menggunakan bandwidth dedicated khusus untuk MTA Server agar pengiriman email keluar domain tidak mengalami delay
10. Check queue secara periodik. Biasanya email broadcast itu mengalami kendala deferred (penundaan) jika terjadi salah ketik alamat email tujuan atau email tujuan over kuota atau email server tujuan tidak merespon komunikasi SMTP. Agar tidak berulangkali diretry queue, saya mengeset agar MTA server langsung mengeluarkan mailer daemon khusus untuk over kuota (sehingga tidak akan ada proses retry queue), menghapus queue salah alamat serta mengurangi waktu tunggu pengiriman email dari default 5 hari menjadi maksimal 1 hari

Salah satu kendala mendasar pengiriman email secara massal adalah adanya beberapa policy dari penerima yang menyebabkan pengiriman email tertunda. Yahoo misalnya, kerapkali merespon dengan “timed out while sending message body” saat kita mengirimkan email ke tujuan Yahoo dengan attachment yang cukup besar. Hal ini biasanya terjadi karena 2 hal :

1. Bandwidth tidak cukup besar sehingga pengiriman keburu terputus saat email belum selesai dikirimkan atau
2. Waktu untuk queue terlalu cepat. Postfix misalnya, secara default hanya memberikan waktu 180s atau 3 menit untuk mengirim 1 email queue ke tujuan. Jika waktu ini terlewati, email akan dipindahkan jadi deferred dan akan diulang kirim dalam proses requeue berikutnya

Kendala lain yang perlu dicegah adalah kemungkinan adanya blacklist terhadap IP public yang kita gunakan untuk mengirim email. Agar tetap eligible, keamanan sistem perlu diperhatikan, terutama untuk mencegah terjadinya kebocoran pengiriman email dari sisi internal kita.

Ada tips lain? Silakan ditambahkan.