Tag: email

  • OpenDKIM, Selector, dan Perbedaan RSA Key Size

    OpenDKIM, Selector, dan Perbedaan RSA Key Size

    OpenDKIM

    OpenDKIM merupakan aplikasi open-source yang digunakan untuk menambahkan tanda tangan digital pada email menggunakan metode DomainKeys Identified Mail (DKIM).

    Tujuannya adalah membantu server penerima memastikan bahwa email telah ditandatangani menggunakan private key yang sesuai dengan domain penandatangan dan bahwa bagian email yang dilindungi tidak mengalami perubahan selama pengiriman.

    OpenDKIM umumnya digunakan bersama mail server seperti Postfix, termasuk pada infrastruktur SMTP Relay dan mail gateway.

    Cara Kerja OpenDKIM

    Secara sederhana, proses DKIM bekerja sebagai berikut:

    1. Email dikirim: Mail server memproses email keluar.
    2. DKIM Signing: OpenDKIM menandatangani email menggunakan private key.
    3. Verifikasi: Server penerima mengambil public key dari DNS untuk memverifikasi tanda tangan.
    4. Hasil: Jika tanda tangan valid, pemeriksaan DKIM menghasilkan status pass.

    DKIM membantu memverifikasi keaslian tanda tangan email, tetapi tidak secara otomatis menjamin email bebas dari spam.

    DKIM Selector

    Salah satu komponen penting dalam OpenDKIM adalah selector. Selector merupakan nama yang digunakan untuk mengidentifikasi pasangan private key dan public key dalam sebuah domain.

    Contohnya, domain example.com menggunakan selector bernama mail. Maka DNS record DKIM berada pada:

    mail._domainkey.example.com

    Satu domain dapat memiliki beberapa selector, misalnya:

    • default._domainkey.example.com
    • mail._domainkey.example.com
    • relay._domainkey.example.com

    Dengan beberapa selector, setiap mail server dapat menggunakan pasangan key berbeda tanpa harus menggunakan domain yang berbeda.

    RSA Key Size pada DKIM

    Ketika membuat DKIM key, kita dapat menentukan ukuran RSA key yang digunakan. Beberapa ukuran yang dikenal adalah 512-bit, 1024-bit, 2048-bit, dan 4096-bit. Ukuran ini merupakan panjang RSA key, bukan ukuran selector.

    RSA Key SizeKeterangan
    512-bitTidak aman dan tidak diperbolehkan oleh standar DKIM saat ini
    1024-bitUkuran minimum yang diperbolehkan
    2048-bitDirekomendasikan karena keamanan lebih kuat
    4096-bitLebih besar dan didukung untuk verifikasi, tetapi umumnya tidak diperlukan

    Contoh Membuat DKIM Key 2048-bit

    Pada server yang sudah memiliki OpenDKIM Tools, kita dapat membuat RSA key 2048-bit menggunakan perintah:

    opendkim-genkey -b 2048 -s mail -d example.com

    Keterangan:

    • -b 2048 menentukan ukuran RSA key.
    • -s mail menentukan selector.
    • -d example.com menentukan domain.

    Perintah tersebut menghasilkan dua file:

    • mail.private — private key untuk menandatangani email.
    • mail.txt — berisi DNS TXT record untuk publikasi public key.

    Public key dipublikasikan melalui DNS, sedangkan private key disimpan dan digunakan oleh OpenDKIM.

    Kesimpulan

    OpenDKIM merupakan salah satu solusi untuk menerapkan DKIM signing pada mail server. Dalam konfigurasinya, terdapat dua hal yang perlu dibedakan, yaitu selector sebagai identitas key dan RSA key size sebagai ukuran kunci kriptografi.

    RSA 512-bit sudah tidak memenuhi standar keamanan DKIM saat ini. Sementara itu, RSA 1024-bit masih diperbolehkan sebagai ukuran minimum, tetapi RSA 2048-bit lebih direkomendasikan untuk konfigurasi baru.

    Referensi:

  • Jenis Kejahatan dan Penipuan Melalui Email

    Jenis Kejahatan dan Penipuan Melalui Email

    Email menjadi bagian penting dalam komunikasi, pertukaran dokumen, dan transaksi perusahaan. Pelaku kejahatan tidak hanya menyerang mail server, tetapi juga memanfaatkan kepercayaan terhadap nama pengirim, domain, dan percakapan yang terlihat sah.

    Serangan perlu dibedakan menjadi dua area. Pertama, serangan terhadap infrastruktur, seperti eksploitasi server yang belum di-patch, penyalahgunaan SMTP Relay, akun administrator, atau DNS. Kedua, penipuan melalui akun dan pesan, seperti phishing, spoofing, pengambilalihan akun, dan manipulasi transaksi. Jenis kedua dapat terjadi tanpa membobol mail server.

    Jenis Ancaman pada Email

    1. Phishing dan Spear Phishing

    Pelaku mengarahkan korban ke halaman login, tautan, atau lampiran berbahaya. Spear phishing disesuaikan dengan jabatan atau aktivitas korban. Indikasinya antara lain permintaan mendesak, URL tidak sesuai, dan login dari perangkat asing. Dampaknya berupa pencurian kredensial dan akses awal ke sistem. Cegah dengan MFA, penyaringan konten, dan edukasi pengguna. CISA menjelaskan cara kerja dan mitigasi phishing.

    2. Business Email Compromise

    Dalam Business Email Compromise (BEC), pelaku menyamar sebagai pimpinan, vendor, atau bagian keuangan untuk meminta pembayaran, data, atau perubahan rekening. Periksa instruksi mendadak, domain yang hampir sama, Reply-To berbeda, dan permintaan melewati prosedur. Dampaknya berupa kerugian finansial atau kebocoran informasi. Perubahan pembayaran harus diverifikasi melalui kanal lain. FBI menyebut BEC sebagai pesan yang seolah-olah berasal dari sumber dikenal.

    3. Email Spoofing dan Domain Impersonation

    Pelaku memalsukan pengirim atau menggunakan domain menyerupai domain resmi. Periksa header, Authentication-Results, SPF, DKIM, DMARC, dan karakter domain. Ketiga mekanisme tersebut mengurangi pemalsuan domain, tetapi tidak menjamin identitas individu atau menghentikan domain tiruan. NIST merekomendasikannya untuk meningkatkan kepercayaan terhadap email.

    4. Account Takeover

    Account takeover terjadi ketika pelaku memperoleh password, token, atau sesi melalui phishing, penggunaan ulang password, malware, atau kebocoran data. Indikasinya berupa login dari IP, lokasi, perangkat, atau waktu yang tidak biasa dan email yang tidak dibuat pengguna. Dampaknya mencakup akses ke mailbox, kontak, dan layanan lain. Gunakan password unik, MFA, pembatasan sesi, dan nonaktifkan autentikasi lama. IC3 menjelaskan metode pengambilalihan akun dan pentingnya MFA.

    5. Manipulasi Percakapan Email

    Setelah menguasai akun, pelaku dapat memantau dan masuk ke dalam thread transaksi. Perubahan gaya bahasa, Reply-To, dokumen, rekening, atau waktu pengiriman menjadi indikasi. Karena pesan berasal dari akun sah, autentikasi domain dapat tetap lolos. Verifikasi perubahan data penting melalui kanal resmi yang sudah dikenal.

    6. Forwarding Rule Tanpa Izin

    Pelaku dapat membuat aturan untuk meneruskan, memindahkan, atau menghapus email sehingga transaksi terpantau dan notifikasi keamanan tersembunyi. Periksa seluruh inbox rule, penerusan eksternal, folder tidak umum, dan log perubahan. Batasi penerusan keluar serta buat peringatan perubahan aturan. Microsoft mendokumentasikan pola penyalahgunaan ini.

    7. Penyalahgunaan Open Relay atau Akun SMTP

    Open relay, cakupan trusted network terlalu luas, atau kredensial SMTP yang bocor dapat digunakan untuk mengirim spam, phishing, dan malware. Gejalanya berupa lonjakan email keluar, mail queue, keluhan penerima, atau IP masuk blacklist. Dampaknya adalah pemblokiran pengiriman dan penurunan reputasi. Batasi relay, wajibkan autentikasi, terapkan rate limit, dan pantau volume.

    8. Malware dan Ransomware

    Lampiran atau tautan berbahaya dapat menjalankan malware pada perangkat korban. Indikasinya berupa deteksi antivirus atau EDR, proses tidak biasa, koneksi mencurigakan, serta file terenkripsi. Dampaknya mencakup pencurian data dan gangguan operasional. Terapkan pemindaian, sandboxing, pemblokiran ekstensi berisiko, patch rutin, backup teruji, dan pelatihan pengguna.

    9. Pencurian dan Kebocoran Data

    Email, lampiran, dan kontak dapat disalin melalui forwarding, sinkronisasi IMAP, ekspor, atau pengiriman keluar. Indikasinya berupa akses massal, lampiran besar, penerima tidak biasa, dan aktivitas di luar jam kerja. Terapkan pembatasan akses, DLP, audit mailbox, dan retensi log. Pada Microsoft 365, audit MailItemsAccessed dapat membantu menentukan cakupan email yang diakses. Dokumentasi Microsoft menjelaskan penggunaannya.

    Pemeriksaan oleh Administrator Email

    Pemeriksaan sebaiknya dilakukan pada beberapa lapisan berikut:

    • Identitas: log autentikasi, percobaan login, IP, lokasi, perangkat, perubahan password, sesi aktif, metode MFA, dan aplikasi yang diberi akses.
    • Mailbox: forwarding rule, filter, delegasi, folder Sent dan Deleted, serta perubahan signature atau profil pengguna.
    • Alur email: lonjakan pengiriman, mail queue, log SMTP, message trace, alamat tujuan, dan pola gagal-kirim.
    • Administrasi: perubahan hak akses dan konfigurasi, aktivitas administrator, serta log yang hilang, terputus, atau berubah secara tidak wajar.
    • Domain dan transport: validasi SPF, DKIM, DMARC beserta alignment dan laporannya; sertifikat dan TLS; MTA-STS; TLS-RPT; blacklist IP; serta reputasi domain. MTA-STS mendeklarasikan penggunaan TLS yang diharapkan, sedangkan TLS-RPT memberi visibilitas terhadap kegagalan atau dugaan gangguan koneksi SMTP TLS.

    Rekomendasi Pengamanan

    Gunakan pengamanan berlapis: MFA, password policy, pembatasan hak akses, penonaktifan protokol lama, dan evaluasi sesi. Pada server, lakukan patch rutin, nonaktifkan open relay, batasi trusted network, terapkan SMTP Authentication dan rate limit, serta pantau mail queue. Lengkapi DNS dan transport dengan SPF, DKIM, DMARC, TLS, MTA-STS, dan TLS-RPT. Backup konfigurasi dan data, kirim log ke lokasi terpisah, tetapkan retensi yang cukup, dan lakukan monitoring. Untuk transaksi, setiap perubahan rekening wajib diverifikasi melalui kanal lain dan sebaiknya menggunakan persetujuan dua pihak.

    Penanganan Awal Insiden

    Jika ditemukan indikasi insiden, lakukan tindakan berikut:

    1. Isolasi atau nonaktifkan sementara akun yang terdampak.
    2. Reset password dan cabut seluruh sesi serta token aktif.
    3. Periksa forwarding rule, delegasi, metode MFA, dan perubahan konfigurasi.
    4. Simpan log, header email, dan bukti transaksi sebelum melakukan pembersihan.
    5. Blokir IP, domain, alamat pengirim, dan indikator serangan yang terverifikasi.
    6. Hubungi bank secepatnya apabila berkaitan dengan transaksi keuangan.
    7. Informasikan insiden kepada manajemen, pemilik data, tim legal, dan pihak berwenang sesuai kebutuhan.
    8. Tentukan cakupan dampak, pulihkan layanan, lalu perbaiki kontrol yang gagal.

    Microsoft juga merekomendasikan penonaktifan akun selama investigasi, pencabutan sesi, pemeriksaan MFA, aplikasi, forwarding, dan audit log.

    Penutup

    Keamanan email tidak cukup hanya mengandalkan antispam. Perlindungan harus mencakup server, akun, DNS, koneksi antarmail server, log, prosedur transaksi, dan kesadaran pengguna. Kombinasi kontrol teknis dan verifikasi manusia menjadi kunci untuk mencegah email digunakan sebagai sarana pencurian, kecurangan, dan penipuan.

  • Cara Mengatasi zmamavisdctl Gagal Start Setelah Upgrade Zimbra NE 10.1.20

    Cara Mengatasi zmamavisdctl Gagal Start Setelah Upgrade Zimbra NE 10.1.20

    Saya memiliki server Zimbra Collaboration Network Edition 10.1.16 yang sudah cukup lama tidak diperbarui. Setelah melakukan upgrade (patching) ke Zimbra 10.1.20, seluruh proses upgrade berjalan dengan baik, namun terdapat satu masalah, yaitu service Amavis (zmamavisdctl) gagal dijalankan.

    Akibatnya:

    • Service amavis berstatus Stopped.
    • Service antivirus dan mta juga ikut berhenti.
    • Email tidak dapat diproses karena Postfix gagal terhubung ke Amavis.

    Gejala

    Cek status service:

    zmcontrol status

    Hasil:

    zimbra@mail:~$ zmcontrol status
    Host mail.zimbra.lab
            amavis                  Stopped
                    amavisd is not running.
            antispam                Stopped
                    zmamavisdctl is not running
            antivirus               Stopped
                    zmamavisdctl is not running
            convertd                Running
            ldap                    Running
            license-daemon          Running
            logger                  Running
            mailbox                 Running
            memcached               Running
            mta                     Stopped
                    zmamavisdctl is not running
            onlyoffice              Running
            opendkim                Running
            proxy                   Running
            service webapp          Running
            snmp                    Running
            spell                   Running
            stats                   Running
            zimbra webapp           Running
            zimbraAdmin webapp      Running
            zimlet webapp           Running
            zmconfigd               Running

    Log Postfix menunjukkan:

    connect to 127.0.0.1:10026: Connection refused

    Artinya Amavis tidak berhasil membuka port filtering SMTP.


    Proses Troubleshooting

    1. Pastikan penyebab

    Jalankan:

    su - zimbra
    
    /opt/zimbra/common/sbin/amavisd \
    -X no_conf_file_writable_check \
    -c /opt/zimbra/conf/amavisd.conf \
    test-config

    Jika tidak ada output, berarti konfigurasi Amavis valid.


    2. Jalankan Amavis secara foreground

    /opt/zimbra/common/sbin/amavisd \
    -X no_conf_file_writable_check \
    -c /opt/zimbra/conf/amavisd.conf \
    foreground

    Didapatkan error:

    zimbra@mail:~$ /opt/zimbra/common/sbin/amavisd \
    -X no_conf_file_writable_check \
    -c /opt/zimbra/conf/amavisd.conf \
    foreground
    
    Suicide () TROUBLE in pre_loop_hook: config: no rules were found!  Do you need to run 'sa-update'?
    Compilation failed in require at /opt/zimbra/common/sbin/amavisd line 101.
    BEGIN failed--compilation aborted at /opt/zimbra/common/sbin/amavisd line 101.

    3. Periksa SpamAssassin

    Lakukan pengecekan:

    /opt/zimbra/common/bin/spamassassin --lint -D

    Hasil akhirnya menunjukkan:

    zimbra@mail:~$ /opt/zimbra/common/bin/spamassassin --lint -D
    .
    .
    .
    config: no rules were found!  Do you need to run 'sa-update'?

    Padahal direktori rules masih lengkap.


    4. Jalankan sa-update

    /opt/zimbra/common/bin/sa-update -D

    Didapatkan error:

    zimbra@mail:~$ /opt/zimbra/common/bin/sa-update -D
    .
    .
    Aug  3 12:05:57.745 [47987] dbg: gpg: [GNUPG:] NO_PUBKEY 6C55397824F434CE
    Aug  3 12:05:57.745 [47987] dbg: gpg: gpg: Can't check signature: No public key
    .
    .
    NO_PUBKEY
    error: GPG validation failed!

    Dari sini diketahui bahwa GPG key SpamAssassin hilang, sehingga proses update rules gagal diverifikasi.


    Solusi

    1. Buat direktori key

    mkdir -p /opt/zimbra/data/spamassassin/localrules/sa-update-keys
    chown -R zimbra:zimbra /opt/zimbra/data/spamassassin/localrules

    2. Download GPG Key resmi

    cd /tmp
    wget https://spamassassin.apache.org/updates/GPG.KEY

    3. Import GPG Key

    Jalankan sebagai user zimbra.

    su - zimbra
    /opt/zimbra/common/bin/sa-update --import /tmp/GPG.KEY

    4. Update SpamAssassin Rules

    /opt/zimbra/common/bin/sa-update

    Pastikan proses selesai tanpa error GPG.

    5. Restart Service

    zmamavisdctl restart

    atau

    zmcontrol restart

    Verifikasi

    Pastikan service kembali berjalan:

    zmcontrol status

    Hasil yang diharapkan:

    zimbra@mail:~$ zmcontrol status
    Host mail.zimbra.lab
            amavis                  Running
            antispam                Running
            antivirus               Running
            convertd                Running
            ldap                    Running
            license-daemon          Running
            logger                  Running
            mailbox                 Running
            memcached               Running
            mta                     Running
            onlyoffice              Running
            opendkim                Running
            proxy                   Running
            service webapp          Running
            snmp                    Running
            spell                   Running
            stats                   Running
            zimbra webapp           Running
            zimbraAdmin webapp      Running
            zimlet webapp           Running
            zmconfigd               Running

    Lalu pastikan dapat mengirim email secara normal kembali.


    Kesimpulan

    Kasus ini terjadi setelah melakukan upgrade dari Zimbra 10.1.16 ke 10.1.20 pada server yang sudah lama tidak diperbarui. Penyebab utamanya bukan pada konfigurasi Amavis, melainkan GPG key SpamAssassin yang hilang, sehingga proses sa-update gagal memverifikasi update rules. Akibatnya, SpamAssassin tidak dapat memuat rules dan Amavis gagal dijalankan.

    Dengan mengembalikan GPG key, menjalankan kembali sa-update, dan me-restart service Zimbra, service amavis, antivirus, dan mta dapat kembali berjalan normal.

    Referensi

  • Mengganti Logo & White Label Zimbra Modern UI

    Mengganti Logo & White Label Zimbra Modern UI

    Salah satu kebutuhan yang sering muncul ketika implementasi mail server Zimbra Collaboration adalah menyesuaikan tampilan webmail dengan identitas perusahaan. Mengganti logo perusahaan pada halaman webmail dapat meningkatkan branding sekaligus memberikan pengalaman yang lebih profesional bagi pengguna.

    Sejak hadirnya Modern UI, mekanisme penggantian logo di Zimbra berubah dibandingkan dengan Classic Web Client. Oleh karena itu, para admin perlu menggunakan metode yang sesuai dengan antarmuka yang digunakan.

    Pada artikel ini kita akan membahas cara mengganti logo pada Zimbra Modern UI berdasarkan panduan resmi Zimbra.


    Rebranding vs White Label

    Sebelum memulai, penting untuk memahami dua istilah yang sering digunakan.

    Rebranding adalah proses menambahkan identitas perusahaan, seperti logo, tanpa menghilangkan identitas Zimbra yang diwajibkan oleh lisensi tertentu.

    Sedangkan White Label berarti mengganti identitas Zimbra sepenuhnya dengan identitas perusahaan, termasuk logo maupun elemen antarmuka lainnya.

    Bagi pengguna Zimbra Open Source Edition, proses rebranding tetap harus mengikuti ketentuan lisensi CPAL. Sementara itu, kemampuan white label melalui konfigurasi bawaan tersedia pada Zimbra Network Edition. Informasi ini dijelaskan pada panduan resmi Zimbra mengenai rebranding Classic Web Client.

    Catatan

    Apabila masih menggunakan Classic Web Client (Zimbra 8.x), Zimbra telah menyediakan panduan resmi tersendiri mengenai penggantian Login Banner dan Application Banner menggunakan atribut zmprov. Karena artikel ini difokuskan pada Modern UI, panduan tersebut tidak dibahas kembali di sini.


    Persiapan

    Sebelum mengganti logo, siapkan terlebih dahulu file logo dengan format:

    • SVG (logo.svg)

    Modern UI menggunakan file logo.svg sebagai logo aplikasi.


    Menentukan Jenis Virtual Host

    Langkah pertama adalah mengetahui apakah deployment menggunakan default virtual hostname atau custom virtual hostname.

    Caranya:

    1. Login ke Modern UI menggunakan browser Firefox.
    2. Klik kanan pada logo Zimbra.
    3. Pilih Open Image in New Tab.
    4. Perhatikan URL gambar yang muncul.

    Hasilnya akan menunjukkan salah satu dari dua kondisi berikut:

    • Menggunakan default virtual hostname.
    • Menggunakan custom virtual hostname.

    Metode penggantian logo akan mengikuti kondisi tersebut.


    Prosedur A — Default Virtual Host

    Apabila logo berasal dari default virtual hostname, lakukan langkah berikut.

    1. Masuk ke direktori aset Modern UI

    cd /opt/zimbra/jetty/webapps/zimbra/modern/clients/default/assets

    2. Backup logo bawaan

    Sebelum mengganti logo, simpan salinan file asli.

    cp logo.svg logo.svg.old

    3. Upload logo

    Upload file logo perusahaan dengan nama:

    logo.svg

    ke direktori:

    /opt/zimbra/jetty/webapps/zimbra/modern/clients/default/assets

    Apabila file diunggah menggunakan user root, ubah ownership menjadi user zimbra.

    chown zimbra:zimbra \
    /opt/zimbra/jetty/webapps/zimbra/modern/clients/default/assets/logo.svg


    4. Perbarui config.json

    Edit file berikut.

    /opt/zimbra/jetty/webapps/zimbra/modern/clients/default/config.json

    Kemudian ubah nilai version menjadi nilai baru yang belum pernah digunakan sebelumnya.

    Tujuan perubahan versi ini adalah agar browser mengambil aset terbaru setelah logo diganti.


    5. Restart layanan Mailbox

    Masuk sebagai user zimbra.

    su - zimbra

    Kemudian restart layanan.

    zmmailboxdctl restart

    Prosedur B — Custom Virtual Host

    Apabila hasil pengecekan menunjukkan penggunaan custom virtual hostname, ikuti langkah berikut.

    1. Login sebagai user zimbra

    su - zimbra

    Masuk ke direktori Modern UI.

    cd /opt/zimbra/jetty/webapps/zimbra/modern/clients/

    2. Salin direktori default

    Salin direktori default menjadi nama virtual hostname yang digunakan.

    cp -r default <virtual-hostname>

    Sebagai contoh, apabila virtual hostname adalah mail.example.com, maka direktori baru akan dibuat menggunakan nama tersebut.


    3. Masuk ke direktori assets

    cd /opt/zimbra/jetty/webapps/zimbra/modern/clients/<virtual-hostname>/assets

    4. Backup logo bawaan

    cp logo.svg logo.svg.old

    5. Upload logo baru

    Upload logo perusahaan menggunakan nama:

    logo.svg

    ke direktori assets tersebut.


    6. Edit config.json

    Edit file:

    /opt/zimbra/jetty/webapps/zimbra/modern/clients/<virtual-hostname>/config.json

    Kemudian ubah nilai version menggunakan nilai baru yang belum pernah digunakan sebelumnya.


    7. Restart layanan

    Setelah konfigurasi, restart layanan Mailbox sebagai zimbra.

    zmmailboxdctl restart

    Verifikasi

    Setelah layanan berhasil dijalankan kembali:

    1. Buka kembali halaman Modern UI.
    2. Refresh browser.
    3. Apabila logo lama masih muncul, bersihkan cache browser lalu muat ulang halaman.

    Perubahan versi pada config.json membantu browser memuat aset terbaru, namun cache browser tetap dapat memengaruhi hasil yang ditampilkan.


    Hal yang Perlu Diperhatikan

    Beberapa hal penting sebelum melakukan kustomisasi logo:

    • Selalu lakukan backup terhadap file logo.svg bawaan.
    • Gunakan nilai version baru setiap kali mengganti logo.
    • Pastikan ownership file tetap dimiliki oleh user zimbra apabila proses upload dilakukan menggunakan user root.
    • Restart zmmailboxdctl setelah seluruh perubahan selesai dilakukan.

    Penutup

    Pada Modern UI, proses penggantian logo tidak lagi menggunakan atribut zmprov seperti pada Classic Web Client. Sebagai gantinya, administrator perlu mengganti file logo.svg, memperbarui nilai version pada config.json, kemudian me-restart layanan zmmailboxdctl.

    Bagi administrator yang masih menggunakan Classic Web Client, Zimbra tetap menyediakan panduan resmi mengenai rebranding Login Banner dan Application Banner. Namun, untuk implementasi Zimbra Modern UI, metode yang dijelaskan dalam artikel ini merupakan pendekatan yang direkomendasikan oleh Zimbra.

    Referensi

    1. Zimbra. (2023). Did you know? How to change the Zimbra logo in Modern UI. https://blog.zimbra.com/2023/08/did-you-know-how-to-change-the-zimbra-logo-in-modern-ui/
    2. Zimbra. (2021). How to change modern user interface logo. https://wiki.zimbra.com/wiki/How_to_change_modern_user_interface_logo
    3. Zimbra. (2015). How to add your Logo in the Login and App window in Open Source or Network Edition. https://blog.zimbra.com/2015/09/change-login-app-logo-open-source-network-edition/
  • Simulasi Error SMTP 451 Temporary Lookup Failure dengan 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

    PeranHostnameIPOS
    Pengirimsender.lab192.168.14.22Ubuntu 24.04
    Penerimareceiver.lab192.168.14.23Ubuntu 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

    SkenarioBalasan SMTPStatus di antrian
    Server penerima normal250 2.0.0 Oksent
    Gangguan sementara di penerima451 4.3.0 Temporary lookup failuredeferred, retry otomatis
    Alamat ditolak permanen550 5.x.xbounced, tidak retry

    Troubleshoot

    GejalaPenyebabSolusi
    Host or domain name not foundSender masih pakai lookup DNSSet relayhost = [IP_RECEIVER] atau smtp_host_lookup = native, dns
    Connection refused port 25inet_interfaces = loopback-only atau firewallSet inet_interfaces = all, buka port 25
    Relay access deniedDomain tujuan tidak ada di mydestinationTambahkan receiver.lab ke mydestination
    554 Too many hopsMail loop antar serverPeriksa relayhost, mydestination, dan transport_maps
    /var/log/mail.log kosongrsyslog tidak terpasangGunakan 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

  • Bagian 1: Mengenal SMTP Relay

    Bagian 1: Mengenal SMTP Relay

    Pada minggu-minggu terakhir, saya mulai cukup banyak bersinggungan dengan layanan SMTP Relay, seperti pengaturan DNS seperti SPF, DKIM, dan DMARC. Dari situ saya menyadari bahwa banyak istilah dan konsep yang selama ini sering digunakan ternyata belum benar-benar saya pahami secara menyeluruh.

    Karena itu, saya memutuskan untuk membuat sebuah seri tulisan yang membahas dasar-dasar SMTP dan SMTP Relay. Tujuannya bukan hanya sebagai dokumentasi pembelajaran pribadi, tetapi juga sebagai referensi bagi siapa saja yang ingin memahami bagaimana proses pengiriman email bekerja, peran server relay, serta teknologi pendukung seperti SPF, DKIM, DMARC, MX Record, hingga alur komunikasi antar mail server. Saya berharap melalui seri ini, pembahasan dapat disampaikan secara bertahap, dimulai dari konsep yang paling mendasar hingga implementasi yang lebih kompleks.

    Apa itu SMTP, sebenarnya?

    SMTP adalah singkatan dari Simple Mail Transfer Protocol. Perhatikan kata pertamanya: Simple. Protokol ini dirancang pada tahun 1982 (RFC 821, lalu diperbarui oleh RFC 5321) dengan filosofi yang sederhana — bagaimana caranya memindahkan sebuah pesan teks dari satu komputer ke komputer lain secara andal.

    Analogi yang paling sering saya pakai: SMTP itu seperti kantor pos dan tukang pos, bukan seperti kotak surat di rumah kalian. Ini penting, jadi saya tegaskan:

    • SMTP bertugas mengirim dan meneruskan email antar server. Ini pekerjaan “tukang pos”.
    • IMAP dan POP3 bertugas agar kalian bisa mengambil dan membaca email dari kotak surat kalian. Ini pekerjaan “membuka kotak surat di rumah”.

    Salah satu kesalahpahaman paling umum yang saya temui: orang mengira SMTP itu untuk membaca email. Bukan. SMTP hanya peduli pada satu hal — memindahkan surat ke tujuan berikutnya.

    Mengenal: MUA, MTA, MDA

    Sebelum masuk ke kata “relay”, kalian wajib kenal tiga singkatan ini. Saya akan pakai istilah-istilah ini terus sepanjang seri, jadi hafalkan baik-baik.

    IstilahKepanjanganPeranContoh nyata
    MUAMail User AgentAplikasi yang kalian pakai untuk menulis & membaca emailOutlook, Thunderbird, Gmail di browser
    MTAMail Transfer AgentServer yang mengirim & meneruskan email antar serverPostfix, Exim, Sendmail
    MDAMail Delivery AgentKomponen yang menaruh email ke kotak surat penerimaDovecot, procmail

    Alur singkatnya begini: kalian menulis email di MUA, MUA menyerahkannya ke MTA, MTA mengoper email itu melewati internet ke MTA lain, lalu di ujung sana MDA menaruhnya ke inbox penerima. Server relay yang akan saya urus (dan yang jadi bintang seri ini) hidup di lapisan MTA.

    Lalu, apa itu “Relay”?

    Nah, sekarang kata kuncinya. Relay dalam konteks email berarti meneruskan email dari satu titik ke titik lain, di mana server yang meneruskan bukanlah pengirim asli maupun penerima akhir.

    Bayangkan estafet lari. Pelari pertama (pengirim) tidak berlari sampai garis finish. Ia memberikan tongkat ke pelari kedua, yang memberikannya lagi ke pelari berikutnya, sampai akhirnya tongkat mencapai finish (penerima). SMTP relay adalah pelari di tengah — ia menerima tongkat (email) lalu meneruskannya ke tujuan berikutnya.

    Kenapa perlu perantara? Kenapa email tidak langsung terbang dari komputer kalian ke server tujuan? Beberapa alasan:

    1. Sentralisasi & kontrol. Perusahaan ingin semua email keluar lewat satu pintu agar bisa dipantau, dicatat, dan diamankan.
    2. Reputasi IP. Server tujuan (misalnya Gmail) menilai email dari reputasi alamat IP pengirim. Mengirim lewat relay dengan IP bereputasi baik jauh lebih mungkin masuk inbox ketimbang dari IP rumahan.
    3. Aplikasi yang tidak mau repot. Aplikasi web, printer, perangkat IoT — mereka tidak mau mengurus antrian, retry, dan enkripsi. Mereka cukup “menitipkan” email ke relay, lalu relay yang mengurus sisanya.
    4. Batasan ISP. Banyak penyedia internet memblokir port 25 dari koneksi rumahan untuk mencegah spam, sehingga mengirim langsung sering kali mustahil.

    Dua wajah SMTP relay

    Ini bagian yang sering bikin bingung pemula, jadi saya pisahkan dengan jelas. Ada dua konteks besar ketika orang menyebut “relay”:

    • Relay sebagai layanan titip-kirim (smarthost). Server aplikasi kalian tidak mengirim langsung ke internet, melainkan menyerahkan semua email ke satu relay tepercaya (disebut smarthost). Relay inilah yang berhubungan dengan dunia luar. Inilah pola yang paling umum di lingkungan korporat.
    • Open relay — dan kenapa ini mimpi buruk. Di masa lalu, banyak server mau meneruskan email dari siapa saja ke siapa saja. Ini disebut open relay. Para spammer menyalahgunakannya besar-besaran untuk menyemburkan jutaan email sampah. Hari ini, open relay adalah dosa besar dalam administrasi email. Server kalian akan langsung masuk daftar hitam (blacklist) global dalam hitungan jam. Salah satu tugas utama saya nanti — dan tema besar di bagian ke-5 seri ini — adalah memastikan relay kita tertutup rapat dan hanya mau melayani pihak yang berwenang.

    Saya tekankan sekali lagi karena ini krusial: relay yang baik itu selektif. Ia tahu persis siapa yang boleh menitip email lewat dirinya, dan menolak semua yang lain.

    Kapan kalian butuh SMTP relay?

    Supaya konkret, ini beberapa skenario nyata di mana relay jadi jawaban:

    • Aplikasi e-commerce kalian perlu mengirim ribuan email “pesanan diterima” per hari, dan kalian ingin semuanya terkirim rapi dengan reputasi terjaga.
    • Kantor punya banyak aplikasi internal (HR, monitoring, printer) yang perlu kirim notifikasi, dan kalian ingin satu titik keluar yang terkontrol.
    • Kalian punya banyak server yang tersebar, tapi ingin semua email keluar melalui satu IP yang sudah dikonfigurasi SPF, DKIM, dan DMARC-nya dengan benar (tenang, semua istilah ini kita bedah tuntas di bagian ke-4).

    Peta perjalanan seri ini

    Karena ini seri berkelanjutan, saya ingin kalian tahu ke mana kita akan pergi. Anggap ini peta perjalanan kita:

    1. Bagian 1 (yang sedang kalian baca): Fondasi — apa itu SMTP dan relay.
    2. Bagian 2: Anatomi perjalanan sebuah email, percakapan SMTP baris demi baris, port, dan istilah DNS seperti MX record.
    3. Bagian 3: Oprek-oprek, membangun relay pertama dengan Postfix dari nol.
    4. Bagian 4: Keamanan & deliverability — TLS, autentikasi SASL, SPF, DKIM, DMARC.
    5. Bagian 5: Menjaga relay tetap sehat — anti-spam, rate limiting, mencegah open relay, dan membaca log saat ada masalah.
    6. Bagian 6: Level produksi — high availability, manajemen antrian, dan monitoring.

    Penutup

    Sampai sini, saya harap gambaran besarnya sudah terbentuk di kepala kalian: SMTP adalah bahasa yang dipakai server email untuk berbicara, dan relay adalah peran perantara yang meneruskan email dengan penuh tanggung jawab.

    Di bagian berikutnya, kita akan menyelami sesuatu yang menurut saya paling seru — kita akan “menguping” percakapan asli antara dua server SMTP, baris demi baris, sampai kalian bisa membaca dan bahkan mengetiknya sendiri dengan tangan. Sampai jumpa di Bagian 2.