Apakah ini praktik yang baik atau terlalu kejam untuk menolak surat dari pengirim surat tanpa RDNS

20

Saya baru saja menghapus SpamAssassin dan sekarang mendasarkan penolakan spam pada DNSRBL, daftar abu-abu dan tes dasar lainnya dan saya bertanya-tanya apakah saya juga harus memblokir host yang tidak memiliki RDNS yang valid yang cocok dengan EHLO?

Jika saya melakukan ini, apakah saya akan membuat masalah untuk banyak surat yang sah dan membuat marah pelanggan saya? Saya pernah mendengar orang-orang mencengkeram bahwa AOL melakukan ini, yang membuat saya berpikir mungkin terlalu tidak biasa untuk saya lakukan.

Saya juga bertanya-tanya apakah saya dapat berkompromi dengan memeriksa bahwa RDNS setidaknya diatur untuk sesuatu, tetapi tidak mencoba untuk mencocokkannya dengan EHLO. Apakah ini mungkin dengan Postfix (dan apakah berguna)?

domain-name-system  email  postfix  reverse-dns 
— Peter Snow
sumber
4
Ya, itu biasa dilakukan, bahkan jika sejumlah kecil orang memiliki masalah dengannya. Lihat Memerangi Spam - Apa yang bisa saya lakukan sebagai: Administrator Email, Pemilik Domain, atau Pengguna? untuk diskusi lebih lanjut.
— Michael Hampton
— Mathias R. Jessen
Beberapa bulan yang lalu, membalikkan lookup pada instalasi baru sendmail di Red Hat adalah default ... Saya pikir rDNS, walaupun bukan standar formal untuk server mail, cukup banyak standar defacto. Sekrup atas orang-orang di alamat IP dinamis (yaitu rumah dengan koneksi ISP kelas konsumen) tetapi dulu, dulu, bahwa IP dinamis dengan koneksi adalah botnet ... tidak tahu tentang hari ini.
— Avery Payne

Jawaban:

10

Saya telah mencoba beberapa pendekatan dengan HELO / EHLO memeriksa dengan basis pelanggan berukuran cukup baik antara 100k-200k pengguna dan akhirnya pergi dengan solusi yang melakukan hal berikut:

  • Periksa apakah HELO / EHLO berisi nama domain. - Ini sebagian besar bermuara pada apakah nama memiliki titik di dalamnya. Memeriksa DNS pada nama menyebabkan server gagal BANYAK karena tidak jarang memiliki server menyajikan nama internal atau sesuatu yang Anda tidak dapat menyelesaikan dengan benar.
  • Pastikan IP memiliki catatan DNS terbalik. - Sekali lagi ini adalah pengaturan longgar karena kami tidak memeriksa terhadap HELO / EHLO. Memeriksa terhadap HELO / EHLO membuat begitu banyak tiket yang tidak dapat dilakukan bahkan dalam satu hari.
  • Periksa nama domain pengirim valid. - Ini adalah pemeriksaan dasar untuk memastikan jika kita harus memantulkan pesan, setidaknya ada beberapa cara untuk menemukan server untuk itu.

Inilah blok Postfix yang kami gunakan untuk pemeriksaan ini:

smtpd_recipient_restrictions =
    reject_non_fqdn_sender,
    reject_unauth_destination,
    reject_unknown_reverse_client_hostname,
    reject_invalid_helo_hostname,
    reject_non_fqdn_helo_hostname,
    reject_unknown_sender_domain,
    reject_non_fqdn_recipient
— Ed.
sumber
1
Juga pendekatan tambahan yang baik adalah untuk memeriksa nama host terhadap daftar regex yang cocok dengan berbagai nama yang ditetapkan secara dinamis oleh ISP seperti xxxx.dynamic.yyy.comatau 12-34-56-78.dsl.zzz.com. Semua host tersebut harus mengirim email mereka melalui relai ISP dan tidak langsung ke MX penerima. Terutama host-host semacam itu adalah node botnet dan pesan-pesan mereka yang saya gunakan untuk mempelajari baye saya.
— Kondybas
Sepertinya ini mungkin solusi bagi saya. Apakah ada cara untuk menjalankan SpamAssassin dan membiarkannya dilewati oleh semua, kecuali untuk surat-surat yang gagal HELO yang cocok dengan RDNS, maka kami hanya memantulkan yang di atas skor tertentu? Surat-surat lain terus melewati langkah ini sepenuhnya.
— Peter Snow
Dengan exim MTA saya telah melakukan itu, secara berurutan: addr / host pengirim diperiksa terhadap daftar putih. Jika cocok - diterima segera, yang lain diperiksa terhadap daftar hitam. Jika cocok - bendera variabel dinaikkan "Gotcha!" dan pesan juga diterima. Jika pesan telah melewati daftar - pesan akan diteruskan ke SA yang bertindak sebagai daemon. Jika nilai yang dikembalikan cukup tinggi, beri tanda "Gotcha!" diangkat dan pesan juga diterima. Kemudian pesan diteruskan ke router.
— Kondybas
1
Jika bendera tidak dinaikkan, pesan disampaikan seperti biasa. Kalau tidak, salinan buta diproduksi. Pesan asli dikirim seperti biasa lagi, sementara BC diteruskan ke router khusus yang memiliki sa-belajar sebagai transportasi. Skema semacam itu memungkinkan untuk membagi aliran email ke cabang spam pasti yang mempelajari SA-bayes, dan mencurigai sisanya yang diperiksa oleh SA-bayes. Pesan dengan bendera yang dinaikkan juga memiliki tajuk tambahan yang memungkinkan untuk menyortirnya ke "Sampah"
— Kondybas
Saya memeriksa aturan-aturan itu terhadap kotak surat saya, dan ada e-mail yang akan ditolak karena HELO bukan-domain atau tidak adanya catatan DNS terbalik. Memang ada sangat sedikit dari mereka (hanya beberapa pengirim di kotak surat dengan 40.000 email), tetapi ada hal-hal penting di sana. Secara khusus, jika saya menggunakan reject_unknown_reverse_client_hostname, email dengan hasil aplikasi visa saya ke negara Asia Tenggara tertentu tidak akan datang. Saya akan menyarankan agar tidak menggunakan reject_invalid_helo_hostnamedan reject_unknown_reverse_client_hostname.
— michau
12

Sangat umum untuk memblokir server SMTP yang tidak memiliki dasar-dasar ini:

  1. Hostname di HELO maju memutuskan untuk koneksi IP berasal dari.
  2. IP asal koneksi membalikkan ke Hostname yang diklaim dalam HELO.
  3. Jika ada kebijakan SPF, DKIM, atau DMARC, verifikasi.

Siapa pun yang ingin dihalangi karena salah satu dari ini harus terpal dan berbulu.
Orang-orang yang akhirnya diblokir karena alasan lain, terutama situasi yang mengandalkan kepatuhan RFC dalam situasi "tidak normal", saya akan menaruh simpati. Spam adalah masalah yang tidak ada alasan untuk melewatkan dasar-dasarnya.

— Chris S
sumber
2
Nama reverse lookup tidak diperlukan untuk mencocokkan HELO sama sekali. Host dapat mengoperasikan banyak domain sementara pencarian balik hanya mengembalikan satu nama utama.
— Kondybas
1
Tentu, Anda dapat melakukan apa pun yang Anda inginkan. Sever Anda akan mendapatkan 511 Your rDNS doesn't match your HELOdari server saya, dan banyak lainnya juga. Spam adalah masalah besar, yang tidak harus dihadapi oleh perancang SMTP RFC. Persyaratan realistis sangat berbeda dari RFC dalam hal-hal kecil.
— Chris S
Spam tidak menjadi masalah ketika MTA dikonfigurasi dengan benar. Pengalaman saya menunjukkan bahwa (gagal rDNS ORcocok dengan bay pendek daftar regex lokal ORcocok) mendeteksi 99,99% spam. Tidak ada DNSBL, tidak ada greylists, tidak ada DKIM, tidak ada SPF. 200rb + pesan masuk bulanan. 1-2 false-p, 10-20 false-n per bulan.
— Kondybas
5

Saya berharap mengirim MTA untuk memiliki RDNS yang valid tetapi bersikeras mencocokkan EHLO akan tergantung pada siapa 'pelanggan'. Anda dapat menemukan beberapa panduan menarik di RFC5321 :

2.3.5.

(...) Nama domain yang diberikan dalam perintah EHLO HARUS berupa nama host utama (nama domain yang memutuskan ke alamat RR) atau, jika host tidak memiliki nama, alamat literal (...)

4.1.4.

(...) Server SMTP DAPAT memverifikasi bahwa argumen nama domain dalam perintah EHLO sebenarnya sesuai dengan alamat IP klien. Namun, jika verifikasi gagal, server TIDAK HARUS menolak untuk menerima pesan atas dasar itu.

tapi kemudian di 7.9.

Ini adalah prinsip yang sudah mapan bahwa server SMTP dapat menolak menerima email untuk alasan operasional atau teknis apa pun yang masuk akal bagi situs yang menyediakan server. (...)

— Dusan Bajic
sumber
1
Ini mungkin dilarang karena string yang dikirim dengan EHLO, di dunia nyata, sering tidak sesuai dengan RFC. Saya telah melihat nama host internal localhost,, dan banyak hal salah lainnya dikirim ke sini, bahkan dengan surat yang sah.
— Michael Hampton
3

Reverse lookup tidak selalu menunjuk ke nama host yang disediakan di HELO. Terkadang beberapa domain di-host pada host yang sama, dan semuanya memiliki alamat IP yang sama. Tetapi ketika Anda mencoba melakukan reverse lookup, Anda akan mendapatkan nama yang telah ditempatkan dalam catatan PTR. Sudah jelas bahwa kedua FQDN akan berbeda - dan itu sepenuhnya dapat diterima.

Satu-satunya keadaan yang memungkinkan untuk menjatuhkan pesan adalah gagal membalikkan pencarian. Setiap pencarian yang berhasil berarti bahwa host tersebut valid. Nama tidak boleh cocok.

— Kondybas
sumber
1
"Sudah jelas bahwa kedua FQDN akan berbeda - dan itu benar-benar dapat diterima." Tidak. Anda hanya dapat mengonfigurasi satu catatan PTR dan server email Anda hanya dapat mengumumkan satu nama host di HELO. Jadi harus jelas bahwa keduanya bisa cocok.
— Chris S
2

Saya ingin tahu apakah saya juga harus memblokir host yang tidak memiliki RDNS yang cocok dengan EHLO?

Tidak, seharusnya tidak. Memblokir seluruh email hanya dengan satu kriteria itu adalah praktik yang buruk.

Jika saya melakukan ini, apakah saya akan membuat masalah untuk banyak surat yang sah dan membuat marah pelanggan saya?

semakin besar kemungkinan Anda melakukannya dan akan kehilangan email yang sah

Saya juga bertanya-tanya apakah saya dapat berkompromi dengan memeriksa bahwa RDNS setidaknya diatur untuk sesuatu, tetapi tidak mencoba untuk mencocokkannya dengan EHLO. Apakah ini mungkin dengan Postfix (dan apakah berguna)?

ya itu mungkin. Anda dapat menggunakan reject_unknown_reverse_client_hostname alih-alih reject_unknown_client_hostname

Sayangnya, postfix tidak memiliki opsi fleksibel untuk "keputusan kompleks". Sebagai contoh, Anda dapat menambahkan beberapa poin untuk email seperti itu, misalnya

Score = 0 
1. The HELO or EHLO hostname is not in fully-qualified domain or address literal form. Score +=10
2. The HELO or EHLO hostname has no DNS A or MX record. Score +=20
3. The HELO or EHLO hostname is listed with the A record "d.d.d.d" under rbl_domain. Score +=20
4. The sender domain has no DNS A or MX record. Score +=10
5. SPF checks return softfail. Score +=10, fail, Score +=20
...

Dan seterusnya. Setelah semua cek akan selesai dan jika Anda memiliki Skor> 100, Anda dapat menolak email. Sebenarnya Anda bisa mendapatkan perilaku seperti itu, tetapi Anda harus menulis layanan kebijakan Anda sendiri

— ALex_hha
sumber
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.