ทีมผลิตภัณฑ์ควรวินิจฉัยและจัดการอีเมลตีกลับอย่างปลอดภัยอย่างไร

ระบุว่าสังเกตเห็นความล้มเหลวที่ขั้นใด

ผลิตภัณฑ์อาจทราบว่าส่งไม่ถึงระหว่างธุรกรรม SMTP สด ผ่าน delivery-status notification ที่มาภายหลัง หรือผ่านอีเวนต์ของผู้ให้บริการที่ยืนยันตัวตนแล้ว การสังเกตเหล่านี้เป็นหลักฐานคนละแบบ การปฏิเสธ RCPT TO ทันทีใช้กับผู้รับรายนั้นก่อนรับข้อมูลข้อความ การปฏิเสธในขั้น DATA อาจใช้กับธุรกรรมที่ส่งเข้ามา DSN ที่มาภายหลังรายงานว่าระบบหนึ่งรับผิดชอบแล้วและต่อมาส่งหรือรีเลย์ข้อความไม่ได้ บันทึกขั้น เซิร์ฟเวอร์ ขอบเขตผู้รับ ความพยายาม เวลา คำตอบ SMTP รหัสสถานะแบบขยาย ข้อความวินิจฉัย และตัวระบุความสัมพันธ์เดิม อย่ารวมทุกกรณีเป็น bounced เก็บ payload ดิบของผู้ให้บริการหรือ DSN ในรูปแบบมาตรฐานไว้เท่าที่ความต้องการด้านการดำเนินงานและนโยบายกำหนดเท่านั้น พร้อมจำกัดการเข้าถึง ภาพหน้าจอของซัพพอร์ตหรือการถอดความโดยมนุษย์ไม่เพียงพอเป็นหลักฐานสำหรับการลองใหม่อัตโนมัติ การระงับการส่ง หรือสถานะที่แสดงต่อลูกค้า

แยกผลลัพธ์ชั่วคราวและถาวร

SMTP ใช้คำตอบ 4yz สำหรับการปิดงานเชิงลบแบบชั่วคราว และ 5yz สำหรับการปิดงานเชิงลบแบบถาวร รหัสสถานะแบบขยายเพิ่มคลาสที่ขึ้นต้นด้วย 4 สำหรับความล้มเหลวชั่วคราวที่คงอยู่ หรือ 5 สำหรับความล้มเหลวถาวร ตามด้วยค่าหัวข้อและรายละเอียด เก็บทั้งรหัสพื้นฐานและรหัสแบบขยาย เพราะข้อความล้วนขึ้นกับผู้ให้บริการและเปลี่ยนแปลงได้ ผลลัพธ์ชั่วคราวอาจเป็นเหตุผลให้ลองส่งข้อความตรรกะเดิมอีกครั้งหลังหน่วงเวลา แต่ไม่ใช่เหตุผลให้วนซ้ำทันทีหรืออยู่ในคิวไม่จำกัด ความล้มเหลวถาวรของผู้รับควรหยุดการส่งซ้ำอัตโนมัติสำหรับผู้รับและความพยายามนั้น จนกว่าที่อยู่หรือนโยบายจะเปลี่ยนผ่านกระบวนการที่ได้รับอนุญาต อย่าอนุมาน hard หรือ soft จากป้ายกำกับไม่เป็นทางการของผู้ให้บริการเพียงอย่างเดียว สร้างนโยบายจากสถานะที่แน่นอน ขั้น ข้อความวินิจฉัย ประเภทข้อความ ผู้รับ และเอกสารของผู้ให้บริการปัจจุบัน การตอบกลับที่ไม่ทราบหรือผิดรูปแบบควรล้มเหลวอย่างปลอดภัยเข้าสู่การตรวจสอบหรือ dead-letter แทนที่จะส่งซ้ำโดยค่าเริ่มต้น

แยกวิเคราะห์ delivery-status notification อย่างระมัดระวัง

RFC 3464 กำหนดรูปแบบ delivery-status notification ที่เครื่องอ่านได้ ซึ่งส่งใน multipart/report พร้อมฟิลด์ message/delivery-status ฟิลด์ที่มีประโยชน์ได้แก่ Reporting-MTA, Final-Recipient, Action, Status, Remote-MTA, Diagnostic-Code และเวลาที่มาถึงหรือความพยายามล่าสุด ถือทุกฟิลด์เป็นอินพุตที่ไม่น่าเชื่อถือ แม้โครงสร้าง MIME จะแยกวิเคราะห์ได้ จำกัดขนาดข้อความ จำนวนเฮดเดอร์ จำนวนส่วน การซ้อน การถอดรหัสอักขระ และความยาวข้อความวินิจฉัยที่เก็บ ห้ามรันไฟล์แนบ ห้ามตามลิงก์ในข้อความวินิจฉัยโดยอัตโนมัติ และห้ามยอมรับที่อยู่ผู้รับเป็นตัวตนของ tenant เชื่อมโยงกับความพยายามที่แอปพลิเคชันเป็นเจ้าของโดยใช้ตัวระบุข้อความของผู้ให้บริการที่คงที่ เมทาดาทา envelope เดิม หรือเฮดเดอร์ความสัมพันธ์ที่ปลอดภัยต่อความเป็นส่วนตัว DSN อาจมีส่วนของข้อความเดิมและข้อมูลผู้รับ จึงควรจำกัดล็อกและการเก็บรักษา หากความสัมพันธ์กำกวม ให้เก็บหลักฐานไว้โดยไม่ระงับการส่งถึงที่อยู่ที่ไม่เกี่ยวข้องหรือเปิดเผยประวัติข้อความของ tenant อื่น

สร้างโมเดลการเปลี่ยนสถานะระดับผู้รับ

ข้อความหนึ่งฉบับอาจส่งถึงผู้รับหลายรายและได้ผลลัพธ์ต่างกัน เก็บสถานะต่อผู้รับและต่อความพยายาม ไม่ใช่เฉพาะในแถวของข้อความ ผู้ให้บริการอาจยอมรับบางคำสั่ง RCPT และปฏิเสธบางคำสั่ง หรือรายงานการส่งถึงสำหรับผู้รับรายหนึ่งและความล้มเหลวสำหรับอีกรายภายหลัง กำหนดการเปลี่ยนสถานะแบบทิศทางเดียว เพื่อไม่ให้อีเวนต์ accepted หรือ deferred ที่ล่าช้าเขียนทับความล้มเหลวถาวร การร้องเรียน หรือการยกเลิกการรับที่ยืนยันแล้วภายหลัง เก็บบัญชีอีเวนต์และอนุมานสถานะที่แสดงปัจจุบันผ่านกฎลำดับความสำคัญที่ชัดเจน แยกสถานะ submitted, provider accepted, recipient server accepted, temporarily deferred, permanently failed, suppressed, complained, unsubscribed และ unknown การยอมรับโดยเซิร์ฟเวอร์ปลายทางก็ยังไม่เปิดเผยโฟลเดอร์กล่องจดหมายสุดท้ายหรือการอ่านโดยมนุษย์ ทำให้การลองใหม่สร้างความพยายามที่เชื่อมโยงกันภายใต้คีย์อีเวนต์ตรรกะเดียวกัน เพื่อให้ความเสี่ยงการซ้ำและหลักฐานยังมองเห็นได้ อย่าทำเครื่องหมายการลองใหม่ที่วางแผนไว้เป็นการกระทำใหม่ของลูกค้า

ลองใหม่ความล้มเหลวชั่วคราวภายในขอบเขตที่เข้มงวด

สำหรับผลลัพธ์ชั่วคราวที่เข้าเกณฑ์ ให้กำหนดเวลา exponential backoff พร้อม jitter จำนวนครั้งที่จำกัด และอายุคิวสูงสุด ใช้พฤติกรรมการลองใหม่ที่ผู้ให้บริการระบุ และอย่าซ้อนลูปของแอปพลิเคชันที่ก้าวร้าวบนรีเลย์ที่ลองใหม่อยู่แล้ว คงตัวตนข้อความตรรกะเดิมและการตรวจสอบการระงับการส่งทุกครั้งที่พยายาม หยุดลองใหม่เมื่อผู้รับถูกระงับการส่ง ความยินยอมเปลี่ยน อีเวนต์หมดอายุ ตัวตนผู้ส่งถูกเพิกถอน หรือมีการตอบกลับถาวรตามมา จำกัดอัตราตาม tenant โดเมนปลายทาง ผู้ส่ง และประเภทความล้มเหลว เพื่อไม่ให้เซิร์ฟเวอร์ผู้รับล่มรายเดียวผูกขาดคิว เคารพ Retry-After หรือแนวทางการเลื่อนที่ระบุไว้เมื่อมี แต่ห้ามเชื่อเนื้อหาข้อความใด ๆ เป็นคำสั่งลองใหม่ แจ้งเตือนเมื่ออายุคิวสูงขึ้น รหัสชั่วคราวซ้ำ โดเมนผิดปกติ และความพยายามที่ใกล้หมดอายุ รหัสชั่วคราวอาจปกปิดปัญหานโยบายหรือชื่อเสียงที่คงอยู่ การลองใหม่ที่มีขอบเขตซื้อเวลาให้ฟื้นตัว ไม่ใช่ใบอนุญาตให้เพิกเฉยต่อสาเหตุ

ระงับการส่งเมื่อยืนยันความล้มเหลวถาวรของผู้รับ

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

หลีกเลี่ยงลูปอีเมลตีกลับและ backscatter

SMTP ใช้ null reverse path สำหรับ delivery-status notification เพื่อไม่ให้ความล้มเหลวขณะส่งการแจ้งเตือนสร้างอีเมลตีกลับอีกฉบับ รักษาพฤติกรรมนี้ในรีเลย์ และอย่าส่งการตอบกลับอัตโนมัติไปยัง DSN การตอบกลับอัตโนมัติ หรือข้อความที่มีสัญญาณว่าสร้างโดยอัตโนมัติ RFC 3834 ให้คำแนะนำสำหรับการตอบกลับอีเมลอัตโนมัติ รวมถึงประเด็นลูปและการขยาย อย่าสร้างอีเมลตีกลับไปยังที่อยู่ From ที่มองเห็นซึ่งไม่ได้ยืนยัน หลังยอมรับข้อความที่น่าสงสัย เพราะตัวตนผู้ส่งที่ปลอมอาจทำให้ระบบกลายเป็นแหล่ง backscatter ปฏิเสธผู้รับที่ไม่ถูกต้องระหว่าง SMTP เมื่อเป็นไปได้ แทนที่จะยอมรับแล้วแจ้งที่อยู่ปลอมภายหลัง จำกัดการตอบกลับอัตโนมัติต่อผู้ส่งและการสนทนา และใช้ตัวตนตอบกลับที่ควบคุมได้ webhook ของผลิตภัณฑ์หรืออีเวนต์ข้อผิดพลาดภายในมักปลอดภัยกว่าการสร้างอีเมลอินเทอร์เน็ตใหม่ ทดสอบ From ปลอม envelope sender แบบ null DSN ซ้ำ เฮดเดอร์ auto-submitted ทราฟฟิกเมลลิงลิสต์ และรายงานที่ผิดรูปแบบใน fixture ที่แยกออกมา

ยืนยันตัวตนอีเวนต์ของผู้ให้บริการก่อนนำไปใช้

หากผู้ให้บริการส่งอีเวนต์อีเมลตีกลับผ่าน webhook ให้ตรวจสอบลายเซ็นหรือกลไกการยืนยันตัวตนที่ระบุไว้เหนือคำขอที่แน่นอนก่อนแยกวิเคราะห์ฟิลด์ทางธุรกิจ บังคับใช้ความสดของ timestamp การป้องกัน replay ขีดจำกัดขนาด body และการเชื่อมโยง tenant บันทึกหรือเข้าคิวอีเวนต์ที่ยืนยันตัวตนแล้วก่อนตอบว่าสำเร็จ จากนั้นกำจัดข้อมูลซ้ำด้วยตัวระบุอีเวนต์ของผู้ให้บริการที่คงที่ หรือคีย์ผสมแบบระมัดระวังที่ไม่รวมผู้รับหรือความพยายามเข้าด้วยกัน เก็บเวลาที่เกิดแยกจากเวลาประมวลผล เพราะอีเวนต์อาจล่าช้าและมาไม่เรียงลำดับ ปฏิเสธอีเวนต์ที่โดเมนผู้ส่ง บัญชี เวิร์กสเปซ ตัวระบุข้อความ หรือขอบเขตผู้รับไม่สามารถเชื่อมโยงกับ tenant ที่คาดไว้ได้ หมุนเวียนความลับของ webhook แยกจากข้อมูลรับรอง SMTP หรือ API ติดตามความล้มเหลวของลายเซ็น อัตราซ้ำ ความล่าช้า dead letter และประเภทอีเวนต์ที่ไม่รู้จัก webhook ที่ยืนยันตัวตนแล้วพิสูจน์แหล่งที่มาภายใต้ความลับที่กำหนดไว้ ไม่ได้พิสูจน์ว่าอีเวนต์ถูกแมปกับงานภายในที่ถูกต้องจนกว่าการเชื่อมโยงจะสำเร็จ

วินิจฉัยตามตระกูลสถานะ ไม่ใช่ตามถ้อยคำที่เดา

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

วัดสุขภาพอีเมลตีกลับโดยไม่รั่วไหลข้อมูลผู้รับ

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

SendHQ เหมาะกับการใช้งานอย่างไร

SendHQ จัดทำเอกสารการติดตามการส่งถึงและอีเมลตีกลับ รวมถึงการระงับการส่ง ดูเอกสารปัจจุบันสำหรับพฤติกรรมที่รองรับ

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

แหล่งอ้างอิง

• ข้อกำหนด RFC 3464: An Extensible Message Format for Delivery Status Notifications — RFC Editor
• ข้อกำหนด RFC 3463: Enhanced Mail System Status Codes — RFC Editor
• ข้อกำหนด RFC 5321: Simple Mail Transfer Protocol — RFC Editor
• ข้อกำหนด RFC 3834: Recommendations for Automatic Responses to Electronic Mail — RFC Editor