Tag: mail server

  • 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

  • Panduan Upgrade Carbonio Menggunakan Ansible

    Panduan Upgrade Carbonio Menggunakan Ansible

    Pendahuluan

    Menjaga Carbonio tetap menggunakan versi terbaru merupakan salah satu langkah penting untuk mendapatkan fitur terbaru, peningkatan performa, perbaikan bug, serta pembaruan keamanan. Mulai Carbonio 26.6.x, Zextras menyediakan mekanisme upgrade yang lebih terstruktur menggunakan Ansible, sehingga proses pembaruan dapat dilakukan secara konsisten baik pada deployment single-node maupun multi-node.

    Berbeda dengan aplikasi yang memiliki installer terpisah, Carbonio melakukan upgrade melalui pembaruan package sistem. Oleh karena itu, proses upgrade dilakukan menggunakan Ansible Playbook yang akan memperbarui seluruh paket Carbonio dari repository resmi Zextras ke versi terbaru yang tersedia. Dokumentasi resmi juga menjelaskan bahwa prosedur ini dapat digunakan untuk melakukan upgrade dari versi Carbonio yang masih didukung menuju versi terbaru tanpa harus melewati setiap versi satu per satu. Sebelum memulai upgrade, Zextras sangat menyarankan untuk membuat backup dan snapshot seluruh node sebagai langkah mitigasi apabila terjadi kendala selama proses upgrade.


    Persyaratan

    Sebelum menjalankan proses upgrade, pastikan beberapa persyaratan berikut telah dipenuhi:

    • Sudah melakukan backup seluruh data Carbonio.
    • Membuat snapshot seluruh virtual machine (jika menggunakan virtualisasi).
    • Seluruh repository Carbonio telah dikonfigurasi dengan benar.
    • Ansible dapat melakukan koneksi SSH ke seluruh node.
    • File inventory Ansible masih sesuai dengan kondisi infrastruktur Carbonio.
    • Hanya repository yang ingin digunakan untuk upgrade yang dalam kondisi aktif. Repository lain sebaiknya dinonaktifkan agar tidak ikut memperbarui package yang tidak diinginkan.

    Install atau Update Collection Carbonio Upgrade

    Sebelum menjalankan playbook upgrade, pastikan collection zxbot.carbonio_upgrade telah terpasang atau diperbarui ke versi terbaru.

    Jalankan perintah berikut:

    ansible-galaxy collection install zxbot.carbonio_upgrade -U

    Parameter -U berfungsi untuk:

    • menginstal collection apabila belum tersedia,
    • atau memperbarui collection ke versi terbaru apabila sudah pernah diinstal sebelumnya.

    Collection inilah yang berisi seluruh playbook yang digunakan untuk melakukan upgrade Carbonio.


    Pastikan File Inventory

    Ansible akan menggunakan file inventory yang sebelumnya digunakan saat instalasi.

    Contoh:

    carbonio-inventory

    Pastikan seluruh hostname, FQDN, dan pembagian service masih sesuai dengan kondisi server saat ini.

    Jika sebelumnya Carbonio diinstal secara manual, inventory tetap dapat digunakan selama seluruh node dan komponennya telah diisikan dengan benar.


    Jalankan Upgrade

    Masuk ke direktori tempat inventory berada, kemudian jalankan:

    ansible-playbook zxbot.carbonio_upgrade.carbonio_upgrade \
    -u root \
    -i carbonio-inventory

    Playbook akan melakukan proses upgrade seluruh package Carbonio yang berasal dari repository resmi Zextras.

    Dokumentasi resmi menjelaskan bahwa versi Carbonio yang saat ini terpasang tidak memengaruhi prosedur upgrade. Selama berasal dari versi yang masih didukung, sistem akan diperbarui ke release terbaru yang tersedia pada repository.


    Mencegah Auto Remove Package

    Secara default, playbook akan menjalankan proses autoremove terhadap dependency yang dianggap sudah tidak digunakan.

    Apabila Anda ingin menonaktifkan perilaku tersebut, gunakan parameter berikut:

    ansible-playbook zxbot.carbonio_upgrade.carbonio_upgrade \
    -u root \
    -i carbonio-inventory \
    --extra-vars skip_autoremove=1

    Opsi ini cukup berguna apabila Anda ingin melakukan verifikasi terlebih dahulu sebelum menghapus package yang tidak lagi digunakan.

    Perlu diperhatikan bahwa package yang dipasang secara manual dan tidak digunakan oleh Carbonio tidak akan dihapus secara otomatis, sehingga administrator tetap perlu melakukan pembersihan apabila diperlukan.


    Jika Upgrade Gagal

    Apabila proses upgrade berhenti karena suatu error, Anda tidak perlu mengulang seluruh proses dari awal.

    Cukup jalankan kembali playbook yang sama:

    ansible-playbook zxbot.carbonio_upgrade.carbonio_upgrade \
    -u root \
    -i carbonio-inventory

    Ansible akan mengenali task yang telah berhasil dijalankan sebelumnya dan hanya mengeksekusi task yang gagal atau belum selesai. Mekanisme ini membantu mempercepat proses recovery tanpa harus mengulang keseluruhan upgrade.


    Catatan Khusus Upgrade dari Versi Lama

    Bagi administrator yang melakukan upgrade dari Carbonio versi lama, terdapat beberapa penyesuaian pada file inventory.

    Upgrade dari Carbonio 24.12

    Jika menggunakan Carbonio 24.12, pastikan inventory telah memiliki section:

    [workStreamServers]

    Jika sebelumnya menggunakan komponen Chats, tambahkan hostname node Chats pada section tersebut sebelum menjalankan upgrade.

    Upgrade dari Carbonio 24.9 atau Lebih Lama

    Untuk deployment yang berasal dari Carbonio 24.9 atau versi yang lebih lama, section berikut tetap harus ada pada inventory selama proses upgrade:

    [dbsConnectorServers]

    Walaupun komponen DB Connector telah dihapus pada versi terbaru, keberadaan section tersebut masih diperlukan agar Ansible dapat melakukan migrasi package dengan benar. Setelah proses upgrade selesai, section tersebut dapat dikosongkan sesuai rekomendasi dokumentasi.


    Hal Pasca Upgrade

    Mulai Carbonio 26.6.x, Zextras memperkenalkan Unified Quota.

    Perubahan ini menggabungkan quota Mail, Files, dan Chat menjadi satu quota penyimpanan per pengguna.

    Penting untuk diketahui bahwa konfigurasi quota lama tidak dimigrasikan secara otomatis. Setelah upgrade, seluruh akun akan memiliki quota Unlimited hingga administrator menetapkan quota baru.

    Oleh karena itu, administrator disarankan untuk:

    • meninjau kembali penggunaan storage,
    • menentukan kebijakan quota baru,
    • menjalankan migration script Unified Quota yang tersedia melalui Partner Portal apabila diperlukan.

    Kesimpulan

    Upgrade Carbonio menggunakan Ansible merupakan metode resmi yang direkomendasikan oleh Zextras karena mampu melakukan pembaruan secara konsisten pada seluruh node dalam infrastruktur. Proses upgrade cukup sederhana, yaitu memperbarui collection Ansible, memastikan inventory telah sesuai, kemudian menjalankan playbook upgrade.

    Sebelum memulai proses, jangan lupa melakukan backup dan snapshot seluruh server. Selain itu, apabila Anda melakukan upgrade ke Carbonio 26.6.x, pastikan untuk meninjau perubahan Unified Quota karena konfigurasi quota lama tidak akan dimigrasikan secara otomatis dan memerlukan tindakan administrator setelah proses upgrade selesai.


    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