Rutin Cek Frozen Message di Queue Exim Sebelum Menumpuk Jadi Tiket

Pelanggan bilang emailnya tidak sampai, atau monitoring mulai mengeluh soal partisi /var yang makin penuh. Begitu queue Exim dibuka, isinya banyak pesan berlabel *** frozen ***. Refleks yang paling sering muncul adalah menghapus semuanya supaya queue bersih. Kadang langkah itu aman. Kadang langkah itu justru menghapus satu-satunya petunjuk bahwa ada router yang salah konfigurasi atau akun yang sedang dipakai kirim spam. Artikel ini membahas cara membaca pesan frozen satu per satu, dari gejala sampai akar masalah, sebelum kita memutuskan mana yang boleh dibuang.

Frozen bukan sekadar email yang tertunda

Pesan berstatus deferred masih punya jadwal. Exim akan mencobanya lagi sesuai aturan retry, dan topik ini sudah dibahas di Email Tertahan di Queue Exim dengan Pesan retry time not reached, Apa Artinya?. Pesan frozen berbeda. Exim sengaja berhenti mencoba mengirimnya. Pesan itu akan diam di spool sampai ada yang men-thaw (mencairkan) secara manual, menghapusnya, atau sampai batas waktu yang diatur di konfigurasi terlewati. Ada beberapa penyebab umum sebuah pesan dibekukan:

Bounce (pesan pemberitahuan gagal kirim) yang ternyata juga gagal dikirim balik ke pengirim aslinya. Ini penyebab yang paling sering.
Router menemukan bahwa tujuan pengiriman ternyata server itu sendiri, padahal domainnya tidak terdaftar sebagai domain lokal. Opsi router self di Exim secara default bernilai freeze.
System filter atau admin yang sengaja membekukan pesan.

Berapa lama pesan frozen bertahan diatur oleh dua opsi. ignore_bounce_errors_after mengatur bounce frozen, dan timeout_frozen_after mengatur semua pesan frozen. Kalau timeout_frozen_after bernilai 0, pesan frozen biasa tidak pernah dibuang otomatis. Kondisi inilah yang membuat queue bisa menumpuk diam-diam selama berminggu-minggu. Nilai yang aktif di server kamu bisa dicek dengan exim -bP diikuti nama opsinya. Kalau server memakai control panel, cari tahu dulu apakah opsi ini diatur lewat panel, karena perubahan manual di file konfigurasi biasanya tertimpa saat panel membuat ulang config.

Hitung dulu, lalu lihat polanya

Sebelum membuka pesan satu per satu, kita perlu gambaran besarnya. Berapa banyak pesan frozen, dan ke domain mana saja tujuannya. Semua perintah di bawah hanya membaca, jadi aman dijalankan.

BASH

# total pesan di queue (frozen maupun tidak)
exim -bpc

# hanya ID pesan yang frozen
exiqgrep -z -i

# jumlah pesan frozen
exiqgrep -z -i | wc -l

# ringkasan pesan frozen per domain tujuan
exiqgrep -z | exiqsumm

Perhatikan polanya. Kalau mayoritas pesan frozen menuju banyak domain acak di luar server, kemungkinan besar isinya bounce yang tidak bisa dikembalikan. Kalau tujuannya menumpuk di satu domain, terutama domain yang di-host di server yang sama, itu sinyal ke arah konfigurasi routing. Kalau jumlahnya naik cepat dalam waktu singkat, curigai ada akun atau script yang sedang mengirim massal. Satu catatan: di queue yang sangat besar, exim -bp dan turunannya bisa lambat karena harus membaca setiap file di spool. Ini wajar, jadi jangan buru-buru membatalkannya.

Membaca satu pesan lewat header spool dan log

Ambil beberapa ID dari daftar tadi sebagai sampel, idealnya dari pola yang berbeda. Ada tiga sumber informasi untuk setiap pesan: header spool, message log khusus pesan itu, dan mainlog.

BASH

# header spool: envelope sender, penerima, flag internal, header email
exim -Mvh ID_PESAN

# message log: riwayat percobaan kirim untuk pesan ini saja
exim -Mvl ID_PESAN

# semua baris mainlog yang berkaitan dengan pesan ini
# (path umum di cPanel/RHEL; di Debian/Ubuntu biasanya /var/log/exim4/mainlog)
exigrep 'ID_PESAN' /var/log/exim_mainlog

Di output -Mvh, bagian awal berisi data envelope dan flag yang tidak terlihat di header email biasa. Beberapa yang paling berguna:

Envelope sender. Kalau isinya <> (kosong), pesan itu adalah bounce yang dibuat oleh server.
Baris -frozen diikuti angka. Angka itu adalah timestamp kapan pesan dibekukan.
Baris -auth_id, kalau ada. Ini akun yang login SMTP saat mengirim pesan. Sangat berguna untuk melacak siapa pengirim sebenarnya.
Baris -host_address, yaitu IP asal koneksi.

Setelah itu ada daftar penerima dan header seperti Subject dan From. Header spool menjawab pertanyaan siapa dan ke mana. Alasan pesan dibekukan biasanya ada di -Mvl atau mainlog, di baris sesaat sebelum pesan berubah status. Untuk bounce yang gagal, biasanya ada keterangan seperti Frozen (delivery error message) setelah server tujuan menolak. Untuk masalah routing, cari pesan error dari router, misalnya keterangan bahwa MX record terendah mengarah ke host lokal. Isi body (exim -Mvb) sebaiknya dibuka hanya kalau benar-benar perlu, karena bisa berisi data pribadi pelanggan. Untuk bounce, body memang sering diperlukan karena memuat potongan pesan asli yang gagal.

Yang biasanya aman dihapus

Pola yang paling umum adalah bounce frozen dengan ciri berikut: envelope sender <>, penerima berupa alamat eksternal yang tidak dikenal, dan log yang menunjukkan server tujuan menolak dengan alasan alamat tidak ada atau domain tidak bisa di-resolve. Pesan seperti ini tidak akan pernah sampai. Menyimpannya hanya memakan ruang dan inode di spool. Meski aman dihapus, tetap tanyakan kenapa bounce itu dibuat sejak awal. Kalau penerima bounce adalah alamat acak yang jelas palsu, server mungkin menerima spam lalu memantulkannya balik ke alamat pengirim yang dipalsukan. Pola ini sering muncul dari forwarder, autoresponder, atau catch-all yang menerima dulu lalu menolak belakangan. Menghapus bounce-nya membersihkan gejala, tapi sumbernya akan terus mengisi queue kalau tidak dibereskan.

Yang menandakan masalah konfigurasi atau keamanan

Ada tiga pola yang sebaiknya tidak langsung dihapus. Pola pertama: pesan frozen dengan pengirim normal (bukan <>) menuju domain yang di-host di server sendiri, dengan log yang menyebut MX mengarah ke host lokal. Biasanya domain itu MX-nya memang ke server ini, tapi Exim tidak menganggapnya sebagai domain lokal. Router lalu melihat dirinya sendiri sebagai tujuan, dan karena opsi self bernilai freeze, pesan dibekukan. Penyebab umumnya domain baru dipindah atau ditambahkan tapi belum masuk daftar domain lokal. Di server cPanel, daftar ini biasanya dikelola lewat file seperti /etc/localdomains dan /etc/remotedomains. Ubah lewat panel sebisa mungkin. Setelah diperbaiki, pesan-pesan ini sah dan sebaiknya dikirim ulang, bukan dihapus. Pola kedua: banyak bounce frozen yang pesan aslinya berasal dari satu akun lokal. Lihat -auth_id di header spool dan potongan pesan asli di body. Kalau isinya spam dari akun yang sama, kemungkinan password akun itu bocor atau ada script di situs yang disalahgunakan. Bounce frozen di sini adalah bukti. Catat ID, auth_id, dan IP asal dulu, amankan akunnya, baru bersihkan queue. Kalau perlu eskalasi, informasi ini yang dibutuhkan tim berikutnya. Daftar lengkapnya ada di Memilih Info Apa yang Wajib Ada Sebelum Eskalasi Tiket ke Tim Engineering. Pola ketiga: pesan frozen tanpa error pengiriman sama sekali di log. Ini biasanya dibekukan oleh system filter atau admin lain. Cek system filter yang aktif sebelum mengambil tindakan apa pun, karena mungkin memang ada aturan yang sengaja menahan pesan tertentu.

Membersihkan dengan aman lalu memverifikasi

Peringatan: exim -Mrm menghapus pesan secara permanen dan tidak bisa dikembalikan. Selalu tinjau daftarnya dulu tanpa -i dan tanpa pipe, pastikan isinya benar-benar bounce yang dimaksud, baru jalankan penghapusan.

BASH

# 1) tinjau dulu: bounce frozen (sender kosong)
exiqgrep -z -f '^<>$'

# 2) kalau daftar sudah benar, hapus hanya bounce frozen tersebut
exiqgrep -z -i -f '^<>$' | xargs -r exim -Mrm

# 3) untuk pesan sah setelah penyebabnya diperbaiki:
#    thaw, lalu paksa coba kirim
exim -Mt ID_PESAN
exim -M ID_PESAN

Pencocokan sender di exiqgrep bisa berbeda tergantung versi. Karena itu, langkah pertama tidak boleh dilewati. Kalau hasilnya kosong padahal kamu yakin ada bounce frozen, cek format sender di output exim -bp dan sesuaikan polanya. Untuk pesan yang dibekukan karena masalah routing, jangan thaw dulu sebelum konfigurasinya benar. Pesan itu hanya akan dibekukan lagi. Setelah perbaikan, kirim satu pesan dengan exim -M, lalu pantau hasilnya di mainlog. Kalau sukses, baru proses sisanya. Verifikasinya sederhana. Hitung ulang pesan frozen dengan perintah di bagian awal, cek ruang dan inode di direktori spool (lokasinya tergantung distro, biasanya di bawah /var/spool/), lalu pantau mainlog beberapa saat untuk melihat apakah muncul pesan frozen baru dengan pola yang sama. Kalau angkanya naik lagi, berarti sumbernya belum tertutup. Praktisnya, jadikan pengecekan jumlah pesan frozen bagian dari rutinitas harian atau pasang alert sederhana kalau jumlahnya melewati ambang yang wajar untuk server kamu. Saat angkanya naik, ambil beberapa sampel, baca -Mvh dan log-nya, lalu tentukan polanya: bounce tak terkirim yang boleh dibuang, routing yang salah konfigurasi, atau akun yang disalahgunakan. Lima menit membaca sampel biasanya jauh lebih murah daripada menghapus semua bukti lalu menunggu keluhan berikutnya masuk.