Bab 11. Layanan Jaringan: Postfix, Apache, NFS, Samba, Squid, LDAP, SIP, XMPP, TURN

Layanan jaringan adalah program-program yang berinteraksi secara langsung dengan para pengguna dalam pekerjaan mereka sehari-hari. Mereka adalah puncak gunung es sistem informasi, dan bab ini akan memfokuskan pada mereka; bagian tak terlihat tempat mereka bertumpu adalah infrastruktur yang sudah kita terangkan sebelumnya. Mereka biasanya memerlukan teknologi enkripsi yang diuraikan dalam Bagian 10.2, “setifikat X.509”.

11.1. Server Mail

Administrator Falcot Corp memilih Postfix untuk server surel elektroniknya, karena keandalan dan kemudahan konfigurasinya. Memang, desainnya memberlakukan bahwa setiap tugas diimplementasikan dalam sebuah proses dengan seperangkat izin minimum yang dibutuhkan, yang merupakan langkah mitigasi yang besar terhadap masalah keamanan.

ALTERNATIF Server Exim4

Debian menggunakan Exim4 sebagai peladen posel bawaan (instalasi awal menyertakan Exim4). Konfigurasi disediakan oleh paket yang terpisah, exim4-config, dan diatur secara otomatis berdasarkan jawaban dari pertanyaan Debconf yang mirip dengan pertanyaan yang diajukan oleh paket postfix.

Konfigurasi dapat berupa berkas tunggal (/etc/exim4/exim4.conf.template) atau terpecah dalam beberapa potongan konfigurasi tersimpan di bawah /etc/exim4/conf.d/. Keduanya, berkas tersebut digunakan olehperintah update-exim4.conf sebagai palet untuk menghasilkan /var/lib/exim4/config.autogenerated. Yang terakhir adalah berkas yang digunakan oleh Exim4. Berkat mekanisme ini, nilai yang dihasilkan melalui konfigurasi debconf Exim --yang tersimpan dalam /etc/exim4/update-exim4.conf.conf-- dapat disuntikkan ke dalam berkas konfigurasi Exim, bahkan ketika administrator atau paket lain telah mengubah konfigurasi bawaan Exim.

Sintaks berkas konfigurasi Exim4 memiliki kekhasan dan kurva belajarnya; namun, begitu keanehan ini dipahami, Exim4 merupakan peladen surel yang sangat lengkap dan hebat, yang dibuktikan dengan puluhan halaman dokumentasi.

→ https://www.exim.org/docs.html

11.1.1. Instalasi Postfix

Paket postfix menyertakan daemon SMTP utama. Paket lain (seperti postfix-ldap dan postfix-pgsql) menambahkan fungsionalitas ekstra ke Postfix, termasuk mengakses basis data pemetaan. Anda hanya perlu menginstallnya jika Anda tahu Anda memerlukannya.

Beberapa pertanyaan Debconf ditanyakan saat instalasi paket tersebut. Jawabannya memungkinkan menghasilkan versi pertama berkas konfigurasi /etc/postfix/main.cf.

Pertanyaan pertama berkaitan dengan jenis pengaturan. Hanya dua jawaban relevan yang diajukan jika ada server yang tersambung ke internet, "situs internet" dan "internet dengan smarthost". Yang pertama sesuai untuk server yang menerima email masuk dan mengirim email keluar langsung ke penerimanya, dan karenanya cocok untuk kasus Falcot Corp. Yang terakhir ini sesuai untuk server yang menerima email masuk secara normal, namun mengirimkan email keluar melalui server SMTP menengah — ”smarthost” — bukan langsung ke server penerima. Ini sangat berguna bagi individu dengan alamat IP dinamis, karena banyak server email menolak pesan yang datang langsung dari alamat IP semacam itu. Dalam kasus ini, smarthost biasanya adalah SMTP server milik ISP, yang selalu dikonfigurasi untuk menerima email dari pelanggan ISP dan meneruskannya dengan tepat. Pengaturan ini (dengan smarthost) selalu relevan untuk server yang tidak terhubung secara permanen ke internet, karena menghindari harus mengatur antrian pesan tidak terkirim yang perlu dicoba ulang di waktu yang lain.

Pertanyaan kedua berkaitan dengan nama lengkap mesin, digunakan untuk menghasilkan alamat email dari nama pengguna lokal; nama lengkap mesin sebagai bagian setelah simbol-at ("@"). Dalam kasus Falcot, jawabannya seharusnya mail.falcot.com. Pertanyaan ini yang diajukan secara default, namun konfigurasi yang diembannya tidak cukup lengkap untuk kebutuhan Falcot, karenanya administrator menjalankan perintah dpkg-reconfigure postfix agar dapat menyesuaikan lebih banyak parameter.

Salah satu pertanyaan tambahan yang diajukan untuk semua nama domain yang berhubungan dengan mesin. Daftar bawaan yang menyertakan nama lengkapnya sebagaimana sedikit padanan untuk localhost, namun domain utama falcot.com perlu ditambahkan sendiri. Lebih umumnya, pertanyaan ini seharusnya biasanya dijawab dengan seluruh nama domain yang mana mesin ini seharusnya melayani sebagai sebuah MX server; dengan kata lain, seluruh nama domain yang mana disebutkan DNS bahwa mesin ini akan menerima surel. Informasi ini berpangkal pada variabel mydestination pada berkas konfigurasi Postfix — /etc/postfix/main.cf.

Gambar 11.1. Aturan record DNS MX saat mengirimkan surel

Dalam beberapa kasus, instalasi juga dapat meminta jaringan apa yang harus diperbolehkan untuk mengirim surel melalui mesin. Dengan konfigurasi default, Postfix hanya menerima surel yang datang dari mesin itu sendiri; jaringan lokal biasanya akan ditambahkan. Administrator Falcot Corp menambahkan 192.168.0.0/16 ke jawaban default. Jika pertanyaan itu tidak muncul, variabel yang relevan dalam berkas konfigurasi adalah mynetworks, seperti yang terlihat dalam contoh di bawah ini.

Surel lokal juga dapat dikirimkan melalui procmail. Alat ini memungkinkan pengguna untuk memilah surel masuk mereka menurut aturan yang disimpan dalam berkas ~/.procmailrc mereka. Postfix dan Exim4 menyarankan procmail secara baku, tapi ada alternatif seperti maildrop atau filter Sieve.

Setelah langkah pertama ini, para administrator mendapat berkas konfigurasi berikut; ini akan digunakan sebagai titik awal untuk menambahkan beberapa fungsi tambahan di bagian berikutnya.

Contoh 11.1. Berkas/etc/postfix/main.cf awal

# See /usr/share/postfix/main.cf.dist for a commented, more complete version


# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = no

# See http://www.postfix.org/COMPATIBILITY_README.html -- default to 2 on
# fresh installs.
compatibility_level = 2



# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_security_level=may

smtp_tls_CApath=/etc/ssl/certs
smtp_tls_security_level=may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache


smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
myhostname = mail.falcot.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
mydestination = mail.falcot.com, falcot.com, localhost.localdomain, localhost
relayhost = 
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 192.168.0.0/16
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
default_transport = smtp
relay_transport = smtp
inet_protocols = all
myorigin = /etc/mailname

KEAMANAN Sertifikat SSL Snake oil

Sertifikat minyak ular, seperti "obat" minyak ular yang dijual oleh dukun palsu di jaman dahulu, benar-benar tidak memiliki nilai: Anda tidak dapat mengandalkan mereka untuk mengotentikasi server karena mereka sertifikat yang ditandatangani sendiri yang dihasilkan secara otomatis. Namun mereka sangat berguna untuk meningkatkan privasi pertukaran.

Secara umum mereka hanya boleh digunakan untuk tujuan pengujian, dan layanan normal harus menggunakan sertifikat nyata. Inisiatif Let's encrypt menawarkan sertifikat SSL/TLS gratis dan terpercaya, yang dapat dihasilkan menggunakan paket certbot seperti yang dijelaskan dalam Bagian 11.2.2, “Menambahkan dukungan untuk SSL” dan kemudian digunakan dalam postfix seperti ini:

smtpd_tls_cert_file = /etc/letsencrypt/live/DOMAIN/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/DOMAIN/privkey.pem
smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtpd_tls_CApath = /etc/ssl/certs
smtp_tls_CApath = /etc/ssl/certs

Cara lain untuk membuat sertifikat Anda sendiri menggunakan otoritas sertifikat Anda sendiri dijelaskan dalam Bagian 10.2.2, “Infrastruktur Kunci Publik: easy-rsa”.

11.1.2. Mengkonfigurasi Domain Virtual

Server surat dapat menerima surel yang ditujukan kepada domain lain selain domain utama; ini kemudian dikenal sebagai domain "virtual". Dalam kebanyakan kasus di mana hal ini terjadi, surel pada akhirnya tidak ditujukan ke pengguna lokal. Postfix menyediakan dua fitur menarik untuk menangani domain virtual.

11.1.2.1. Domain Alias Virtual

Suatu domain alias virtual hanya berisi alias, yaitu alamat-alamat yang hanya meneruskan surel ke alamat lain.

Domain seperti itu diaktifkan dengan menambahkan nama ke variabel virtual_alias_domains, dan mereferensi berkas pemetaan alamat dalam variabel virtual_alias_maps.

virtual_alias_domains = falcotsbrand.com
virtual_alias_maps = hash:/etc/postfix/virtual

Berkas /etc/postfix/virtual menjelaskan pemetaan dengan sintaks yang agak sederhana: setiap baris berisi dua field yang dipisahkan oleh spasi; field pertama adalah nama alias, field kedua adalah daftar alamat surel tujuan pengalihan. Sintaks khusus @domain.com mencakup semua sisa alias dalam suatu domain.

webmaster@falcotsbrand.com  jean@falcot.com
contact@falcotsbrand.com    laure@falcot.com, sophie@falcot.com
# The alias below is generic and covers all addresses within
# the falcotsbrand.com domain not otherwise covered by this file.
# These addresses forward email to the same user name in the
# falcot.com domain.
@falcotsbrand.com           @falcot.com

Setelah mengubah /etc/postfix/virtual tabel postfix /etc/postfix/virtual.db perlu diperbarui menggunakan sudo postmap /etc/postfix/virtual.

11.1.2.2. Domain Kotak Surat Virtual

Pesan-pesan yang ditujukan ke kotak surat domain virtual disimpan dalam kotak surat yang tidak ditugaskan ke pengguna sistem lokal.

Memfungsikan kotak surat domain virtual memerlukan menamai domain ini dalam variabel virtual_mailbox_domains, dan mereferensi ke berkas pemetaan kotak surat di virtual_mailbox_maps. Parameter virtual_mailbox_base berisi direktori di mana kotak pesan akan disimpan.

virtual_mailbox_domains = falcot.org
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_mailbox_base = /var/mail/vhosts

Parameter virtual_uid_maps (dan virtual_gid_maps) mengacu ke berkas yang berisi pemetaan antara alamat surel dan sistem pengguna (dan kelompok) yang "memiliki" kotak surat yang sesuai. Agar semua kotak surat dimiliki oleh pemilik/kelompok yang sama, sintaks static:5000 menetapkan UID/GID tertentu (yang bernilai 5000 di sini).

Sekali lagi, sintaks berkas /etc/postfix/vmailbox cukup sederhana: dua field dipisahkan dengan spasi. Field pertama adalah alamat surel dalam salah satu domain virtual, dan field kedua adalah lokasi kotak surat yang terkait (relatif terhadap direktori yang ditentukan dalam virtual_mailbox_base). Jika nama kotak surat berakhir dengan garis miring (/), surel akan disimpan dalam format maildir; jika tidak, format tradisional mbox akan digunakan. Format maildir menggunakan seluruh direktori untuk menyimpan kotak surat, masing-masing pesan disimpan dalam berkas terpisah. Dalam format mbox, seluruh kotak surat disimpan dalam satu berkas, dan setiap baris yang dimulai dengan "From " (From diikuti dengan spasi) menandai awal pesan baru.

# Surel Jean disimpan sebagai maildir, dengan
# satu berkas per surel dalam suatu direktori terdedikasi
jean@falcot.org falcot.org/jean/
# Surel Sophie's disimpan dalam suatu berkas "mbox"
# tradisional dengan semua surel disambung ke dalam satu berkas tunggal
sophie@falcot.org falcot.org/sophie

11.1.3. Pembatasan Penerimaan dan Pengiriman

Meningkatnya jumlah surel massal yang tidak diminta (spam) memerlukan menjadi semakin ketat ketika memutuskan surel mana yang mesti diterima oleh server. Bagian ini menyajikan beberapa strategi yang termasuk dalam Postfix.

Jika aturan penolakan terlalu ketat, mungkin terjadi bahkan lalu lintas surel yang sah pun terkunci. Oleh karena itu, merupakan kebiasaan yang baik untuk menguji pembatasan dan mencegah penolakan permanen atas permintaan selama waktu ini menggunakan perintah soft_bounce = yes. Dengan menambahkan direktif tipe tolak dengan warn_if_reject hanya pesan log yang akan direkam daripada menolak permintaan tersebut.

KULTUR Masalah spam

"Spam" adalah istilah umum yang digunakan untuk menamai semua surel komersial yang tidak diinginkan (juga dikenal sebagai UCE) yang membanjiri kotak surat elektronik kita; individu-individu yang tidak bermoral yang mengirim mereka dikenal sebagai spammer. Mereka tidak peduli tentang gangguan yang mereka sebabkan, karena mengirimkan surel biayanya sangat rendah, dan hanya persentase yang sangat kecil dari penerima yang perlu tertarik dengan tawaran agar operasi spam menghasilkan lebih daripada biaya. Prosesnya kebanyakan otomatis, dan alamat surel yang dibuat publik (misalnya, di forum web, atau di arsip milis, atau di blog, dan sebagainya) akan ditemukan oleh robot spammer, dan menjadi sasaran pesan tak diharapkan yang tidak pernah berakhir. Setiap kontak yang ditemukan pada sebuah sistem yang terkompromi juga ditarget.

Semua administrator sistem mencoba untuk menghadapi gangguan dengan filter spam, tapi tentu saja spammer terus menyesuaikan diri dengan mencoba menghindari filter ini. Beberapa bahkan menyewa jaringan mesin yang terkompromi oleh worm dari berbagai sindikat kejahatan. Statistik baru-baru ini memperkirakan bahwa hingga 95% dari semua surel yang beredar di Internet adalah spam!

11.1.3.1. Pembatasan Akses Berbasis IP

Direktif smtpd_client_restrictions mengendalikan mesin mana yang diperbolehkan untuk berkomunikasi dengan server surel.

Ketika suatu variabel berisi daftar aturan, seperti pada contoh di bawah, aturan-aturan ini dievaluasi berurutan, dari pertama sampai terakhir. Setiap aturan dapat menerima pesan, menolak, atau menyerahkan keputusan ke aturan berikutnya. Sebagai akibatnya, urutan penting, dan sekedar mempertukarkan dua aturan dapat menyebabkan perilaku yang sangat berbeda.

Contoh 11.2. Pembatasan Berbasis Alamat Klien

smtpd_client_restrictions =
    permit_mynetworks,
    warn_if_reject reject_unknown_client_hostname,
    check_client_access hash:/etc/postfix/access_clientip,
    reject_rhsbl_reverse_client dbl.spamhaus.org,
    reject_rhsbl_reverse_client rhsbl.sorbs.net,
    reject_rbl_client zen.spamhaus.org,
    reject_rbl_client dnsbl.sorbs.net

Direktif permit_mynetworks, yang digunakan sebagai aturan pertama, menerima semua surel yang datang dari mesin jaringan lokal (seperti yang didefinisikan oleh variabel konfigurasi mynetworks).

Direktif kedua biasanya akan menolak surel yang datang dari mesin tanpa konfigurasi DNS yang sepenuhnya valid. Sebuah konfigurasi yang valid berarti bahwa alamat IP dapat di-resolve ke suatu nama, dan bahwa nama ini, pada gilirannya, di-resolve ke alamat IP. Pembatasan ini sering terlalu ketat, karena banyak server surel yang tidak memiliki reverse DNS untuk alamat IP mereka. Ini menjelaskan mengapa para administrator Falcot mengawali pengubah warn_if_reject ke direktif reject_unknown_client: pengubah ini mengubah penolakan menjadi peringatan sederhana yang tercatat dalam log. Administrator dapat kemudian mengawasi jumlah pesan yang akan ditolak jika aturan yang benar-benar ditegakkan, dan membuat keputusan kemudian jika mereka ingin memberlakukan aturan itu.

TIP tabel access

Kriteria pembatasan termasuk tabel yang dapat dimodifikasi oleh administrator berisi daftar kombinasi pengirim, alamat IP, dan nama host yang diperbolehkan atau dilarang. Tabel ini dapat dibuat memakai salinan berkas /usr/share/doc/postfix/examples/access yang dikirimkan dengan paket postfix-doc dan diuraikan dalam access(5). Model ini didokumentasikan mandiri dalam komentar, yang berarti setiap tabel menjelaskan sintaksnya sendiri.

Tabel /etc/postfix/access_clientip menampung daftar alamat IP dan jaringan; /etc/postfix/access_helo berisi daftar nama domain; /etc/postfix/access_sender berisi alamat surel pengirim. Semua berkas ini harus diubah menjadi tabel hash (format yang dioptimalkan untuk akses cepat) setelah setiap perubahan, dengan perintah sudo postmap /etc/postfix/berkas.

Direktif check_client_access memungkinkan administrator untuk mengatur daftar hitam dan daftar putih server surel, yang disimpan dalam berkas /etc/postfix/access_clientip. Server dalam daftar putih dianggap tepercaya, dan surel yang berasal dari sana oleh karena itu tidak melalui aturan penyaringan berikut.

Empat aturan terakhir menolak pesan yang berasal dari server yang tercantum dalam salah satu blacklist yang ditunjukkan. RBL adalah akronim untuk Remote Black List, dan RHSBL singkatan dari Right-Hand Side Black List. Perbedaannya adalah bahwa yang pertama memuat daftar alamat IP, sedangkan yang kedua memuat daftar nama domain. Ada beberapa layanan seperti itu. Mereka membuat daftar domain dan alamat IP dengan reputasi buruk, server-server yang dikonfigurasi secara buruk yang dipakai oleh spammer untuk me-relay surel mereka, maupun pe-relay surel yang tak terduga seperti mesin-mesin yang terinfeksi worm atau virus.

11.1.3.2. Memeriksa Validitas Perintah `EHLO` atau `HELO`

Setiap pertukaran SMTP dimulai dengan perintah HELO (atau EHLO), diikuti dengan nama server surel pengirim. Memeriksa validitas nama ini bisa menarik. Untuk sepenuhnya menegakkan pembatasan yang tercantum dalam smtpd_helo_restrictions opsi smtpd_helo_required perlu diaktifkan. Jika tidak, klien dapat melewati pembatasan dengan tidak mengirimkan perintah HELO/EHLO.

Contoh 11.3. Pembatasan pada nama yang diumumkan di EHLO

smtpd_helo_required = yes
smtpd_helo_restrictions =
    permit_mynetworks,
    reject_invalid_helo_hostname,
    reject_non_fqdn_helo_hostname,
    warn_if_reject reject_unknown_helo_hostname,
    check_helo_access hash:/etc/postfix/access_helo,
    reject_rhsbl_helo multi.surbl.org

Direktir permit_mynetworks pertama memungkinkan semua mesin di jaringan lokal untuk memperkenalkan diri dengan bebas. Hal ini penting, karena beberapa program email tidak menghormati bagian dari protokol SMTP ini secara cukup memadai, dan mereka dapat memperkenalkan diri dengan nama-nama yang tidak masuk akal.

Aturan reject_invalid_helo_hostname menolak surel ketika EHLO mengumumkan daftar nama host yang secara sintaksis salah. Aturan reject_non_fqdn_helo_hostname menolak pesan ketika nama host yang diumumkan bukan fully-qualified domain name (yang memuat nama domain maupun nama host). Aturan reject_unknown_helo_hostname menolak pesan jika nama yang diumumkan tidak ada di DNS. Karena aturan terakhir ini sayangnya mengarah ke penolakan yang terlalu banyak, para administrator mengubah efeknya menjadi peringatan sederhana dengan pengubah warn_if_reject sebagai langkah pertama; mereka mungkin memutuskan untuk menghapus pengubah ini pada tahap berikutnya, setelah audit hasil peraturan ini.

reject_rhsbl_helo memungkinkan untuk menentukan daftar hitam untuk memeriksa nama host terhadap RHSBL.

Menggunakan permit_mynetworks sebagai aturan pertama memiliki efek samping yang menarik: aturan berikutnya hanya diterapkan ke host di luar jaringan lokal. Hal ini memungkinkan mencekal semua host yang mengumumkan diri mereka sebagai bagian dari jaringan falcot.com, misalnya dengan menambahkan baris falcot.com REJECT Anda tidak berada dalam jaringan kami! ke dalam berkas / postfix/dll/access_helo.

11.1.3.3. Menerima atau Menolak Berdasarkan Pengirim yang Diumumkan

Setiap pesan memiliki pengirim, diumumkan oleh perintah MAIL FROM dari protokol SMTP; sekali lagi, informasi ini dapat divalidasi dalam beberapa cara yang berbeda.

Contoh 11.4. Pemeriksaan pengirim

smtpd_sender_restrictions =
    check_sender_access hash:/etc/postfix/access_sender,
    reject_unknown_sender_domain,
    reject_unlisted_sender,
    reject_non_fqdn_sender,
    reject_rhsbl_sender rhsbl.sorbs.net

Tabel /etc/postfix/access_sender memetakan beberapa perlakuan khusus untuk beberapa pengirim. Ini biasanya berarti memasukkan beberapa pengirim ke daftar putih atau daftar hitam.

Aturan reject_unknown_sender_domain memerlukan domain pengirim yang valid, karena dibutuhkan untuk alamat yang valid. Aturan reject_unlisted_sender menolak pengirim lokal jika alamat tidak ada; hal ini mencegah surel dari yang dikirim dari alamat yang tidak valid dalam domain falcot.com, dan pesan yang berasal dari joe.bloggs@falcot.com hanya diterima jika alamat tersebut benar-benar ada.

Akhirnya, aturan reject_non_fqdn_sender menolak surel yang mengaku berasal dari alamat tanpa fully-qualified domain name. Dalam prakteknya, ini berarti menolak surel yang datang dari user@machine: alamat harus diumumkan sebagai user@machine.example.com atau user@example.com.

Aturan reject_rhsbl_sender menolak pengirim berdasarkan layanan RHSBL (berbasis domain).

11.1.3.4. Menerima atau Menolak Berdasarkan Penerima

Setiap surel yang memiliki minimal satu penerima, diumumkan dengan perintah RCPT TO dalam protokol SMTP. Alamat ini juga memerlukan validasi, bahkan jika itu mungkin kurang relevan daripada pemeriksaan atas alamat pengirim.

Contoh 11.5. Pemeriksaan penerima

smtpd_recipient_restrictions =
    permit_mynetworks,
    reject_unauth_destination,
    reject_unlisted_recipient,
    reject_non_fqdn_recipient,
    permit

reject_unauth_destination adalah aturan dasar yang mempersyaratkan pesan dari luar ditujukan kepada kami; pesan yang dikirim ke alamat yang tidak dilayani oleh server ini akan ditolak. Tanpa aturan ini, server menjadi relay terbuka yang memungkinkan spammer untuk mengirim surel yang tidak diinginkan; aturan ini wajib, dan itu paling baik disertakan di bagian awal dari daftar, sehingga tidak ada aturan lainnya mungkin mengotorisasi pesan sebelum tujuan telah diperiksa.

Aturan reject_unlisted_recipient menolak pesan yang dikirim ke pengguna lokal yang tidak ada. Ini masuk akal. Akhirnya, aturan reject_non_fqdn_recipient menolak alamat yang bukan fully-qualified; ini menjadikannya mustahil untuk mengirim surel ke jean atau jean@machine, dan memerlukan menggunakan alamat lengkap, seperti jean@machine.falcot.com atau jean@falcot.com.

Arahan permit di akhir tidak diperlukan. Tapi bisa berguna di akhir daftar batasan untuk membuat kebijakan default eksplisit.

11.1.3.5. Pembatasan Terkait dengan Perintah `DATA`

Perintah DATA SMTP dikirimkan sebelum isi pesan. Tidak memberikan informasi apapun per se, selain mengumumkan apa yang datang berikutnya. Masih bisa dipersyaratkan untuk pemeriksaan.

Contoh 11.6. Pemeriksaan DATA

smtpd_data_restrictions = reject_unauth_pipelining

Direktif reject_unauth_pipelining menyebabkan pesan ditolak jika pihak pengirim mengirim perintah sebelum balasan atas perintah sebelumnya dikirim. Ini penjaga terhadap optimasi yang umum digunakan oleh robot spammer, karena mereka biasanya tidak peduli isi balasan dan fokus hanya pada mengirim surel sebanyak mungkin dalam waktu sependek mungkin.

11.1.3.6. Menerapkan Pembatasan

Meskipun perintah di atas memvalidasi informasi di berbagai tahap pertukaran SMTP, Postfix mengirimkan penolakan sebenarnya sebagai jawaban atas perintah RCPT TO secara baku.

Ini berarti bahwa bahkan jika pesan tersebut ditolak karena perintah EHLO yang tidak valid, Postfix tahu pengirim dan penerima ketika mengumumkan penolakan. Ini kemudian mencatat log pesan yang lebih eksplisit daripada yang bisa dilakukan jika transaksi telah terputus dari awal. Selain itu, sejumlah klien SMTP tidak mengharapkan kegagalan pada perintah SMTP awal, dan klien ini akan kurang terganggu oleh penolakan akhir ini.

Keuntungan akhir pilihan ini adalah bahwa aturan dapat mengumpulkan informasi selama berbagai tahap pertukaran SMTP; hal ini memungkinkan mendefinisikan izin lebih halus, seperti menolak koneksi non-lokal jika itu mengumumkan dirinya dengan pengirim lokal.

Perilaku default dikendalikan oleh aturan smtpd_delay_reject.

11.1.3.7. Penyaringan Berdasarkan Isi Pesan

Sistem validasi dan pembatasan tidak akan lengkap tanpa cara untuk menerapkan pemeriksaan ke isi pesan. Postfix membedakan pemeriksaan yang berlaku ke header surel dari mereka yang berlaku ke tubuh surel.

Contoh 11.7. Memfungsikan penyaring berbasis konten

header_checks = regexp:/etc/postfix/header_checks
body_checks = regexp:/etc/postfix/body_checks

Kedua berkas berisi daftar ekspresi reguler (umumnya dikenal sebagai regexps atau regexes) dan tindakan menjadi dipicu ketika header surel (atau tubuh) cocok dengan ekspresi yang terkait.

Contoh 11.8. Berkas contoh /etc/postfix/header_checks

/^X-Mailer: GOTO Sarbacane/ REJECT I fight spam (GOTO Sarbacane)
/^Subject: *Your email contains VIRUSES/ DISCARD virus notification

KEMBALI KE DASAR Ekspresi reguler

Istilah ekspresi reguler (disingkat menjadi regexp atau regex) mengacu ke notasi generik untuk mengekspresikan deskripsi dari isi dan/atau struktur serangkaian karakter. Karakter khusus tertentu memungkinkan mendefinisikan alternatif (misalnya, foo|bar cocok dengan "foo" atau "bar"), set karakter yang diizinkan (misalnya, [0-9] berarti "sebarang digit", dan . — dot — berarti "sebarang karakter"), kuantifikasi (s? cocok dengan s atau string kosong, dengan kata lain 0 atau 1 kali munculnya s; s+ cocok dengan satu atau lebih karakter s berturut-turut; dan seterusnya). Kurung memungkinkan pengelompokan hasil pencarian.

Sintaks yang tepat dari ungkapan-ungkapan ini bervariasi di seluruh alat yang menggunakan mereka, tapi fitur dasarnya sama.

→ https://en.wikipedia.org/wiki/Regular_expression

Yang pertama memeriksa header yang menyebutkan perangkat lunak surel; jika GOTO Sarbacane (software surel massal) ditemukan, pesan tersebut akan ditolak. Ekspresi kedua mengendalikan subjek pesan; jika itu menyebutkan pemberitahuan virus, kita bisa memutuskan untuk tidak menolak pesan tetapi untuk membuangnya segera sebagai gantinya.

Menggunakan filter ini adalah pedang bermata dua, karena mudah untuk membuat aturan yang terlalu generik dan kehilangan surel yang sah sebagai akibatnya. Dalam kasus ini, tidak hanya pesan akan hilang, tapi pengirimnya akan mendapatkan pesan kesalahan yang tidak diinginkan (dan menjengkelkan).

11.1.4. Menyiapkan greylisting

"Greylisting" adalah teknik penyaringan yang pesan awalnya ditolak dengan kode kesalahan sementara, dan hanya diterima pada percobaan lebih lanjut setelah penundaan. Hal ini sangat efisien terhadap spam yang dikirim oleh banyak mesin yang terinfeksi oleh virus dan worm karena software ini jarang bertindak sebagai agen SMTP penuh (dengan memeriksa kode kesalahan dan mencoba kembali pesan gagal kemudian), terutama karena banyak dari alamat yang dipanen sebenarnya tidak sah dan mencoba kembali berarti kehilangan waktu.

Postfix tidak menyediakan greylist secara native, tapi ada fitur dimana keputusan untuk menerima atau menolak pesan tertentu dapat diserahkan ke program eksternal. Paket postgrey memuat program seperti itu, dirancang untuk berinteraksi dengan layanan delegasi kebijakan akses ini.

Setelah postgrey terinstal, itu berjalan sebagai daemon dan mendengarkan pada port 10023. Postfix kemudian dapat dikonfigurasi untuk menggunakannya, dengan menambahkan parameter check_policy_service sebagai pembatasan tambahan:

smtpd_recipient_restrictions =
    permit_mynetworks,
    [...]
    check_policy_service inet:127.0.0.1:10023

Setiap kali Postfix mencapai aturan ini dalam set aturan, itu akan menyambung ke daemon postgrey dan mengirim informasi mengenai pesan yang relevan. Pada sisinya, Postgrey mempertimbangkan triplet alamat IP/pengirim/penerima dan memeriksa basis data apakah triplet yang sama telah terlihat baru-baru ini. Jika demikian, Postgrey menjawab bahwa pesan harus diterima; jika tidak, jawaban menunjukkan bahwa pesan harus ditolak untuk sementara, dan triplet dicatat dalam basis data.

Kelemahan utama dari greylist adalah bahwa pesan yang sah tertunda, yang tidak selalu bisa diterima. Hal ini juga meningkatkan beban pada server yang mengirim banyak surel yang sah.

DALAM PRAKTEK Kekurangan dari greylisting

Secara teori, greylist hanya harus menunda surat pertama dari pengirim yang diberikan kepada penerima tertentu, dan penundaan umumnya dalam orde menit. Kenyataannya, bagaimanapun, dapat sedikit berbeda. Beberapa ISP besar menggunakan cluster server SMTP, dan ketika pesan awalnya ditolak, server yang mencoba ulang transmisi mungkin tidak akan sama seperti yang pertama. Ketika itu terjadi, kedua server mendapat pesan kesalahan sementara karena greylist, dan seterusnya; mungkin butuh beberapa jam sampai transmisi ini dicoba oleh server yang sudah telah terlibat, karena server SMTP biasanya meningkatkan penundaan antara pengulangan di setiap kegagalan.

Sebagai akibatnya, alamat IP yang masuk dapat bervariasi dengan berjalannya waktu bahkan untuk pengirim tunggal. Tapi lebih jauh lagi: bahkan alamat pengirim dapat berubah. Sebagai contoh, banyak milis server menyandikan tambahan informasi dalam alamat pengirim untuk dapat menangani pesan kesalahan (dikenal sebagai bounces). Setiap pesan baru yang dikirim ke milis kemudian mungkin perlu pergi melalui greylist, yang berarti itu harus disimpan (secara sementara) pada server pengirim. Untuk milis yang sangat besar (dengan puluhan ribu pelanggan), ini dapat segera menjadi masalah.

Untuk memitigasi kelemahan ini, Postgrey mengelola daftar putih dari situs-situs seperti itu, dan pesan yang berasal dari mereka segera diterima tanpa melalui greulist. Daftar ini dengan mudah dapat disesuaikan dengan kebutuhan lokal, karena disimpan dalam berkas /etc/postgrey/whitelist_clients.

LEBIH LANJUT Greylisting selektif dengan milter-greylist

Kelemahan dari greylist dapat dimitigsai dengan hanya menggunakan greylist pada subset dari klien yang sudah dianggap sebagai kemungkinan sumber spam (karena mereka tercantum dalam daftar hitam DNS). Hal ini tidak mungkin dengan postgrey tapi milter-greylist dapat digunakan dengan cara itu.

Dalam skenario itu, karena blacklist DNS tidak pernah memicu penolakan definitif, menjadi masuk akal untuk menggunakan blacklist agresif, termasuk daftar semua alamat IP dinamis dari klien ISP (seperti pbl.spamhaus.org atau dul.dnsbl.Sorbs.net).

Karena milter-greylist menggunakan antarmuka milter Sendmail, konfigurasi sisi postfix-nya terbatas ke "smtpd_milters = unix:/var/run/milter-greylist/milter-greylist.sock". Halaman manual greylist.conf(5) mendokumentasikan /etc/milter-greylist/greylist.conf dan banyak cara untuk mengkonfigurasi milter-greylist. Anda juga harus menyunting /etc/default/milter-greylist untuk benar-benar mengaktifkan layanan.

11.1.5. Mengubah Filter Berdasarkan Penerima

Bagian 11.1.3, “Pembatasan Penerimaan dan Pengiriman” dan Bagian 11.1.4, “Menyiapkan greylisting” meninjau banyak kemungkinan pembatasan. Mereka semua memiliki kegunaan dalam membatasi jumlah spam yang diterima, tetapi mereka semua juga memiliki kelemahan. Maka semakin umum untuk menyesuaikan set filter tergantung pada penerima. Pada Falcot Corp, greylist menarik bagi sebagian pengguna, tapi mengganggu pekerjaan beberapa pengguna yang membutuhkan latensi rendah dalam surel mereka (seperti layanan dukungan teknis). Demikian pula, layanan komersial kadang-kadang memiliki masalah menerima surel dari beberapa penyedia Asia yang mungkin tercantum di daftar hitam; layanan ini meminta alamat tak tersaring untuk bisa berkorespondensi.

Postfix menyediakan kustomisasi filter dengan konsep "kelas pembatasan". Kelas dideklarasikan dalam parameter smtpd_restriction_classes, dan didefinisikan dengan cara yang sama sebagai smtpd_recipient_restrictions. Direktif check_recipient_access kemudian mendefinisikan tabel pemetaan penerima tertentu untuk seperangkat batasan.

Contoh 11.9. Mendefinisikan kelas pembatasan dalam main.cf

smtpd_restriction_classes = greylisting, aggressive, permissive

greylisting = check_policy_service inet:127.0.0.1:10023
aggressive =
        reject_rbl_client sbl-xbl.spamhaus.org,
        check_policy_service inet:127.0.0.1:10023
permissive = permit

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

Contoh 11.10. Berkas /etc/postfix/recipient_access

# Unfiltered addresses
postmaster@falcot.com  permissive
support@falcot.com     permissive
sales-asia@falcot.com  permissive

# Aggressive filtering for some privileged users
joe@falcot.com         aggressive

# Special rule for the mailing-list manager
sympa@falcot.com       reject_unverified_sender

# Greylisting by default
falcot.com             greylisting

11.1.6. Mengintegrasikan Filter Antivirus

Banyak virus yang beredar sebagai lampiran surel membuat penting untuk meyiapkan anti virus di titik entri jaringan perusahaan, karena meskipun sudah ada kampanye kesadaran, beberapa pengguna masih akan membuka lampiran dari pesan yang jelas-jelas mencurigakan.

KEAMANAN Diskusi Kontroversial tentang Perangkat Lunak Anti Virus

Penggunaan pemindai virus, atau yang disebut perangkat lunak anti virus, itu kontroversial. Biasanya ada kesenjangan antara rilis beberapa bagian dari malware dan penambahan aturan deteksi ke basis data anti virus. Selama kesenjangan ini, tidak ada perlindungan berbasis perangkat lunak. Lebih lanjut, penggunaan sering diperlukan untuk menjalankan perangkat lunak tambahan, misalnya, untuk uncompress arsip dan memindai semua jenis executable, yang secara drastis meningkatkan potensi mengeksploitasi perangkat lunak anti virus itu sendiri. Penggunaan solusi perangkat lunak tersebut untuk itu tidak pernah dapat menggantikan kampanye kesadaran dan aturan perilaku sederhana (tidak pernah membuka lampiran terkirim yang tidak diminta, dll.).

Administrator Falcot memilih clamav dari paket homonim.

Tugas antarmuka antara antivirus dan server surel jatuh ke clamav-milter. milter (singkatan dari mail filter) adalah sebuah program penyaringan yang dirancang khusus untuk menyambung dengan server surel. Suatu milter menggunakan standar antarmuka pemrograman aplikasi (API) yang memberikan kinerja lebih baik daripada filter eksternal ke server surel. Milters awalnya diperkenalkan oleh Sendmail, tetapi Postfix segera mengikutinya.

Setelah paket clamav-milter diinstal, milter harus ditata ulang untuk berjalan pada sebuah port TCP bukan pada named socket yang default. Hal ini dapat dicapai dengan dpkg-reconfigure clamav-milter. Ketika diminta untuk "Antarmuka komunikasi dengan Sendmail", jawablah "inet:10002@127.0.0.1".

Konfigurasi ClamAV standar cocok untuk kebanyakan situasi, tetapi beberapa parameter penting masih dapat disesuaikan dengan dpkg-reconfigure clamav-base.

Langkah terakhir melibatkan meemberitahu Postfix untuk menggunakan filter yang baru-baru ini dikonfigurasi. Ini bisa dilakukan sekedar dengan menambahkan direktif berikut untuk /etc/postfix/main.cf:

# Virus check with clamav-milter
smtpd_milters = inet:[127.0.0.1]:10002

Jika antivirus menyebabkan masalah, baris ini dapat dijadikan komentar dan systemctl reload postfix harus dijalankan sehingga perubahan ini diperhitungkan.

DALAM PRAKTEK Menguji antivirus

Setelah antivirus disiapkan, perilaku yang benar harus diuji. Cara termudah untuk melakukannya adalah dengan mengirim surel percobaan dengan lampiran yang berisi berkas eicar.com (atau eicar.com.zip), yang dapat diunduh secara daring:

→ https://2016.eicar.org/86-0-Intended-use.html

Berkas ini bukan virus yang benar, tetapi berkas uji yang didiagnosa sebagai sebuah virus oleh semua perangkat lunak antivirus di pasar agar memungkinkan memeriksa instalasi.

Semua pesan yang ditangani oleh Postfix sekarang pergi melalui saringan antivirus.

11.1.7. Melawan Spam dengan SPF, DKIM dan DMARC

Tingginya jumlah surel yang tidak diminta yang dikirim setiap hari mengarah pada pembuatan beberapa standar, yang bertujuan untuk memvalidasi bahwa host pengirim surel diotorisasi dan bahwa surel tersebut belum dirusak. Sistem berikut semuanya berbasis DNS dan mengharuskan administrator untuk tidak hanya memiliki kendali atas server surel, tetapi juga atas DNS untuk domain yang dipermasalahkan.

HATI-HATI Diskusi Kontroversial

Seperti alat lainnya, standar berikut memiliki batasan dan efek nyata jika digunakan. Mereka dapat (dan seharusnya) menyebabkan surel ditolak atau bahkan dibuang begitu saja. Jika itu terjadi pada beberapa surel yang sah (terkadang dikirim dari server SMTP yang salah konfigurasi), biasanya hal itu menyebabkan kemarahan dan kurangnya pemahaman pengguna. Oleh karena itu, aturan ini sering kali diterapkan sebagai "kegagalan ringan" atau "penolakan ringan", yang biasanya berarti bahwa gagal dalam pemeriksaan hanya akan menyebabkan penambahan tanda (header) ke surel yang terpengaruh. Ada orang yang berpikir bahwa ini membuat standar ini "rusak sejak disain". Putuskan sendiri dan berhati-hatilah tentang seberapa ketat Anda memilih untuk menerapkan standar ini.

11.1.7.1. Mengintegrasikan Sender Policy Framework (SPF)

Sender Policy Framework (SPF) digunakan untuk memvalidasi jika server surel tertentu diizinkan untuk mengirim surel untuk domain yang diberikan. Hal ini sebagian besar dikonfigurasi melalui DNS. Sintaks untuk entri untuk membuat dijelaskan secara rinci di:

→ http://www.open-spf.org/SPF_Record_Syntax

→ https://tools.ietf.org/html/rfc7208

→ https://en.wikipedia.org/wiki/Sender_Policy_Framework

Berikut ini adalah contoh entri DNS yang menyatakan bahwa semua domain Mail Exchange Resource Records (MX-RR) diperbolehkan untuk surel domain saat ini, dan semua yang lain dilarang. Entri DNS tidak perlu diberi nama. Tetapi untuk menggunakan direktif include itu harus memilikinya.

Name: example.org
Type: TXT
TTL:  3600
Data: v=spf1 a mx -all

Mari kita lihat entri falcot.org.

# host -t TXT falcot.org
falcot.org descriptive text "v=spf1 ip4:199.127.61.96 +a +mx +ip4:206.221.184.234 +ip4:209.222.96.251 ~all"

Ini menyatakan bahwa IP pengirim harus cocok dengan record A untuk domain pengiriman, atau harus terdaftar sebagai salah satu Mail Exchange Resource Records untuk domain saat ini, atau harus menjadi salah satu dari tiga alamat IP4 yang disebutkan. Semua host lain harus ditandai sebagai tidak diizinkan untuk mengirim surel untuk domain pengirim. Yang terakhir disebut "soft fail" dan dimaksudkan untuk menandai surel yang sesuai, tetapi masih menerimanya.

Server surel postfix dapat memeriksa data SPF untuk surel masuk menggunakan paket postfix-policyd-spf-python, agen kebijakan yang ditulis dalam Python. Berkas /usr/share/doc/postfix-policyd-spf-python/README. Debian menjelaskan langkah-langkah yang diperlukan untuk mengintegrasikan agen ke dalam postfix, jadi kami tidak akan mengulanginya di sini.

Konfigurasi dilakukan dalam berkas /etc/postfix-policyd-spf-python/policyd-spf.conf, yang sepenuhnya didokumentasikan dalam policyd-spf.conf(5) dan /usr/share/doc/postfix-policyd-spf-python/policyd-spf.conf.commented.gz. Parameter konfigurasi utama adalah HELO_reject dan Mail_From_reject, yang mengkonfigurasi apakah surel harus ditolak (Fail) atau diterima dengan header yang ditambah (False), jika pemeriksaan gagal. Yang terakhir ini sering berguna, ketika pesan diproses lebih lanjut oleh filter spam.

Jika hasilnya dimaksudkan untuk digunakan oleh opendmarc (Bagian 11.1.7.3, “Mengintegrasikan Domain-based Message Authentication, Reporting and Conformance (DMARC)”), maka Header_Type harus diatur ke AR.

Perhatikan bahwa spamassassin memuat suatu plugin untuk memeriksa record SPF.

11.1.7.2. Mengintegrasikan DomainKeys (DKIM) Penandatanganan dan Pemeriksaan

Standar Domain Keys Identified Mail (DKIM) adalah sistem otentikasi pengirim. Agen transpor surat, di sini postfix, menambahkan tanda tangan digital yang terkait dengan nama domain ke header surel keluar. Pihak penerima dapat memvalidasi bidang badan pesan dan header dengan memeriksa tanda tangan terhadap kunci publik, yang diperoleh dari catatan DNS pengirim.

→ http://dkim.org/

Alat-alat yang diperlukan dikemas dalam paket opendkim dan opendkim-tools.

Pertama, kunci privat harus dibuat menggunakan perintah opendkim-genkey -s SELECTOR -d DOMAIN. SELECTOR harus merupakan nama unik untuk kunci tersebut. Ini bisa sekadar "mail" atau tanggal pembuatan, jika Anda berencana untuk merotasi kunci.

Contoh 11.11. Membuat sebuah kunci privat untuk menandatangani Surel dari falcot.com

# opendkim-genkey -s mail -d falcot.com -D /etc/dkimkeys
# chown opendkim.opendkim /etc/dkimkeys/mail.*

Ini akan membuat berkas /etc/dkimkeys/mail.private dan /etc/dkimkeys/mail.txt dan mengatur kepemilikan yang sesuai. Berkas pertama berisi kunci pribadi, dan yang terakhir adalah kunci publik yang perlu ditambahkan ke DNS:

Name: mail._domainkey
Type: TXT
TTL:  3600
Data: "v=DKIM1; h=sha256; k=rsa; s=email; p=[...]"

Paket opendkim di Debian secara default memiliki ukuran kunci 2048 bit. Sayangnya beberapa server DNS hanya dapat menangani entri teks dengan panjang maksimum 255 karakter, yang dilampaui oleh ukuran kunci default yang dipilih. Dalam hal ini gunakan opsi -b 1024 untuk memilih ukuran kunci yang lebih kecil. Jika opendkim-testkey berhasil, entri telah berhasil disiapkan. Sintaks dari entri tersebut dijelaskan di sini:

→ https://tools.ietf.org/html/rfc6376

→ https://en.wikipedia.org/wiki/DKIM

Untuk mengkonfigurasi opendkim, SOCKET dan RUNDIR harus dipilih di /etc/default/opendkim. Harap dicatat bahwa SOCKET harus dapat diakses dari postfix di lingkungan chroot-nya. Konfigurasi lebih lanjut dilakukan di /etc/opendkim.conf. Berikut ini adalah kutipan konfigurasi, yang memastikan bahwa Domain "falcot.com" dan semua subdomain (SubDomain) ditandatangani oleh Selector "mail" dan kunci privat tunggal (KeyFile) /etc/dkimkeys/mail.private. Canonicalization "relaxed" baik untuk header dan body mentolerir modifikasi ringan (oleh perangkat lunak milis, misalnya). Filter berjalan baik dalam Mode penandatanganan ("s") dan verifikasi ("v"). Jika tanda tangan gagal untuk memvalidasi (On-BadSignature), surat harus dikarantina ("q").

[...]
Domain                  falcot.com
KeyFile                 /etc/dkimkeys/mail.private
Selector                mail

[...]
Canonicalization        relaxed/relaxed
Mode                    sv
On-BadSignature         q
SubDomains              yes

[...]
Socket                  inet:12345@localhost

[...]
UserID                  opendkim

Dimungkinkan juga untuk menggunakan beberapa pemilih/kunci (KeyTable), domain (SigningTable), dan untuk menentukan host internal atau terpercaya (InternalHosts, ExternalIgnoreList), yang dapat mengirim surel melalui server sebagai salah satu domain penandatanganan tanpa kredensial.

Direktif berikut dalam /etc/postfix/main.cf membuat postfix memakai filter:

milter_default_action = accept
non_smtpd_milters = inet:localhost:12345
smtpd_milters = inet:localhost:12345

Untuk membedakan penandatanganan dan verifikasi, terkadang lebih berguna untuk menambahkan arahan ke layanan di /etc/postfix/master.cf sebagai gantinya.

Informasi lebih lanjut tersedia di direktori /usr/share/doc/opendkim/ dan halaman manual opendkim(8) dan opendkim.conf(5).

Perhatikan bahwa spamassassin memuat suatu plugin untuk memeriksa record DKIM.

11.1.7.3. Mengintegrasikan Domain-based Message Authentication, Reporting and Conformance (DMARC)

Standar Domain-based Message Authentication, Reporting and Conformance (DMARC) dapat digunakan untuk menentukan entri DNS TXT dengan nama _dmarc dan tindakan yang harus diambil ketika surel yang berisi domain Anda sebagai host pengirim gagal divalidasi menggunakan DKIM dan SPF.

→ https://dmarc.org/overview/

Mari kita lihat entri dari dua penyedia besar:

# host -t TXT _dmarc.gmail.com
_dmarc.gmail.com descriptive text "v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com"
# host -t TXT _dmarc.yahoo.com
_dmarc.yahoo.com descriptive text "v=DMARC1; p=reject; pct=100; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com;"

Yahoo memiliki kebijakan yang ketat untuk reject semua surel yang berpura-pura dikirim dari akun Yahoo tetapi kekurangan atau gagal pemeriksaan DKIM dan SPF. Google Mail (Gmail) menyebarkan kebijakan yang sangat santai, di mana pesan tersebut dari domain utama masih harus diterima (p=none). Untuk subdomain, mereka harus ditandai sebagai spam (sp=quarantine). Alamat yang diberikan dalam kunci rua dapat digunakan untuk mengirim laporan DMARC gabungan. Sintaks lengkap dijelaskan di sini:

→ https://tools.ietf.org/html/rfc7489

→ https://en.wikipedia.org/wiki/DMARC

Server surat postfix dapat menggunakan informasi ini juga. Paket opendmarc berisi milter yang diperlukan. Mirip dengan opendkim SOCKET dan RUNDIR harus dipilih di /etc/default/opendmarc (untuk soket Unix Anda harus memastikan bahwa mereka berada di dalam chroot postfix untuk ditemukan). Berkas konfigurasi /etc/opendmarc.conf berisi komentar rinci dan juga dijelaskan di opendmarc.conf(5). Secara default, surel yang gagal dalam validasi DMARC tidak ditolak tetapi ditandai, dengan menambahkan kolom header yang sesuai. Untuk mengubahnya, gunakan RejectFailures true.

Milter kemudian ditambahkan ke smtpd_milters dan non_smtpd_milters. Jika kita mengkonfigurasi milter opendkim dan opendmarc untuk berjalan pada port 12345 dan 54321, entri di /etc/postfix/main.cf terlihat seperti ini:

non_smtpd_milters = inet:localhost:12345,inet:localhost:54321
smtpd_milters = inet:localhost:12345,inet:localhost:54321

Milter juga dapat diterapkan secara selektif ke suatu layanan dalam /etc/postfix/master.cf sebagai pengganti.

11.1.8. SMTP Terotentikasi

Mampu mengirim surel memerlukan server SMTP yang dapat dijangkau; ini juga memerlukan server SMTP untuk mengirim surel melalui itu. Untuk pengguna roaming, ini mungkin memerlukan secara teratur mengubah konfigurasi klien SMTP, karena server SMTP Falcot's menolak pesan yang datang dari alamat IP yang tampaknya bukan milik perusahaan. Ada dua solusi: pengguna roaming menginstal server SMTP pada komputer mereka atau mereka masih menggunakan server perusahaan dengan beberapa cara untuk otentikasi sebagai karyawan. Solusi pertama tidak dianjurkan karena komputer tidak akan dihubungkan secara permanen, dan tidak akan dapat mengulangi pengiriman pesan jika terjadi masalah; kita akan fokus pada solusi yang terakhir.

Otentikasi SMTP di Postfix mengandalkan SASL (Simple Authentication and Security Layer). Hal ini membutuhkan instalasi paket libsasl2-modules dan sasl2-bin, kemudian mendaftarkan suatu kata sandi di basis data SASL untuk setiap pengguna yang memerlukan otentikasi pada server SMTP. Hal ini dilakukan dengan perintah saslpasswd2, yang memerlukan beberapa parameter. Opsi -U mendefinisikan domain otentikasi, yang harus cocok dengan parameter smtpd_sasl_local_domain dalam konfigurasi Postfix. Opsi -C memungkinkan membuat pengguna, dan -f menetapkan berkas yang akan dipakai jika basis data SASL perlu disimpan di lokasi yang berbeda dari default (/etc/sasldb2).

# saslpasswd2 -u `postconf -h myhostname` -f /var/spool/postfix/etc/sasldb2 -c jean
[... ketikkan kata sandi jean dua kali ...]

Perhatikan bahwa basis data SASL dibuat dalam direktori milik Postfix. Untuk memastikan konsistensi, kita juga mengubah /etc/sasldb2 menjadi link simbolik menunjuk pada basis data yang digunakan oleh Postfix, dengan perintah ln -sf /var/spool/postfix/etc/sasldb2 /etc/sasldb2.

Sekarang kita perlu mengkonfigurasi Postfix agar menggunakan SASL. Pertama pengguna postfix perlu ditambahkan ke grup sasl, sehingga dapat mengakses basis data akun SASL. Beberapa parameter baru juga diperlukan untuk mengaktifkan SASL, dan parameter smtpd_recipient_restrictions perlu dikonfigurasi untuk memungkinkan kilen terotentikasi-SASL untuk mengirim surel dengan bebas.

Contoh 11.12. Memfungsikan SASL di /etc/postfix/main.cf

# Memfungsikan otentikasi SASL
smtpd_sasl_auth_enable = yes
# Define the SASL authentication domain to use
smtpd_sasl_local_domain = $myhostname
[...]
# Menambahkan permit_sasl_authenticated before reject_unauth_destination
# mengizinkan merelay surel yang dikirim oleh pengguna SASL-authenticated
smtpd_recipient_restrictions = 
    permit_sasl_authenticated,
    permit_mynetworks,
    reject_unauth_destination,
[...]

Biasanya merupakan ide yang baik untuk tidak mengirim kata sandi melalui koneksi yang tidak terenkripsi. Postfix memungkinkan untuk menggunakan konfigurasi yang berbeda untuk setiap port (layanan) yang dijalankannya. Semua ini dapat dikonfigurasi dengan aturan dan arahan yang berbeda di berkas /etc/postfix/master.cf. Untuk mematikan otentikasi sama sekali untuk port 25 (layanan smtpd) tambahkan direktif berikut:

smtp      inet  n       -       y       -       -       smtpd
    [..]
    -o smtpd_sasl_auth_enable=no
    [..]

Jika karena alasan tertentu klien menggunakan perintah AUTH yang sudah kedaluwarsa (beberapa klien surel yang sangat lama menggunakannya), interoperabilitas dengan mereka dapat diaktifkan menggunakan direktif broken_sasl_auth_clients.

EKSTRA Klien SMTP terotentikasi

Kebanyakan klien surel dapat untuk melakukan otentikasi ke server SMTP sebelum mengirim pesan keluar, dan menggunakan fitur itu cukup dengan sekedar mengkonfigurasi parameter yang tepat. Jika klien yang digunakan tidak menyediakan fitur itu, solusinya adalah untuk menggunakan server Postfix lokal dan mengkonfigurasi dengan relay surel melalui server SMTP remote. Dalam kasus ini, Postfix lokal itu sendiri adalah klien yang mengotentikasi dengan SASL. Berikut adalah parameter yang diperlukan:

smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
relay_host = [mail.falcot.com]

Berkas /etc/postfix/sasl_passwd perlu berisi nama pengguna dan kata sandi yangdigunakan untuk otentikasi pada server mail.falcot.com. Berikut adalah contoh:

[mail.falcot.com]   joe:LyinIsji

Seperti semua pemetaan Postfix, berkas ini harus diubah menjadi /etc/postfix/sasl_passwd.db dengan perintah postmap.