ทำไมอีเมลถึงถูกส่งตามปกติแม้จะมี SPF“ hardfail”?

ฉันพยายามที่จะคิดออกว่าทำไมอีเมลปลอมจะถูกส่งไปยังผู้ให้บริการอีเมลที่สำคัญ (gmail.com, outlook.com) แม้ว่าอีเมลถูกทำเครื่องหมายด้วยค่า hardfailSPF อีเมลดังกล่าวจะถูกส่งไปยัง Microsoft Exchange ซึ่งกำลังส่งไปยังPermErrorระเบียน SPF เดียวกัน

ฉันกำลังส่งอีเมลโดยใช้โดเมน SOME_DOMAIN.com ซึ่งกำหนดเรคคอร์ด SPF ที่ใช้งานไม่ได้ อีเมลถูกส่งจากที่อยู่ IP ของฉันซึ่งไม่ได้ระบุไว้อย่างชัดเจนในบันทึก SPF ของ SOME_DOMAIN.com ระเบียน SPF สำหรับ SOME_DOMAIN.com มีคุณสมบัติสามประการต่อไปนี้สองรายการแรกเป็นการละเมิด SPF RFC-4408:

1. ต้องมีมากกว่า 10 คำสั่ง DNS เพื่อแก้ไขระเบียน SPF include:ทั้งการเนื่องจาก
2. ข้อผิดพลาดทางไวยากรณ์ในหนึ่งในระเบียน SPF, python-spf ส่งข้อผิดพลาดในการแยกวิเคราะห์
3. ระเบียน SPF มีทั้งกฎ~allและ-allทั้งสองบอกว่าชุดของที่อยู่ทั้งหมดควรsoftfailและhardfail

อีเมลที่ส่งไปยังที่อยู่ outlook.com ที่ปลอมแปลงเป็น admin@SOME_DOMAIN.com จะมีข้อผิดพลาดต่อไปนี้ในส่วนหัว SMTP ของอีเมลที่ส่ง โดยปกติอีเมลนี้จะถูกส่งไปยังกล่องจดหมายของผู้ใช้ :

Received-SPF: PermError (: domain of SOME_DOMAIN.com used an invalid SPF mechanism)

Gmail จะส่งอีเมลไปยังกล่องจดหมายของผู้ใช้ แต่จะมีข้อผิดพลาด SPF แตกต่างกัน:

spf=hardfail (google.com: domain of admin@SOME_DOMAIN.COM does not designate x.x.x.x as permitted sender) smtp.mail=admin@SOME_DOMAIN.COM

แล้วเกิดอะไรขึ้นที่นี่? ทำไมอีเมลถูกส่งแม้จะมีค่า SPF hardfail? การมีระเบียน SPF ที่ใช้งานไม่ได้หมายความว่าเซิร์ฟเวอร์ SMTP อื่นไม่สนใจค่า SPF ทั้งหมดหรือไม่ หรือมีบางอย่างที่ฉันขาดหายไปที่นี่ ...

SPF ถูกกำหนดค่าอย่างไม่ดีนักโดยไซต์จำนวนมากที่รับ MTA มักจะนับhardfailเป็นคำแนะนำเท่านั้นและแยกให้เป็นคะแนนการตรวจจับสแปมของพวกเขา ในที่สุดมันก็ขึ้นอยู่กับผู้ดูแลระบบของ MTA ว่าจะปฏิบัติต่อความล้มเหลวของ SPF ได้อย่างไร

เงื่อนไขข้อผิดพลาด SPF ไม่ได้ระบุอะไรเกี่ยวกับนโยบายที่ต้องการ เช่นนี้พวกเขาไม่ได้ให้คำแนะนำว่าจะยอมรับข้อความหรือไม่ +allมันเป็นไปได้ว่านโยบายที่ตั้งใจไว้คือ เป็นเรื่องปกติที่จะรับจดหมายในกรณีนี้ ดูเหมือนว่า Google กำลังผ่อนปรนกับโดเมนนี้ที่ล้มเหลวในการปฏิบัติตามมาตรฐาน

แม้แต่การปฏิเสธนโยบาย SPF ( -all) ก็ไม่น่าเชื่อถือเมื่อตรวจสอบที่อยู่ผู้ส่ง มีหลายกรณีที่การปฏิเสธเมลดังกล่าวจะไม่เหมาะสม ได้แก่ :

• จดหมายที่ส่งโดยจดหมายที่ทำสัญญา (คนเหล่านี้จะได้รับเงินเพื่อละเมิดนโยบาย)
• จดหมายที่ส่งจากเว็บฟอร์มและระบบอัตโนมัติอื่น ๆ
• ส่งต่อจดหมายโดยรายชื่อผู้รับจดหมายหรือกลไกการส่งต่ออื่น ๆ และ
• เพียงแค่กำหนดค่าเรคคอร์ด SPF อย่างผิดปกติ (ไม่ธรรมดา แต่ไม่พบว่าเพียงพอ)

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

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

ดูเหมือนว่า SPF ที่ล้มเหลวจะมีความน่าเชื่อถือในการตรวจสอบข้อมูลประจำตัวของเซิร์ฟเวอร์ที่ส่ง ฉันค้นคว้ามาระยะหนึ่งแล้วและพบว่าแม้แต่ชื่อ HELO ที่อ่อนนุ่มก็เป็นเหตุผลที่สมควรที่จะล้มเหลวหรือเลื่อนข้อความที่เข้ามา

เมลเซิร์ฟเวอร์จำนวนมากไม่มีเรคคอร์ด SPF ถ้าเมลเซิร์ฟเวอร์ไม่มีเรคคอร์ด SPF ฉันจะตรวจสอบเรคคอร์ด SPF กับโดเมนหลัก นี่ไม่ใช่มาตรฐาน แต่มีประสิทธิภาพ ฉันแนะนำให้ผู้ดูแลระบบอีเมลตรวจสอบให้แน่ใจว่ามีระเบียน SPF สำหรับเซิร์ฟเวอร์ IP ตามที่ระบุไว้ในระเบียน PTR เซิร์ฟเวอร์ของคุณควรระบุตัวเองด้วยชื่อที่ส่งคืนโดยระเบียน PTR เช่นกัน ตรวจสอบว่าคุณมีระเบียน A ที่สอดคล้องกันสำหรับการตรวจสอบ DNS ย้อนกลับ