คู่มือ · yahoo mail authentication failed

ทีมผลิตภัณฑ์ควรวินิจฉัยความล้มเหลวในการยืนยันตัวตนอีเมลของ Yahoo อย่างปลอดภัยได้อย่างไร

เมื่อ Yahoo รายงานว่า mail authentication failed ให้หยุดการลองใหม่วงกว้างและเก็บการตอบกลับ SMTP ฉบับสมบูรณ์ ขอบเขตผู้รับ IP ที่ใช้ส่ง envelope sender โดเมน From ที่มองเห็น โดเมน d= และ selector ของ DKIM และเวลาของข้อความ ก่อนอื่นให้แยกการตอบกลับ 4xx ชั่วคราวออกจากการปฏิเสธ 5xx ถาวร จากนั้นทำซ้ำด้วยข้อความควบคุมหนึ่งข้อความ ตรวจสอบการอนุญาต SPF ยืนยันลายเซ็น DKIM ที่ได้รับเทียบกับคีย์ที่เผยแพร่ และประเมิน DMARC alignment แก้ไขความผิดปกติของตัวตนหรือ DNS ที่เฉพาะเจาะจง รอให้ DNS converge ทดสอบซ้ำแบบแคบ และเริ่มส่งทราฟฟิกคืนทีละน้อย การยืนยันตัวตนสำเร็จก็ยังไม่รับประกันว่าจะเข้ากล่องจดหมาย Yahoo

แยกแยะความล้มเหลวก่อนเปลี่ยน DNS

วลี Yahoo mail authentication failed อาจหมายถึงปัญหาสองอย่างที่ต่างกัน ไคลเอนต์อีเมลอาจลงชื่อเข้าใช้บัญชี Yahoo ไม่ได้ หรือระบบรับของ Yahoo อาจปฏิเสธอีเมลของผลิตภัณฑ์เพราะยืนยันตัวตนผู้ส่งไม่ได้ คู่มือนี้กล่าวถึงกรณีที่สอง คือ SPF, DKIM, DMARC และนโยบายผู้รับที่เกี่ยวข้องระหว่างการส่ง SMTP อย่ารีเซ็ตรหัสผ่านของผู้ใช้ สร้างรหัสผ่านแอป หรือหมุนเวียนข้อมูลรับรองการส่งใน production เพียงเพราะ MX ปลายทางส่งการปฏิเสธที่เกี่ยวกับการยืนยันตัวตนกลับมา ให้เริ่มจากหลักฐานที่แน่นอน บันทึกการตอบกลับ SMTP แบบขยายทั้งหมดโดยไม่ตัดข้อความวินิจฉัย ชื่อโฮสต์ MX ปลายทาง เวลา ผู้รับ ตัวระบุความพยายามส่ง IP ที่ใช้ส่ง โดเมน SMTP MAIL FROM โดเมน RFC 5322 From ที่มองเห็น และโดเมนและ selector ของลายเซ็น DKIM ทุกอัน ปกปิด local part และเนื้อหาข้อความในตั๋วที่แชร์ เว้นแต่จำเป็นจริง ๆ วลีเดียวที่คัดลอกมาโดยไม่มีรหัสสถานะและบริบทของตัวตนไม่พอที่จะระบุวิธีแก้ที่ปลอดภัย

จำแนกการตอบกลับชั่วคราวและถาวรของ Yahoo

Sender Hub ของ Yahoo จัดกลุ่มการตอบกลับ SMTP 421 เป็นการเลื่อนส่งชั่วคราว และ 553 หรือ 554 เป็นปัญหาการส่งถาวร คำแนะนำเรื่องข้อผิดพลาดปัจจุบันรวมกรณีชั่วคราวที่ไม่สามารถระบุผลการยืนยันตัวตนได้เพราะข้อผิดพลาดชั่วคราว และกรณีถาวรที่ข้อความไม่ผ่านการตรวจสอบเทียบกับนโยบาย DMARC หรือ DKIM ของโดเมนผู้ส่ง ให้ใช้การตอบกลับจริง แทนที่จะสันนิษฐานว่าทุกคำที่เกี่ยวกับการยืนยันตัวตนหมายถึงเงื่อนไขเดียวกัน สำหรับการตอบกลับ 4xx ให้เก็บข้อความไว้ในคิวและลองใหม่ด้วย exponential backoff ที่มีขอบเขต jitter อายุคิวสูงสุด และเพดานจำนวนครั้ง สำหรับการตอบกลับ 5xx ให้หยุดการส่งซ้ำอัตโนมัติสำหรับผู้รับและตัวตนข้อความนั้น จนกว่าจะเข้าใจความผิดพลาดด้านการตั้งค่าหรือเนื้อหา การรุมส่งซ้ำกับการปฏิเสธถาวรเพิ่มสัญญาณรบกวนและความเสี่ยงส่งซ้ำโดยไม่ซ่อม DNS หากเซสชัน SMTP จบอย่างกำกวมก่อนการตอบกลับสุดท้าย ให้ทำเครื่องหมายความพยายามนั้นเป็นไม่ทราบและกระทบยอด แทนที่จะสร้างข้อความเชิงตรรกะใหม่ทันที

ไล่ตามห่วงโซ่ตัวตนของข้อความควบคุมหนึ่งข้อความ

สร้างตารางตัวตนแบบกระชับสำหรับตัวอย่างที่ล้มเหลวและควบคุมได้ ให้รวม IP ที่เชื่อมต่อ ชื่อ reverse DNS ชื่อ EHLO โดเมน SMTP MAIL FROM ที่ SPF ใช้ โดเมน From ที่มองเห็นที่ DMARC ใช้ โดเมน d= และ selector s= ของ DKIM แต่ละอัน และโดเมนที่เผยแพร่เรคคอร์ด SPF, DKIM และ DMARC ในปัจจุบัน ค้นหาชื่อเหล่านั้นจาก DNS แบบ authoritative และ recursive resolver อิสระอย่างน้อยสองตัว เก็บคำตอบ TTL และการตอบกลับแบบลบพร้อมเวลา จากนั้นเปรียบเทียบกับไบต์และเฮดเดอร์ที่แน่นอนของตัวอย่างที่ส่ง อย่าทดสอบแค่สถานะโดเมนทั่วไปในแดชบอร์ดของผู้ให้บริการ เพราะซับโดเมน selector return path สตรีม หรือ tenant อื่นอาจอยู่ใน production ข้อความที่ผ่านจากผู้ให้บริการหรือเทมเพลตอื่นก็ไม่ได้พิสูจน์เส้นทางที่ล้มเหลว ให้ผู้รับเป็นผู้ที่ควบคุมได้ เปลี่ยนตัวแปรหนึ่งตัวต่อการทดสอบ และใช้ตัวระบุการติดตามใหม่ โดยคงการตั้งค่าโดเมนที่ยืนยันตัวตนไว้เหมือนเดิม

ตรวจสอบการอนุญาต SPF โดยไม่สับสนกับ From alignment

SPF ประเมินว่า IP ที่เชื่อมต่อได้รับอนุญาตสำหรับตัวตน SMTP หรือไม่ ซึ่งโดยปกติคือโดเมน MAIL FROM หรือตัวตน HELO ตามกฎของโปรโตคอล ค้นหาโดเมนที่แน่นอนที่ใช้ในความพยายามที่ล้มเหลว ยืนยันว่ามีเรคคอร์ด SPF ที่ไวยากรณ์ถูกต้องเพียงรายการเดียว เป้าหมาย include และ redirect ทั้งหมด resolve ได้ IP ส่งจริงของผู้ให้บริการอยู่ในขอบเขต และการประเมิน DNS อยู่ในขีดจำกัดของโปรโตคอล อย่าคัดลอกเรคคอร์ด TXT ที่สองไว้ข้างนโยบายที่มีอยู่ หรือเพิ่ม mechanism ที่กว้างเกินไปเพียงเพื่อให้การทดสอบผ่าน ผล SPF เชิงบวกเพียงอย่างเดียวอาจยังทำให้ DMARC ไม่ผ่านได้ หากโดเมนที่ยืนยันตัวตนไม่ align กับโดเมน From ที่มองเห็น เช่นเดียวกัน การส่งต่ออาจเปลี่ยน IP ที่เชื่อมต่อและทำให้ SPF พังแม้ผู้ส่งเดิมได้รับอนุญาต แก้การตั้งค่า return-path หรือผู้ให้บริการที่รับผิดชอบ แล้วตรวจสอบข้อความควบคุมและหลักฐาน Authentication-Results แทนที่จะพึ่งเพียงตัวตรวจ DNS

ตรวจสอบ DKIM เทียบกับข้อความที่ Yahoo ประเมิน

หาเฮดเดอร์ DKIM-Signature ทุกอันบนตัวอย่างควบคุม สำหรับลายเซ็นที่ตั้งใจใช้ยืนยันตัวตนผู้ส่งที่มองเห็น ให้ดึงโดเมน d= selector s= โหมด canonicalization รายการเฮดเดอร์ที่ลงลายเซ็น body hash อัลกอริทึม และ timestamp หรือวันหมดอายุใด ๆ ค้นหา selector ที่ s._domainkey.d และยืนยันว่าคีย์ที่เผยแพร่เป็นปัจจุบัน รูปแบบถูกต้อง และเข้าถึงได้จาก resolver ภายนอก ตรวจสอบลายเซ็นเทียบกับไบต์ของข้อความต้นฉบับ การคัดลอกเนื้อหาผ่านตั๋วหรือการ serialize MIME ใหม่อาจทำให้ตัวอย่างทดสอบใช้ไม่ได้ ความผิดพลาดที่พบบ่อยได้แก่ ลงลายเซ็นด้วยโดเมนที่ไม่คาดคิด เผยแพร่คีย์ภายใต้ selector หรือโซนผิด หมุนเวียนก่อนที่แคชจะ converge แก้เฮดเดอร์ที่ลงลายเซ็นหรือเนื้อหาหลังลงลายเซ็น และใช้เส้นทางเทมเพลตหรือ relay ที่ข้ามการลงลายเซ็น อย่าลบนโยบาย DKIM หรือลดทอนลายเซ็นทั้งหมดเพื่อซ่อมสตรีมเดียว ให้ระบุว่าส่วนใดสร้างหรือแก้ไขข้อความ และแก้เส้นทางนั้น

ประเมิน DMARC pass และ alignment อย่างชัดเจน

DMARC ใช้โดเมน From ที่มองเห็นและต้องมี SPF หรือ DKIM ที่ผ่านและ align กลไกการยืนยันตัวตนอาจผ่านในทางเทคนิคแต่ยังไม่ align ได้ เช่น SPF อาจยืนยันโดเมน return-path ของผู้ให้บริการ หรือ DKIM อาจลงลายเซ็นด้วยโดเมนของผู้ให้บริการที่ไม่เกี่ยวกับ From ที่มองเห็น ค้นหา _dmarc สำหรับนโยบายองค์กรหรือซับโดเมนที่เกี่ยวข้อง และบันทึกแท็กปัจจุบัน จากนั้นประเมินผล SPF และ alignment ของโดเมน ผล DKIM และ alignment ของโดเมนลงลายเซ็นแต่ละอัน และผล DMARC ที่ได้ ข้อกำหนดผู้ส่งของ Yahoo ปัจจุบันระบุว่าผู้ส่งทุกรายต้องมี SPF หรือ DKIM เป็นอย่างน้อย ผู้ส่งจำนวนมากต้องมีทั้ง SPF และ DKIM นโยบาย DMARC ที่ถูกต้องอย่างน้อย p=none DMARC pass และ alignment ของโดเมน From กับโดเมน SPF หรือ DKIM ให้ถือว่าเป็นข้อกำหนดปัจจุบันของ Yahoo และตรวจสอบหน้าทางการซ้ำ นโยบาย p=none ติดตามผลการจัดการ ไม่ได้ทำให้ข้อความที่ล้มเหลวผ่านการยืนยันตัวตนหรือให้สิทธิพิเศษในการส่งถึง

ใช้ Authentication-Results เป็นหลักฐาน ไม่ใช่คำสั่ง

RFC 8601 กำหนดฟิลด์เฮดเดอร์ Authentication-Results ให้บริการยืนยันตัวตนที่เชื่อถือได้ใช้สื่อสารผลลัพธ์ ให้อ่านผลที่ผู้รับหรือเกตเวย์ที่เชื่อถือได้เพิ่มเข้ามา รวมถึงวิธี ผลลัพธ์ ตัวตนที่ประเมิน และ property ที่อธิบายเพิ่มเติม อย่าเชื่อเฮดเดอร์ Authentication-Results ที่มาจากผู้ส่งที่ไม่น่าเชื่อถือหรือคัดลอกจาก hop ที่ไม่เกี่ยวข้อง เปรียบเทียบการตอบกลับ SMTP ของ Yahoo กับผลจากผู้รับควบคุมของคุณเองและล็อกของผู้ให้บริการ โดยจำไว้ว่าผู้รับต่างรายอาจมีการมองเห็น DNS นโยบาย หรือการแปลงข้อความต่างกัน เก็บเฮดเดอร์ต้นฉบับสำหรับการวิเคราะห์เหตุการณ์พร้อมการควบคุมการเข้าถึง ตัวอย่างที่ได้รับเพียงหนึ่งข้อความแสดงได้ว่าทำไมตัวอย่างนั้นผ่านหรือไม่ผ่าน แต่ไม่อาจพิสูจน์ว่าทุกสตรีมที่ส่งถูกต้อง รายงาน DMARC แบบรวมอาจเผยรูปแบบ alignment ที่กว้างกว่า แต่ล่าช้าและถูกรวมแล้ว และต้องมีการเก็บรักษาที่คำนึงถึงความเป็นส่วนตัวและปลายทางรายงานที่ได้รับอนุญาต

ซ่อมแบบแคบและทดสอบการ converge ของ DNS

เลือกการเปลี่ยนแปลงที่เล็กที่สุดที่แก้ตัวตนที่สังเกตได้ ตัวอย่างเช่น เพิ่มแหล่งส่งจริงลงในนโยบาย SPF ที่มีอยู่ ตั้งค่าผู้ให้บริการให้ใช้ custom return path ที่ align เผยแพร่ DKIM selector ที่ถูกต้อง เปิดการลงลายเซ็นบนสตรีมที่ข้ามไป ป้องกันไม่ให้ relay แก้เนื้อหาที่ลงลายเซ็น หรือตั้งค่าโดเมน d= ที่ align ทบทวนไวยากรณ์และความเป็นเจ้าของของ DNS เก็บเรคคอร์ดเดิม ลด TTL ล่วงหน้าเมื่อมีแผน และใช้การควบคุมการเปลี่ยนแปลงปกติ ห้ามเผยแพร่ความลับหรือคีย์ส่วนตัวในตั๋วหรือเรคคอร์ด DNS DKIM ใน DNS มีเพียงคีย์สาธารณะ หลังเปลี่ยน ให้ค้นหาจากเซิร์ฟเวอร์ authoritative และ recursor หลายตัวจนเห็นคำตอบที่ตั้งใจ ส่งข้อความควบคุมสองสามข้อความไปยังผู้รับทดสอบ Yahoo แยกกัน เก็บหลักฐาน SMTP และเฮดเดอร์ครบถ้วน และตรวจสอบ mechanism ที่เปลี่ยนโดยเฉพาะ อย่ารวมการเปลี่ยน SPF, DKIM, DMARC, IP, เทมเพลต และปริมาณไว้ในการทดสอบเดียว เพราะผลที่ผ่านจะไม่บอกว่าการเปลี่ยนใดมีผล

กลับมาส่งอย่างช้า ๆ และแยกผลการส่งถึงออกจากกัน

เมื่อข้อความควบคุมยืนยันตัวตนผ่านแล้ว ให้เพิ่มปริมาณเฉพาะสตรีมที่ได้รับผลกระทบ ติดตามการเลื่อนส่งชั่วคราว การปฏิเสธถาวร อีเมลตีกลับจากผู้ให้บริการ สัญญาณการร้องเรียน อายุคิว และผลการยืนยันตัวตนตามโดเมน selector IP ที่ใช้ส่ง และประเภทข้อความ อย่าใส่ที่อยู่ผู้รับและเนื้อหาข้อความในเมตริก ให้ใช้ตัวระบุที่มีขอบเขตหรือข้อมูลรวมแบบหยาบ แนวปฏิบัติที่ดีที่สุดของ Yahoo กำหนดอัตราการร้องเรียนต่ำ DNS แบบ forward และ reverse ที่ถูกต้องสำหรับ IP ที่ใช้ส่ง และอีเมลที่เป็นไปตาม RFC นอกเหนือจากการยืนยันตัวตน ขณะที่ข้อกำหนดของผู้ส่งจำนวนมากรวมพฤติกรรมการยกเลิกการรับที่ทำได้ง่าย ดังนั้นผลการยืนยันตัวตนที่แก้แล้วจึงไม่ได้สัญญาว่าเซิร์ฟเวอร์ปลายทางจะยอมรับทุกข้อความ เข้ากล่องจดหมาย หรือมีการมีส่วนร่วม ให้แยกการที่ผู้ให้บริการยอมรับการส่งเข้า การที่ SMTP ของ Yahoo ยอมรับ หลักฐานการส่งถึงภายหลัง การเข้าโฟลเดอร์ของกล่องจดหมาย และการกระทำของผู้ใช้ หากอัตราการปฏิเสธเพิ่มอีก ให้หยุดกลุ่มที่ได้รับผลกระทบ แทนที่จะย้ายทราฟฟิกที่ไม่ผ่านการยืนยันตัวตนไปยัง IP หรือโดเมนอื่น การหลบเลี่ยงแบบนั้นซ่อนสาเหตุราก และอาจทำให้ความเสียหายด้านชื่อเสียงลุกลาม

ใช้เอกสารโดเมนและ DNS ของ SendHQ

สำหรับการกำหนดค่าเฉพาะ SendHQ ให้ทำตามเอกสาร Domains และ DNS ปัจจุบัน ซึ่งครอบคลุมตัวตนผู้ส่ง DNS, SES การเผยแพร่ และสถานะการแก้ไข

คำถามที่พบบ่อย

Yahoo กำหนดให้ต้องมีทั้ง SPF และ DKIM หรือไม่

ปัจจุบัน Yahoo ระบุว่าผู้ส่งทุกรายต้องมี SPF หรือ DKIM เป็นอย่างน้อย ส่วนผู้ส่งจำนวนมากต้องมีทั้ง SPF และ DKIM พร้อมนโยบาย DMARC ที่ถูกต้องและ DMARC pass ให้ตรวจสอบข้อกำหนดปัจจุบันของ Yahoo ซ้ำสำหรับสตรีมที่ได้รับผลกระทบ

SPF ผ่านแต่ DMARC ไม่ผ่านได้หรือไม่

ได้ SPF อาจยืนยันโดเมน return-path ที่ไม่ align กับโดเมน From ที่มองเห็น DMARC ต้องมี SPF หรือ DKIM ที่ผ่านและ align

DKIM ผ่านแต่ DMARC ไม่ผ่านได้หรือไม่

ได้ ลายเซ็นที่ถูกต้องซึ่งใช้โดเมน d= ที่ไม่เกี่ยวข้องอาจไม่ align กับโดเมน From ที่มองเห็น จึงไม่ทำให้ DMARC ผ่านสำหรับตัวตน From นั้น

ควรลองใหม่เมื่อ Yahoo ปฏิเสธการยืนยันตัวตนด้วย 554 หรือไม่

ให้ถือว่าการตอบกลับ 553 หรือ 554 เป็นถาวรสำหรับความพยายามนั้น หยุดการส่งซ้ำอัตโนมัติ แก้ความผิดพลาดด้านการตั้งค่าหรือข้อความที่ระบุได้ แล้วทดสอบซ้ำด้วยข้อความควบคุม

ควรทำอย่างไรหลัง Yahoo เลื่อนส่งด้วย 421 ที่เกี่ยวกับการยืนยันตัวตน

เก็บข้อความเดิมในคิวและใช้ backoff ที่มีขอบเขตพร้อม jitter และขีดจำกัดอายุคิว เก็บการตอบกลับทั้งหมดไว้ เพราะข้อผิดพลาดชั่วคราวของ DNS หรือการประเมินต่างจากความล้มเหลวด้านนโยบายถาวร

การยืนยันตัวตนสำเร็จรับประกันการเข้ากล่องจดหมาย Yahoo หรือไม่

ไม่ การยืนยันตัวตนให้หลักฐานตัวตนในขอบเขตเท่านั้น Yahoo ยังคงใช้การตัดสินใจด้านชื่อเสียง การร้องเรียน เนื้อหา อัตรา และการกรองกล่องจดหมายได้ ชื่อเสียงของผู้รับ การร้องเรียน เนื้อหา อัตรา และตัวกรองกล่องจดหมาย ยังมีผลแยกกันอย่างอิสระ

หน้านี้พิสูจน์ว่า SendHQ แก้ความล้มเหลวในการยืนยันตัวตนของ Yahoo ได้หรือไม่

ไม่ใช่เพียงอย่างเดียว สำหรับการกำหนดค่าเฉพาะ SendHQ ให้ใช้เอกสาร Domains และ DNS ปัจจุบัน และตรวจสอบเส้นทางส่งที่ได้รับผลกระทบด้วยการทดสอบ Yahoo แบบควบคุม