อนุญาตให้ปฏิเสธอีเมลตามที่อยู่ IP ในห่วงโซ่หรือไม่

ISP รายใหญ่กำลังปฏิเสธอีเมล (ตีกลับโดยมีข้อผิดพลาด 550) เนื่องจากที่อยู่ IP ในสายการส่งข้อมูลอยู่ใน 'รายการบล็อก' พวกเขาได้รับอนุญาตให้ทำเช่นนี้และยังเป็นไปตามมาตรฐาน IETF หรือไม่

ทั้งหมดที่ฉันหาได้คือ RFC 2821:

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

สิ่งนี้บ่งชี้ว่าระบบต้องไม่ปฏิเสธอีเมลแม้ว่าจะอยู่ในสถานการณ์อื่นก็ตาม

ใครช่วยสอนเราที

เป็นที่ถกเถียงได้ RFC เป็นเรื่องเกี่ยวกับการรักษาอินเทอร์เน็ตให้ใช้งานได้และเชื่อมต่อถึงกันโดยที่สแปมเข้ามาใช้ในทางที่ผิด

นั่นหมายความว่าไม่มี RFC หรือมาตรฐานอื่นใดที่กำหนด "นี่คือสแปม" ; การสร้างมาตรฐานดังกล่าวหมายความว่าทุกอย่างที่ไม่ใช่ "สแปมที่เป็นไปตามมาตรฐาน" ไม่ควรถูกบล็อกและต้องส่ง...

ดังนั้น การจำแนกประเภทว่าอะไรคือสแปมและอะไรไม่ใช่นั้นเป็นไปตามอำเภอใจ และสมบูรณ์ขึ้นอยู่กับ (ระบบที่ใช้โดย) ผู้รับ

เมื่อข้อความอีเมลถูกระบุว่าเป็นสแปม ผู้รับจะมีทางเลือกสามทางโดยประมาณ:

• ยอมรับสแปม - แต่อย่าส่งข้อความถึง INBOX ของผู้รับโดยตรง กักกันข้อความ ติดป้ายกำกับ และ/หรือส่งไปยังโฟลเดอร์สแปม
• ยอมรับสแปมและทิ้งอย่างเงียบๆ - อาจเป็นไปได้ว่าสิ่งนี้ละเมิดแนวคิดและมาตรฐาน SMTP ในอดีต ผู้ส่งไม่ได้รับการแจ้งเตือนว่าข้อความของพวกเขายังไม่ถูกส่ง และผู้รับที่ต้องการจะไม่ทราบว่ามีคนพยายามติดต่อพวกเขา ดู RFC 5321 - §6.2 ว่าจะอนุญาตได้เมื่อใด
• ปฏิเสธสแปม - แม้ว่าคุณต้องการหลีกเลี่ยง กระจายกลับ การปฏิเสธข้อความอย่างเหมาะสมจะส่งผลให้เกิดข้อความแสดงข้อผิดพลาดที่ไม่ส่งถึงผู้ส่ง (สำคัญในกรณีที่มีผลบวกลวง)

วิธีที่ถูกต้องตามมาตรฐานในการปฏิเสธอีเมลที่ไม่ต้องการคือ เมื่อเซิร์ฟเวอร์อีเมลที่ส่งยังคงเชื่อมต่ออยู่และระหว่างการทำธุรกรรม SMTP ให้ตอบกลับด้วยข้อผิดพลาด SMTP ตัวอย่างเช่น อาจเป็นข้อผิดพลาดจากช่วง 400 แต่ก็มาจากช่วง 500 ด้วย:

5yz ตอบกลับเชิงลบอย่างถาวร
  คำสั่งไม่ได้รับการยอมรับและการกระทำที่ร้องขอไม่ได้
  เกิดขึ้น. ไคลเอ็นต์ SMTP ไม่สนับสนุนการทำซ้ำที่แน่นอน
  คำขอ (ในลำดับเดียวกัน) แม้แต่ข้อผิดพลาด "ถาวร" บางอย่าง
  สามารถแก้ไขเงื่อนไขได้ ดังนั้นผู้ใช้ที่เป็นมนุษย์อาจต้องการควบคุมโดยตรง
  ไคลเอนต์ SMTP เพื่อเริ่มต้นลำดับคำสั่งใหม่อีกครั้งโดยตรง
  การดำเนินการในบางจุดในอนาคต (เช่น หลังจากตัวสะกดมี
  ถูกเปลี่ยนแปลง หรือผู้ใช้เปลี่ยนสถานะบัญชี)

RFC 2821 - §4.2.3

  550 ไม่ได้ดำเนินการตามที่ร้องขอ: กล่องจดหมายไม่พร้อมใช้งาน
     (เช่น ไม่พบเมลบ็อกซ์ ไม่มีการเข้าถึง หรือคำสั่งถูกปฏิเสธ
     ด้วยเหตุผลด้านนโยบาย)

เซิร์ฟเวอร์อีเมลที่ส่งยังสามารถรายงานปัญหาไปยังผู้ส่งจริงได้อย่างหมดจด โดยไม่ทำให้เกิดการกระจายกลับ