Tag: postfix

Mengatasi Error 451 4.3.0 Temporary lookup failure di Carbonio
Beberapa waktu lalu, saya menemukan satu hal setelah melakukan upgrade in-place pada server Carbonio. Pengiriman email lokal (local delivery) gagal dan log Postfix menunjukkan error 451 4.3.0 Temporary lookup failure yang sekilas terlihat seperti masalah LDAP atau DNS.

Awalnya saya juga mengira penyebabnya adalah layanan LDAP yang tidak berjalan atau DNS lokal bermasalah. Namun setelah melakukan pengecekan lebih dalam, ternyata penyebabnya sama sekali berbeda. Masalah terjadi karena Postfix tidak memiliki izin membaca file konfigurasi LDAP yang digunakan untuk melakukan lookup account dan domain.

Panduan ini membahas langkah-langkah troubleshooting hingga menemukan akar penyebabnya.

Kendala

Saat mengirim email muncul log seperti berikut.
```
postfix/proxymap: warning: ldap:/opt/zextras/conf/ldap-transport.cf is unavailable.
open /opt/zextras/conf/ldap-transport.cf: Permission denied

postfix/trivial-rewrite: warning:
virtual_alias_domains lookup failure

451 4.3.0 Temporary lookup failure
```
Karena Postfix gagal melakukan lookup ke LDAP, proses penerimaan email langsung ditolak. Ternyata permission ditolak pada file /opt/zextras/conf/ldap-transport.cf untuk user group postfix.

Analisis Awal

Awalnya saya melakukan beberapa pengecekan berikut.

Memastikan service LDAP berjalan
```
su - zextras
systemctl list-units -all carbonio-*
```
Semua service berjalan normal.

Memastikan DNS berjalan

Saya juga mengecek dnsmasq.
```
systemctl status dnsmasq
```
Memeriksa permission file LDAP

Saya mengecek seluruh file konfigurasi LDAP yang digunakan Postfix.
```
ls -l /opt/zextras/conf/ldap-*.cf
```
Hasilnya:
```
-rw-r----- 1 zextras zextras ldap-transport.cf
-rw-r----- 1 zextras zextras ldap-vad.cf
-rw-r----- 1 zextras zextras ldap-vmd.cf
```
Sekilas permission tersebut terlihat normal.

Namun saya mencoba membaca file menggunakan user Postfix.
```
su -s /bin/bash postfix
```
Kemudian:
```
cat /opt/zextras/conf/ldap-transport.cf
```
Hasilnya:
```
Permission denied
```
Di sinilah penyebab utama mulai terlihat.

Mengapa Bisa Terjadi?

Service SMTP dijalankan oleh user postfix.
```
ps -ef | grep smtpd
```
Output:
```
postfix .... smtpd
```
Sementara file konfigurasi LDAP dimiliki oleh:
```
Owner : zextras
Group : zextras
Permission : 640
```
Artinya hanya:
- owner (zextras)
- group (zextras)
yang dapat membaca file tersebut.

Karena user postfix bukan anggota group zextras, maka Postfix tidak dapat membaca file konfigurasi LDAP.

Akibatnya seluruh proses lookup gagal.
```
Postfix
      │
      ▼
ldap-transport.cf
      │
Permission denied
      │
      ▼
LDAP lookup gagal
      │
      ▼
451 Temporary lookup failure
```
Membandingkan Dengan Server Carbonio yang Normal

Saya kemudian membandingkan dengan server Carbonio lain yang berjalan normal.

Server yang sehat memiliki permission berikut.
```
-rw-r----- 1 zextras postfix ldap-transport.cf
```
Perbedaannya hanya pada group ownership.

Server Owner Group
Server error zextras zextras
Server normal zextras postfix

Karena group sudah menggunakan postfix, service SMTP dapat membaca file tanpa perlu memberikan permission ke user lain.

Solusi

Saya mengubah group ownership seluruh file LDAP menjadi postfix.
```
chown zextras:postfix /opt/zextras/conf/ldap-*.cf
chmod 640 /opt/zextras/conf/ldap-*.cf
```
Kemudian restart layanan MTA.
```
systemctl restart carbonio-mta.target
```
Setelah itu saya kembali mencoba membaca file menggunakan user postfix.
```
su -s /bin/bash postfix

cat /opt/zextras/conf/ldap-transport.cf
```
File sudah dapat dibaca tanpa error.

Penyebab Permission Berubah

Sampai artikel ini ditulis saya belum tau penyebab pastinya. Namun ada beberapa kemungkinan:
- Upgrade Carbonio mengubah ownership file.
- Script maintenance atau proses regenerasi konfigurasi membuat ulang file LDAP.
- Restore konfigurasi dari backup dengan ownership berbeda.
- Perubahan manual menggunakan chown.
Tips Sebelum Mengubah Permission

Saya tidak menyarankan menggunakan:
```
chmod 644 /opt/zextras/conf/ldap-*.cf
```
karena file tersebut berisi informasi autentikasi LDAP seperti:
```
bind_dn
bind_pw
```
Memberikan permission 644 berarti seluruh user lokal pada server dapat membaca credential LDAP.

Solusi yang lebih aman adalah tetap menggunakan permission 640, namun memastikan group ownership sesuai dengan yang dibutuhkan oleh Postfix.

Penutup

Error 451 Temporary lookup failure tidak selalu berarti LDAP atau DNS sedang bermasalah. Pada kasus ini penyebab sebenarnya adalah Postfix tidak dapat membaca file konfigurasi LDAP akibat perubahan group ownership.

Jika menemukan log seperti:
```
open /opt/zextras/conf/ldap-transport.cf: Permission denied
```
Periksa ownership dan permission file konfigurasi LDAP dan pastikan ownership dan permission sesuai. Perubahan kecil pada group ownership dapat menyebabkan seluruh proses lookup gagal dan membuat layanan email tidak dapat berfungsi sebagaimana mestinya.
July 28, 2026

Server	Owner	Group
Server error	zextras	zextras
Server normal	zextras	postfix

Simulasi Error SMTP 451 Temporary Lookup Failure dengan Postfix

Error 451 Temporary lookup failure sering muncul di lingkungan produksi dan bikin email nyangkut di antrian dengan status deferred. Supaya paham perilakunya tanpa mengganggu server klien, saya buat lab kecil berisi dua VM Postfix, satu sebagai pengirim dan satu sebagai penerima. Panduan ini mencakup instalasi, pengujian normal, simulasi error 451, lalu pemulihan ke kondisi normal.

Informasi lab

Peran	Hostname	IP	OS
Pengirim	sender.lab	192.168.14.22	Ubuntu 24.04
Penerima	receiver.lab	192.168.14.23	Ubuntu 24.04

Prasyarat: akses root di kedua VM, koneksi internet untuk instalasi paket, dan kedua VM berada di segmen jaringan yang sama.

1. Persiapan

Tambahkan entri berikut di /etc/hosts pada kedua server:

192.168.14.22 sender.lab
192.168.14.23 receiver.lab

Set hostname sesuai perannya:

hostnamectl set-hostname sender.lab

Pastikan saling terjangkau:

ping -c 3 receiver.lab

2. Instalasi Postfix

Jalankan di kedua server:

apt update
apt install postfix mailutils -y

Saat wizard muncul, pilih Internet Site, lalu isi System mail name dengan sender.lab atau receiver.lab sesuai server.

Cek status service:

systemctl status postfix

Status harus active (running).

3. Konfigurasi server penerima

Edit /etc/postfix/main.cf di receiver, pastikan baris berikut ada:

myhostname = receiver.lab
mydestination = receiver.lab, localhost.lab, localhost
inet_interfaces = all
mynetworks = 127.0.0.0/8, 192.168.14.0/24

Buat akun lokal sebagai tujuan email:

adduser user
systemctl restart postfix

Verifikasi Postfix listen di port 25:

ss -tlnp | grep :25

Output:

4. Konfigurasi server pengirim

Secara default Postfix mencari tujuan lewat DNS (smtp_host_lookup = dns), jadi entri /etc/hosts saja tidak cukup. Karena di lab ini tidak ada DNS internal, arahkan langsung ke IP receiver. Edit /etc/postfix/main.cf di sender:

myhostname = sender.lab
relayhost = [192.168.50.20]

Tanda kurung siku [ ] membuat Postfix melewati pencarian MX dan langsung konek ke IP tersebut. Lalu reload:

systemctl reload postfix

Uji koneksi SMTP dari sender:

telnet receiver.lab 25

Harus muncul banner seperti 220 receiver.lab ESMTP Postfix. Keluar dengan mengetik quit.

5. Uji pengiriman normal

Kirim email percobaan dari sender:

echo "Test kondisi normal" | mail -s "SMTP Test" user@receiver.lab

Pantau log di sender:

tail -f /var/log/mail.log

Output yang benar:

2026-07-24T07:37:35.394338+00:00 sender postfix/smtp[27206]: 4DD982C6: to=<user@receiver.lab>, relay=192.168.14.23[192.168.14.23]:25, delay=0.09, delays=0.02/0.02/0.03/0.01, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 5A88D6AF79)

Ini jadi baseline sebelum kita rusak sengaja.

6. Simulasi error 451

Di server penerima, tambahkan restriction berikut di /etc/postfix/main.cf:

smtpd_recipient_restrictions =
    check_recipient_access hash:/etc/postfix/recipient_access,
    permit_mynetworks,
    reject_unauth_destination

Buat file /etc/postfix/recipient_access dengan isi:

user@receiver.lab 451 4.3.0 Temporary lookup failure

Format 4NN text di access table membuat Postfix membalas dengan kode dan pesan tersebut. Kode 4.3.0 ditulis eksplisit supaya DSN di sisi pengirim sama persis dengan kasus produksi. Generate database lalu reload:

postmap /etc/postfix/recipient_access
systemctl reload postfix

Catatan: jika postmap gagal karena tipe hash tidak tersedia, cek dengan postconf -m dan ganti ke lmdb.

7. Uji ulang dan baca log

Kirim lagi dari sender:

echo "Test 451" | mail -s "451 test" user@receiver.lab

Log di sender akan berbunyi:

2026-07-24T07:53:18.718740+00:00 sender postfix/smtp[27250]: 9CED3332: to=<user@receiver.lab>, relay=192.168.14.23[192.168.14.23]:25, delay=0.09, delays=0.03/0.01/0.03/0.01, dsn=4.3.0, status=deferred (host 192.168.14.23[192.168.14.23] said: 451 4.3.0 <user@receiver.lab>: Recipient address rejected: Temporary lookup failure (in reply to RCPT TO command))

Cek antrian:

postqueue -p

Output

Email tetap tertahan dan akan dicoba ulang sesuai maximal_queue_lifetime (default 5 hari). Ini yang membedakan error 4xx dari 5xx.

8. Kembalikan ke kondisi normal

Kosongkan file access lalu regenerate:

: > /etc/postfix/recipient_access
postmap /etc/postfix/recipient_access
systemctl reload postfix

Paksa antrian jalan lagi:

postqueue -f

Log akan berubah menjadi dsn=2.0.0, status=sent dengan balasan 250 2.0.0 Ok.

2026-07-24T07:56:01.180149+00:00 sender postfix/qmgr[27194]: 9CED3332: from=<root@sender.lab>, size=317, nrcpt=1 (queue active)
2026-07-24T07:56:01.258620+00:00 sender postfix/smtp[27271]: 9CED3332: to=<user@receiver.lab>, relay=192.168.14.23[192.168.14.23]:25, delay=163, delays=163/0.03/0.04/0.01, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 314AD6AF79)
2026-07-24T07:56:01.258793+00:00 sender postfix/qmgr[27194]: 9CED3332: removed

Ringkasan

Skenario	Balasan SMTP	Status di antrian
Server penerima normal	250 2.0.0 Ok	sent
Gangguan sementara di penerima	451 4.3.0 Temporary lookup failure	deferred, retry otomatis
Alamat ditolak permanen	550 5.x.x	bounced, tidak retry

Troubleshoot

Gejala	Penyebab	Solusi
`Host or domain name not found`	Sender masih pakai lookup DNS	Set `relayhost = [IP_RECEIVER]` atau `smtp_host_lookup = native, dns`
`Connection refused` port 25	`inet_interfaces = loopback-only` atau firewall	Set `inet_interfaces = all`, buka port 25
`Relay access denied`	Domain tujuan tidak ada di `mydestination`	Tambahkan `receiver.lab` ke `mydestination`
`554 Too many hops`	Mail loop antar server	Periksa `relayhost`, `mydestination`, dan `transport_maps`
`/var/log/mail.log` kosong	rsyslog tidak terpasang	Gunakan `journalctl -u postfix -f`

Lab ini cukup ringan tapi mencakup pola error yang paling sering ditemui saat troubleshooting Postfix, Zimbra, Carbonio, maupun SMTP relay. Semoga bermanfaat.

Referensi

July 24, 2026

Install dan Konfigurasi Postfix di Rocky 9
Pada panduan ini saya akan membahas instalasi Postfix di Rocky Linux 9 dari kondisi fresh install. Targetnya dua, pertama Postfix bisa kirim email antar user lokal, dan lalu ditingkatkan supaya bisa mengirim ke alamat Gmail menggunakan relay smtp.gmail.com. Namun untuk hari ini hanya sampai di antar user lokal saja. Semua perintah dijalankan sebagai root.

Informasi Lab

Item Nilai
OS Rocky Linux 9
Hostname mail.rafi.lab
Domain rafi.lab
IP Address 192.168.14.4/24
Kebutuhan Akses root, internet

Sesuaikan hostname dan domain dengan lingkungan kalian.

1. Persiapan Server

Set hostname dan tambahkan mapping di /etc/hosts:
```
hostnamectl set-hostname mail.rafi.lab
echo "192.168.14.4 mail.rafi.lab mail" >> /etc/hosts
```
Update sistem:
```
dnf update -y
```
(Opsional) Buka port SMTP di firewalld supaya klien lain di jaringan lokal bisa mengirim lewat server ini:
```
firewall-cmd --add-service=smtp --permanent
firewall-cmd --reload
```
SELinux biarkan enforcing, Postfix dengan konfigurasi standar tidak bermasalah.

2. Instalasi Postfix

Install Postfix beserta s-nail (pengganti mailx di Rocky 9, menyediakan perintah mail untuk pengujian) dan telnet:
```
dnf install postfix s-nail telnet -y
systemctl enable --now postfix
```
Verifikasi:
```
systemctl status postfix
postconf mail_version
```
Status service harus active(running).

3. Konfigurasi Dasar Postfix

Ubah parameter utama di /etc/postfix/main.cf. Cara paling aman menggunakan postconf:
```
postconf -e 'myhostname = mail.rafi.lab'
postconf -e 'mydomain = rafi.lab'
postconf -e 'myorigin = $mydomain'
postconf -e 'inet_interfaces = all'
postconf -e 'inet_protocols = ipv4'
postconf -e 'mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain'
postconf -e 'mynetworks = 127.0.0.0/8, 192.168.14.0/24'
postconf -e 'home_mailbox = Maildir/'
```
Penjelasan singkat:
- inet_interfaces = all membuat Postfix listen di semua interface, bukan hanya localhost
- mydestination menentukan domain yang diterima sebagai tujuan lokal
- mynetworks menentukan subnet yang boleh relay lewat server ini
- home_mailbox = Maildir/ menyimpan email di direktori ~/Maildir tiap user
Cek sintaks lalu restart:
```
postfix check
systemctl restart postfix
```
postfix check tidak menampilkan output apa pun jika konfigurasi benar.

4. Uji Kirim Sesama User Lokal

Buat dua user untuk pengujian:
```
useradd budi
useradd andi
```
Kirim email dari budi ke andi:
```
su - budi -c 'echo "Halo Andi, ini tes email lokal" | mail -s "Tes Lokal" andi@rafi.lab'
```
Cek email masuk di Maildir milik andi:
```
ls /home/andi/Maildir/new/
cat /home/andi/Maildir/new/*
```
Cek log pengiriman:
```
tail /var/log/maillog
```
Opsional, kalian juga bisa tes lewat sesi SMTP manual:
```
telnet 192.168.14.4 25
```
Lalu ketik perintah SMTP berikut satu per satu (enter):
```
ehlo rafi.lab
mail from: budi@rafi.lab
rcpt to: andi@rafi.lab
data
Subject: Tes via telnet

Halo, ini tes lewat telnet
.
quit
```
Sampai tahap ini Postfix sudah berfungsi untuk pengiriman antar user lokal.
July 17, 2026
Troubleshoot Zimbra Level 1: MTA yang Berhenti
Tulisan saya kali ini yaitu, catatan satu ronde latihan drill troubleshooting di lab Zimbra. Aturannya saya susun sendiri bersama Claude Code, Claude yang menyuntikkan fault ke server lab tanpa memberi tahu apa yang dirusak, saya yang mendiagnosis dan memperbaiki. Level 1 ini pemanasan, satu masalah dengan error yang seharusnya cukup terang kalau saya cek di tempat yang benar. Ada baiknya baca dulu Latihan Troubleshooting dengan Claude Code di tulisan saya sebelumnya agar paham konsep dan aturan main drill-nya.

Tiket

Sesi dimulai seperti biasa, saya pilih platform Zimbra dan level 1, Claude memastikan SSH ke node lab jalan dan snapshot sudah ada, lalu menyuntikkan fault-nya secara diam-diam. Yang saya terima cuma ini:

Tiket: «User lapor email keluar dan masuk berhenti total sejak beberapa menit lalu. Webmail masih bisa login, tapi kirim email nyangkut.»

Aturan mainnya disebutkan di awal: saya kerja sendiri, boleh minta hint kalau perlu, dan tiap hint mengurangi skor.

Investigasi

Tidak ada informasi lain selain tiket di atas. Karena webmail masih bisa diakses tapi pengiriman macet, langkah pertama saya selalu sama, lihat status zimbra dulu:

Via CLI
```
su - zimbra
zmcontrol status
```
Ketemu. Komponen mta dan yang berhubungan dengan mta stopped, komponen yang menjalankan Postfix. Ini sesuai dengan tanda-tanda nya, webmail (mailbox) jalan, tapi pengiriman (mta) mati.

Tips: Sebelum menyalakan apa pun, cek dulu antrian mail untuk pastikan email cuma tertahan, bukan hilang:
```
su - zimbra -c 'mailq'
```
Coba Fitur Hint

Karena ada fitur hint di drill ini, saya sengaja minta supaya tahu seperti apa bentuk hint nya.

Claude kasih Hint 1 (dari 3 hint) sesuai urutan bertingkat yang sudah dia siapkan: «Ini bukan masalah mailbox/store, gejalanya di layer pengiriman (MTA).» Isinya memang sudah ketemu lewat zmcontrol status, jadi saya lanjut ke fix tanpa minta hint kedua.

Fix

Tinggal nyalakan lagi komponen MTA-nya:
```
su - zimbra 
zmmtactl start
```
Setelah zmcontrol status saya cek ulang dan semua komponen kembali «Running», saya bilang ke Claude Code kalau saya sudah selesai.

Verifikasi

Claude tidak langsung percaya status «Running» saja. Dia jalankan verifikasi fungsional lewat SSH ke node lab: cek ulang zmcontrol status, cek mailq untuk pastikan antrian yang tadi tertahan mulai jalan, lalu kirim email uji dan bandingkan hasilnya ke baseline yang direkam sebelum fault disuntikkan. Semua cocok, gejalanya hilang karena root cause-nya memang sudah benar diperbaiki, bukan cuma ditutupi.

Debrief dan skor

Baru di titik ini Claude membuka kartunya. Root cause-nya persis seperti dugaan saya, service MTA (Postfix) dihentikan manual lalu dinyalakan kembali. Claude jelaskan kenapa fault ini realistis, di dunia nyata ini sering kejadian waktu ada maintenance atau restart manual yang lupa dinyalakan lagi setelahnya.

Skor saya 8.5 dari 10, dipotong karena pakai satu hint meski sebenarnya lebih untuk coba-coba daripada kebutuhan. Hasil ini dicatat ke progress.md di project drill saya, jadi kelihatan riwayatnya kalau saya naik level nanti.

Penutup

Ronde ini singkat, cek status dulu secara menyeluruh sebelum menyentuh apa pun yang kelihatan mati. Level 1 memang dirancang begitu, satu masalah, error yang cukup terang asal dicek di tempat yang benar. Sampai jumpa di Level 2.
July 14, 2026