มันเป็นการปฏิบัติที่ดีหรือเข้มงวดเกินไปที่จะปฏิเสธเมลจาก mailservers ที่ไม่มี RDNS


20

เมื่อเร็ว ๆ นี้ฉันได้ลด SpamAssassin และตอนนี้ฉันกำลังปฏิเสธการสแปมในการทดสอบรายชื่อสีเทาและการทดสอบขั้นพื้นฐานอื่น ๆ ของ DNSRBL และฉันสงสัยว่าฉันควรบล็อกโฮสต์ที่ไม่มี RDNS ที่ตรงกับ EHLO ใช่หรือไม่

ถ้าฉันทำสิ่งนี้ฉันจะสร้างปัญหาให้กับจดหมายที่ถูกกฎหมายและทำให้ลูกค้าของฉันไม่พอใจหรือไม่? ฉันได้ยินคนจับที่ AOL ทำเช่นนี้ซึ่งทำให้ฉันคิดว่ามันผิดปกติสำหรับฉันที่จะทำ

ฉันยังสงสัยด้วยว่าฉันสามารถประนีประนอมได้หรือไม่โดยตรวจสอบว่าอย่างน้อย RDNS นั้นถูกตั้งค่าเป็นบางอย่าง แต่ไม่พยายามจับคู่กับ EHLO เป็นไปได้ไหมกับ Postfix (และมีประโยชน์)?


4
ใช่มันทำกันโดยทั่วไปแม้ว่าคนจำนวนน้อยมากจะมีปัญหากับมัน ดูการต่อสู้กับสแปม - ฉันจะทำอะไรได้บ้าง: ผู้ดูแลระบบอีเมล, เจ้าของโดเมนหรือผู้ใช้? สำหรับการสนทนาต่อไป
Michael Hampton


ดวงจันทร์หลายคนย้อนกลับการค้นหา sendmail ติดตั้งใหม่ใน Red Hat เป็นค่าเริ่มต้น ... ฉันคิดว่า rDNS ในขณะที่ไม่ใช่มาตรฐานอย่างเป็นทางการสำหรับเซิร์ฟเวอร์อีเมลมันค่อนข้างเป็นมาตรฐาน defacto มันสกรูมากกว่าคนในที่อยู่ IP แบบไดนามิก (เช่นบ้านที่มีการเชื่อมต่อ ISP ระดับผู้บริโภค) แต่มันเคยเป็นครั้งคราวที่ส่วนใหญ่ของ IP แบบไดนามิกเหล่านั้นที่มีการเชื่อมต่อเป็นบอทเน็ต ... ทุกวันนี้
Avery Payne

คำตอบ:


10

ฉันได้ลองหลายวิธีด้วยการตรวจสอบ HELO / EHLO ด้วยฐานลูกค้าที่มีขนาดพอสมควรระหว่าง 100k-200k ผู้ใช้และจบลงด้วยโซลูชันที่ทำสิ่งต่อไปนี้:

  • ตรวจสอบว่า HELO / EHLO มีชื่อโดเมน - สิ่งนี้ส่วนใหญ่จะทำให้ชื่อมีจุดอยู่ในนั้น การตรวจสอบ DNS ในชื่อที่นำไปสู่เซิร์ฟเวอร์ที่ล้มเหลวจำนวนมากเนื่องจากไม่ใช่เรื่องแปลกที่จะให้เซิร์ฟเวอร์แสดงชื่อภายในหรือสิ่งที่คุณไม่สามารถแก้ไขได้อย่างถูกต้อง
  • ตรวจสอบว่า IP มีระเบียน DNS ย้อนกลับ - อีกครั้งนี่เป็นการตั้งค่าหละหลวมเนื่องจากเราไม่ได้ตรวจสอบกับ HELO / EHLO การตรวจสอบกับ HELO / EHLO ได้สร้างตั๋วจำนวนมากที่การตั้งค่านี้ไม่สามารถทำได้แม้แต่วันเดียว
  • ตรวจสอบชื่อโดเมนผู้ส่งว่าถูกต้อง - นี่เป็นการตรวจสอบเบื้องต้นเพื่อให้แน่ใจว่าถ้าเราต้องตีกลับข้อความอย่างน้อยก็จะมีวิธีในการค้นหาเซิร์ฟเวอร์ให้

นี่คือบล็อก Postfix ที่เราใช้สำหรับการตรวจสอบเหล่านี้:

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

1
นอกจากนี้ยังมีวิธีการเพิ่มเติมที่ดีคือการตรวจสอบชื่อโฮสต์กับรายการ regexes ที่ตรงกับชื่อต่าง ๆ ที่ได้รับมอบหมายจาก ISP แบบไดนามิกเหมือนหรือxxxx.dynamic.yyy.com 12-34-56-78.dsl.zzz.comโฮสต์ดังกล่าวทั้งหมดควรส่งจดหมายผ่านทางรีเลย์ของ ISP และไม่ส่งตรงไปยัง MX ของผู้รับ โฮสต์ส่วนใหญ่เช่นโหนด botnet และข้อความที่ฉันใช้เพื่อเรียนรู้ช่องของฉัน
Kondybas

ดูเหมือนว่ามันอาจเป็นทางออกสำหรับฉัน มีวิธีเรียกใช้ SpamAssassin และปล่อยให้ผ่านไปทั้งหมดยกเว้นอีเมลที่ HELO ไม่สามารถจับคู่กับ RDNS ได้ดังนั้นเราจะตีกลับเฉพาะคะแนนที่สูงกว่าเท่านั้น เมลอื่นยังคงดำเนินต่อไปโดยสมบูรณ์ผ่านขั้นตอนนี้
Peter Snow

ด้วยเอ็มทีเอ็ม EXIM ที่ฉันทำไปตามลำดับ: addr / host ของผู้ส่งถูกตรวจสอบกับรายการสีขาว หากจับคู่ - ยอมรับทันทีจะมีการตรวจสอบกับบัญชีดำ หากจับคู่ - ตั้งค่าสถานะตัวแปรยก "Gotcha!" และข้อความก็เป็นที่ยอมรับ หากข้อความถูกส่งผ่านรายการ - มันจะถูกส่งไปยัง SA ที่ทำหน้าที่เป็น daemon หากส่งคืนค่าสูงพอให้ตั้งค่าสถานะ "Gotcha!" ยกขึ้นและข้อความได้รับการยอมรับ จากนั้นส่งข้อความไปยังเราเตอร์
Kondybas

1
หากการตั้งค่าสถานะไม่ยกข้อความจะถูกส่งตามปกติ มิฉะนั้นจะผลิตสำเนาแบบบอด ข้อความต้นฉบับจะถูกส่งตามปกติอีกครั้งในขณะที่ BC ถูกส่งผ่านไปยังเราเตอร์พิเศษที่มีการเรียนรู้แบบการขนส่ง รูปแบบดังกล่าวช่วยให้สามารถแยก mailflow ออกเป็นสาขาสแปมแน่นอนที่เรียนรู้ SA-bayes และสงสัยส่วนที่เหลือที่ตรวจสอบโดย SA-bayes ข้อความที่มีการตั้งค่าสถานะยกยังมีส่วนหัวเพิ่มเติมที่อนุญาตให้จัดเรียงลงใน "ขยะ"
Kondybas

ฉันตรวจสอบกฎเหล่านั้นกับกล่องจดหมายของฉันและมีอีเมลที่จะถูกปฏิเสธเนื่องจากไม่ใช่โดเมน HELO หรือไม่มีระเบียน DNS ย้อนกลับ มีเพียงไม่กี่คนเท่านั้นที่ยอมรับ (มีผู้ส่งไม่กี่รายในกล่องจดหมายที่มี 40,000 อีเมล) แต่มีสิ่งสำคัญอยู่ที่นั่น โดยเฉพาะอย่างยิ่งถ้าฉันใช้reject_unknown_reverse_client_hostnameอีเมลที่มีผลการสมัครวีซ่าไปยังประเทศในเอเชียตะวันออกเฉียงใต้โดยเฉพาะนั้นคงไม่ผ่าน ผมแนะนำให้กับการใช้และreject_invalid_helo_hostname reject_unknown_reverse_client_hostname
michau

12

เป็นเรื่องธรรมดามากที่จะบล็อกเซิร์ฟเวอร์ SMTP ที่ไม่มีพื้นฐานเหล่านี้:

  1. ชื่อโฮสต์ใน HELO ฟอร์เวิร์ดจะแก้ไขการเชื่อมต่อ IP ที่มาจาก
  2. การเชื่อมต่อ IP ต้นทางกลับไปเป็นชื่อโฮสต์ที่อ้างสิทธิ์ใน HELO
  3. หากมีนโยบาย SPF, DKIM หรือ DMARC ให้ยืนยัน

ผู้ใดก็ตามที่จับต้องถูกบล็อกเพราะสิ่งเหล่านี้ควรถูกทำลายและมีขน
คนที่ลงเอยด้วยการถูกปิดกั้นด้วยเหตุผลอื่นโดยเฉพาะอย่างยิ่งสถานการณ์ที่ต้องพึ่งพาความสอดคล้อง RFC ในสถานการณ์ "ผิดปกติ" ฉันจะเห็นอกเห็นใจ สแปมเป็นปัญหาที่ไม่มีข้อแก้ตัวสำหรับการขาดพื้นฐาน


2
ชื่อการค้นหาแบบย้อนกลับไม่จำเป็นต้องตรงกับ HELO เลย โฮสต์สามารถทำงานได้หลายโดเมนในขณะที่การค้นหาแบบย้อนกลับจะส่งคืนชื่อหลักเพียงชื่อเดียวเท่านั้น
Kondybas

1
แน่นอนคุณสามารถทำสิ่งที่คุณต้องการ เซิร์ฟเวอร์ของคุณจะได้รับ511 Your rDNS doesn't match your HELOจากเซิร์ฟเวอร์ของฉันและอื่น ๆ อีกมากมายเช่นกัน สแปมเป็นปัญหาสำคัญที่ผู้ออกแบบของ SMTP RFC ไม่ต้องจัดการ ความต้องการที่สมจริงนั้นแตกต่างจาก RFC อย่างชัดเจน
Chris S

สแปมไม่ใช่ปัญหาเมื่อ MTA ได้รับการกำหนดค่าอย่างเหมาะสม ประสบการณ์ของฉันแสดงให้เห็นว่า (rDNS ที่ไม่ORตรงกับช่องรายการ regex ในพื้นที่แบบสั้นOR) ตรวจจับสแปม 99.99% ไม่มี DNSBLs ไม่มี greylists ไม่มี DKIM ไม่มี SPF 200k + ข้อความที่เข้ามาทุกเดือน 1-2 false-p, 10-20 false-n ต่อเดือน
Kondybas

5

ฉันคาดหวังว่าการส่ง MTA จะมี RDNS ที่ถูกต้อง แต่การยืนยันในการจับคู่ EHLO นั้นขึ้นอยู่กับว่า 'ลูกค้า' คือใคร คุณสามารถค้นหาแนวทางที่น่าสนใจในRFC5321 :

2.3.5

(... ) ชื่อโดเมนที่กำหนดในคำสั่ง EHLO ต้องเป็นชื่อโฮสต์หลัก (ชื่อโดเมนที่แปลงเป็น RR ที่อยู่) หรือหากโฮสต์ไม่มีชื่อจะมีตัวอักษรที่อยู่ (... )

4.1.4

(... ) เซิร์ฟเวอร์ SMTP อาจตรวจสอบว่าอาร์กิวเมนต์ชื่อโดเมนในคำสั่ง EHLO นั้นสอดคล้องกับที่อยู่ IP ของลูกค้าหรือไม่ อย่างไรก็ตามหากการตรวจสอบล้มเหลวเซิร์ฟเวอร์จะต้องไม่ปฏิเสธที่จะรับข้อความตามนั้น

แต่แล้วใน 7.9

เป็นหลักการที่ได้รับการยอมรับอย่างดีว่าเซิร์ฟเวอร์ SMTP อาจปฏิเสธที่จะรับจดหมายด้วยเหตุผลด้านการปฏิบัติงานหรือทางเทคนิคใด ๆ ที่เหมาะสมกับเว็บไซต์ที่ให้บริการเซิร์ฟเวอร์ (... )


1
สิ่งนี้อาจเป็นสิ่งต้องห้ามเนื่องจากสตริงที่ส่งมากับ EHLO ในโลกแห่งความเป็นจริงมักไม่สอดคล้องกับ RFC ฉันเห็นชื่อโฮสต์ภายในlocalhostและสิ่งอื่น ๆ อีกมากมายที่ส่งมาที่นี่แม้จะมีอีเมลที่ถูกต้องสมบูรณ์แบบก็ตาม
Michael Hampton

3

การค้นหาแบบย้อนกลับไม่จำเป็นต้องชี้ไปที่ชื่อโฮสต์ที่ให้ไว้ใน HELO บางครั้งมีหลายโดเมนที่โฮสต์บนโฮสต์เดียวกันและทั้งหมดนั้นมีที่อยู่ IP เดียวกัน แต่เมื่อคุณพยายามค้นหาแบบย้อนกลับคุณจะได้รับชื่อที่อยู่ในเรคคอร์ด PTR เป็นที่ชัดเจนว่าทั้ง FQDNs จะแตกต่างกันและเป็นที่ยอมรับโดยสมบูรณ์

สถานการณ์เดียวที่อนุญาตให้ปล่อยข้อความล้มเหลวในการค้นหาแบบย้อนกลับ การค้นหาที่สำเร็จหมายความว่าโฮสต์นั้นถูกต้อง ชื่อไม่ควรตรงกัน


1
"เห็นได้ชัดว่าทั้ง FQDNs จะแตกต่างกัน - และยอมรับได้อย่างสมบูรณ์" ไม่ได้คุณสามารถกำหนดค่าได้เพียงหนึ่งเรคคอร์ด PTR และเมลเซิร์ฟเวอร์ของคุณสามารถประกาศชื่อโฮสต์ได้เพียงรายการเดียวใน HELO ดังนั้นควรชัดเจนว่าทั้งคู่สามารถจับคู่กันได้
Chris S

2

ฉันสงสัยว่าฉันควรบล็อกโฮสต์ที่ไม่มี RDNS ที่ถูกต้องที่ตรงกับ EHLO หรือไม่

ไม่คุณไม่ควรทำ บล็อกอีเมลทั้งหมดโดยใช้เพียงเกณฑ์เดียวเท่านั้นถือว่าเป็นการปฏิบัติที่ไม่ดี

ถ้าฉันทำสิ่งนี้ฉันจะสร้างปัญหาให้กับจดหมายที่ถูกกฎหมายและทำให้ลูกค้าของฉันไม่พอใจหรือไม่?

มีโอกาสมากที่คุณทำและจะสูญเสียเมลที่ถูกต้อง

ฉันยังสงสัยด้วยว่าฉันสามารถประนีประนอมได้หรือไม่โดยตรวจสอบว่าอย่างน้อย RDNS นั้นถูกตั้งค่าเป็นบางอย่าง แต่ไม่พยายามจับคู่กับ EHLO เป็นไปได้ไหมกับ Postfix (และมีประโยชน์)?

ใช่มันเป็นไปได้ คุณสามารถใช้ปฏิเสธ _unknown_reverse_client_hostname แทนปฏิเสธ _unknown_client_hostname

น่าเสียดายที่ postfix ไม่มีตัวเลือกที่ยืดหยุ่นสำหรับ "การตัดสินใจที่ซับซ้อน" ใน exim คุณสามารถเพิ่มคะแนนบางส่วนสำหรับจดหมายดังกล่าวเช่น

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

และอื่น ๆ หลังจากการตรวจสอบทั้งหมดจะเสร็จสมบูรณ์และหากคุณมีคะแนน> 100 คุณสามารถปฏิเสธเมลได้ ที่จริงแล้วคุณสามารถรับพฤติกรรมดังกล่าว แต่คุณจะต้องเขียนบริการนโยบายของคุณเอง

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.