Tag: sysadmin

  • Memahami Zimlet pada Zimbra

    Memahami Zimlet pada Zimbra

    Zimbra bukan hanya sekadar mail server yang menyediakan layanan email, kalender, kontak, dan task. Salah satu fitur yang membuat Zimbra fleksibel adalah Zimlet, sebuah mekanisme yang memungkinkan system admin maupun developer mengintegrasikan Zimbra dengan aplikasi, layanan, atau sistem lain tanpa harus mengubah kode inti Zimbra. Zimlet telah menjadi salah satu fitur unggulan sejak awal pengembangan Zimbra dan terus berkembang hingga versi modern.

    Pada artikel ini kita akan membahas apa itu Zimlet, bagaimana cara kerjanya, jenis-jenis Zimlet, contoh implementasinya, hingga cara admin mengelolanya di server Zimbra.


    Apa Itu Zimlet?

    Zimlet adalah ekstensi (plugin) yang dirancang untuk menambahkan kemampuan baru pada Zimbra Collaboration. Dengan Zimlet, informasi di dalam email dapat menjadi interaktif (actionable content) sehingga pengguna dapat berinteraksi langsung dengan aplikasi atau layanan lain tanpa meninggalkan antarmuka Zimbra.

    Sederhananya, Zimlet dapat:

    • Menambahkan menu baru pada antarmuka Zimbra.
    • Menghubungkan email dengan aplikasi pihak ketiga.
    • Menampilkan informasi tambahan ketika pengguna mengarahkan kursor ke suatu objek.
    • Menambahkan fitur drag-and-drop.
    • Menambahkan tab atau panel baru pada Zimbra Web Client.

    Mengapa Zimlet Dibuat?

    Pada umumnya, ketika menerima email yang berisi alamat, nomor resi, atau nomor penerbangan, pengguna harus membuka browser lalu mencari informasi tersebut secara manual.

    Dengan Zimlet, proses tersebut menjadi jauh lebih sederhana.

    Contohnya:

    • Alamat pada email langsung dapat dibuka di Google Maps.
    • Nomor penerbangan dapat menampilkan status penerbangan secara real-time.
    • Nomor tiket helpdesk langsung membuka halaman tiket.
    • Nomor telepon dapat langsung dihubungkan ke aplikasi VoIP.
    • Link meeting dapat langsung membuka Zoom atau Microsoft Teams.

    Semua proses tersebut berlangsung tanpa harus keluar dari Zimbra.

    Contoh Zimlet Bawaan Zimbra

    Beberapa Zimlet sudah tersedia secara default pada instalasi Zimbra.

    Contohnya:

    ZimletFungsi
    URLPreview website
    EmailMenampilkan informasi kontak
    CalendarMembuka jadwal pada tanggal tertentu
    PhoneIntegrasi VoIP
    MapsMembuka lokasi pada peta
    Skype / Zoom (tergantung versi)Membuka aplikasi meeting

    Admin dapat mengaktifkan atau menonaktifkan Zimlet sesuai kebutuhan.


    Jenis-Jenis Zimlet

    Secara umum terdapat beberapa jenis Zimlet.

    1. Content Zimlet

    Jenis ini bekerja dengan mendeteksi pola tertentu pada isi email.

    Misalnya:

    • alamat email
    • URL
    • tanggal
    • nomor telepon
    • alamat fisik

    Kemudian objek tersebut dibuat menjadi interaktif.


    2. Panel Zimlet

    Panel Zimlet muncul pada panel sebelah kiri Zimbra.

    Biasanya digunakan sebagai launcher aplikasi.

    Contohnya:

    • CRM
    • Helpdesk
    • ERP
    • Dashboard internal

    Pengguna dapat melakukan drag-and-drop email ke Panel Zimlet untuk menjalankan aksi tertentu.


    3. Tab Zimlet

    Jenis ini membuat tab baru pada menu utama Zimbra.

    Contohnya:

    Mail
    Calendar
    Contacts
    Tasks
    CRM
    Helpdesk
    Inventory

    Dengan begitu aplikasi perusahaan dapat diakses langsung dari dalam Zimbra.


    4. Integrated Zimlet

    Jenis ini merupakan Zimlet yang terintegrasi lebih dalam dengan antarmuka Zimbra.

    Contohnya:

    • menambahkan tombol baru
    • menambahkan menu klik kanan
    • membuat dialog baru
    • mengubah perilaku UI tertentu

    Jenis ini biasanya digunakan pada implementasi enterprise.


    Struktur Dasar Zimlet

    Sebuah paket Zimlet biasanya didistribusikan dalam bentuk file ZIP yang berisi beberapa komponen.

    Contohnya:

    com_example_demo.zip
    
    ├── com_example_demo.xml
    ├── com_example_demo.js
    ├── com_example_demo.properties
    ├── config_template.xml
    ├── images/
    ├── css/
    └── jsp/

    Penjelasan singkat:

    FileFungsi
    XMLMendefinisikan Zimlet
    JSLogika JavaScript
    JSPKomunikasi server (opsional)
    PropertiesMulti bahasa
    CSSTampilan
    ImagesIkon

    File yang paling penting adalah file XML, karena di sinilah perilaku dasar Zimlet didefinisikan.

    Mengelola Zimlet di Zimbra

    System admin dapat mengelola Zimlet menggunakan utilitas zmzimletctl.

    Melihat daftar Zimlet

    su - zimbra
    
    zmzimletctl listZimlets

    Deploy Zimlet

    zmzimletctl deploy nama-zimlet.zip

    Menonaktifkan Zimlet

    zmzimletctl disable nama_zimlet

    Mengaktifkan kembali

    zmzimletctl enable nama_zimlet

    Menghapus Zimlet

    zmzimletctl undeploy nama_zimlet

    Perintah-perintah tersebut memungkinkan admin mengelola siklus hidup Zimlet langsung dari command line.

    Kesimpulan

    Zimlet merupakan salah satu fitur yang menjadikan Zimbra lebih dari sekadar mail server. Dengan kemampuannya mengintegrasikan email dengan aplikasi dan layanan lain, Zimlet mampu meningkatkan produktivitas pengguna sekaligus menyederhanakan alur kerja di lingkungan perusahaan.

    Bagi system admin, Zimlet dapat dikelola dengan mudah melalui zmzimletctl, sedangkan bagi developer, Zimlet menyediakan kerangka kerja yang fleksibel untuk membangun integrasi dengan berbagai sistem internal maupun layanan pihak ketiga. Memahami konsep dan cara kerja Zimlet menjadi langkah awal yang penting sebelum mulai mengembangkan atau menerapkan integrasi pada lingkungan Zimbra.


    Referensi

    1. Zimbra Wiki – Zimlets
      https://wiki.zimbra.com/wiki/Zimlets
    2. GitHub – Zimbra Zimlet Guide
      Zimbra zm-zimlet-guide Repository
    3. Zimbra Developers Guide (Modern UI Zimlet Development)
      https://wiki.zimbra.com/wiki/DevelopersGuide#Zimlet_Development_Guide
  • 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/
  • Install dan Konfigurasi Postfix di Rocky 9

    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

    ItemNilai
    OSRocky Linux 9
    Hostnamemail.rafi.lab
    Domainrafi.lab
    IP Address192.168.14.4/24
    KebutuhanAkses 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.

  • Latihan Troubleshooting dengan Claude Code

    Latihan Troubleshooting dengan Claude Code

    Jadi hari ini saya mencoba mengasah kemampuan troubleshooting, khususnya pada aplikasi yang dapat diimplementasikan secara on-premise seperti mail server (Zimbra dan Carbonio), platform virtualisasi (Proxmox VE), serta file management (Nextcloud). Menurut saya, kemampuan troubleshooting adalah salah satu keterampilan yang harus terus diasah karena sangat dibutuhkan saat mengelola infrastruktur. Namun, ada satu hal yang sampai sekarang masih sering membuat saya bingung ketika ingin belajar troubleshooting, diantara lain:

    • Saya gonta-ganti konfigurasinya sendiri (oprek)
    • Menunggu ada update/patch/bug terbaru
    • atau, menunggu aplikasi failure/error dengan sendirinya

    Kalau oprek sendiri dengan skill teknis minim seperti saya malah-malah merembet kemana-mana, kalau menunggu update bisa berbulan-bulan, dan apalagi kalau nunggu aplikasi failure nanti malah tidak latihan.

    Masalahnya, menunggu insiden itu tidak efisien. Jadi saya balik logikanya. Saya menjadikan Claude Code untuk merusak lab saya sendiri dengan pola yang realistis, lalu saya yang mendiagnosis dan memperbaiki. Anggap saja latihan tanding, tapi lawannya adalah AI yang paham error apa saja yang biasa terjadi di Proxmox, Nextcloud, Zimbra, atau Carbonio.

    Konsepnya

    Aturannya cuma satu yang penting: Claude berperan sebagai fasilitator, bukan tukang benerin. Tugas dia merusak, memberi gejala, dan memberi petunjuk kalau saya mentok. Yang mendiagnosis dan memperbaiki tetap saya.

    Alurnya kira-kira begini:

    1. Saya pilih platform dan level kesulitan.
    2. Claude menyuntikkan satu fault via SSH, tanpa memberi tahu apa yang dia rusak. (sebenernya mau pake MCP tapi belum paham)
    3. Saya cuma dikasih gejala, seperti tiket dari user. Misalnya “email keluar nyangkut sejak pagi”.
    4. Saya investigasi sendiri. Kalau mentok, boleh minta hint, tapi skornya berkurang.
    5. Setelah saya bilang selesai, Claude verifikasi dan kasih skor.

    Kuncinya ada di poin ketiga. Saya tidak dikasih tahu root cause-nya. Persis seperti simulasi production, saya cuma pegang gejala dan harus menelusuri sendiri sampai ke akar.

    Level 1 sampai 5

    Biar latihannya naik kelas, saya bagi lima level. Makin tinggi, makin dekat ke insiden produksi yang sebenarnya.

    LevelKarakter faultContoh
    1Satu masalah jelas, error terang di logService ke-stop, typo di config
    2Satu masalah, gejala kurang gamblangPort diblok firewall, cert expired
    3Gejala tak langsung lewat dependensiLDAP mati bikin semua auth gagal
    4Cascading, satu akar banyak gejalaDisk penuh, quorum cluster hilang
    5Beberapa masalah sekaligus, butuh metodeFault kombinasi lintas layer

    Level 1 itu pemanasan. Level 5 memaksa saya berpikir sistematis, memisahkan gejala satu per satu, dan menahan diri dari asumsi buru-buru.

    Penutup: Backup, backup, backup

    Sengaja merusak sistem tetap butuh rem. Ada dua aturan yang dibutuhkan

    • Pertama, backup atau snapshot dulu sebelum apa pun.
    • Kedua, kunci jawaban terpisah di folder sementara. Kalau saya baca duluan, latihan jadi percuma. Biar disiplin aja.

    Latihan ini akan dijalankan besok. Stay tune!

  • 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.