ทีมผลิตภัณฑ์ควรใช้ Cloudflare email routing อย่างปลอดภัยอย่างไร

กำหนดงานขาเข้าและขอบเขตความเป็นเจ้าของ

เริ่มด้วยการเขียนงานขาเข้าให้ชัดเจน ได้แก่ โดเมนและ local part ใดที่ควรรับเมล ใครเป็นเจ้าของแต่ละปลายทาง ข้อความควรถูกส่งต่อ ประมวลผลด้วยโค้ด หรือทิ้ง และหลักฐานการปฏิบัติงานเก็บไว้ได้นานเท่าใด Cloudflare Email Routing เป็นเลเยอร์การกำหนดเส้นทางขาเข้า ตัวมันเองไม่ได้สร้างตั๋วซัพพอร์ต ไม่ได้ยืนยันตัวตนผู้ส่ง ไม่ได้พิสูจน์ว่าเมลที่ส่งต่อไปถึงมนุษย์ และไม่ได้รับประกันการเข้ากล่องจดหมายที่ปลายทาง ให้แยกสถานะของแอปพลิเคชันในขั้นถัดไปเหล่านั้นออกจากกัน มอบหมายเจ้าของด้านการปฏิบัติงานสำหรับ DNS กฎการกำหนดเส้นทาง โค้ด Worker การยืนยันปลายทาง เหตุการณ์ด้านความปลอดภัย และการย้อนกลับ ใช้ alias เฉพาะ เช่น support@ หรือ invoices@ แทน catch-all ในการเปิดใช้ครั้งแรก เส้นทางที่แคบช่วยลดการเก็บข้อมูลโดยไม่ตั้งใจ ทำให้ตีความผลการทดสอบได้ และจำกัดผลกระทบจากปลายทางหรือสาขาของ Worker ที่ผิดพลาด

นำโดเมนเข้าสู่ระบบโดยไม่ถือว่า DNS เป็นขั้นตอนติดตั้งที่ทำโดยไม่ตรวจสอบ

เอกสาร Email Service ปัจจุบันของ Cloudflare ระบุว่าโดเมนต้องใช้ Cloudflare DNS สำหรับ Email Routing ขั้นตอน onboarding สามารถเพิ่มเรคคอร์ด MX สำหรับการกำหนดเส้นทางขาเข้า รวมถึงเรคคอร์ด TXT ที่เกี่ยวกับ SPF และ DKIM ตามที่ผลิตภัณฑ์อธิบายไว้ ให้ตรวจสอบเรคคอร์ดที่เสนอทุกรายการอย่างละเอียดก่อนนำไปใช้ ตรวจสอบรายการ MX, SPF, DKIM, DMARC กล่องจดหมาย บริการส่งต่อ โทเค็นยืนยัน และการมอบหมายซับโดเมนที่มีอยู่ก่อน การแทนที่เรคคอร์ด MX เปลี่ยนปลายทางของเซสชัน SMTP ขาเข้าใหม่ ดังนั้นควรประสานช่วงเวลาบำรุงรักษา และเก็บค่าเดิมไว้เป็นบันทึกสำหรับย้อนกลับ หลีกเลี่ยงการสร้างเรคคอร์ด SPF TXT หลายรายการที่ owner name เดียวกัน หลังการเปลี่ยนแปลง ให้ค้นหาจาก resolver แบบ authoritative และสาธารณะ แล้วทดสอบการส่งจากบัญชีที่ไม่เกี่ยวข้องกับปลายทาง ค่าประมาณการแพร่กระจายของ DNS ไม่ใช่หลักฐานว่าผู้ส่งทุกรายเห็นคำตอบเดียวกันแล้ว และแดชบอร์ดที่เป็นสีเขียวไม่ได้พิสูจน์การส่งต่อแบบ end-to-end

ยืนยันปลายทางก่อนสร้างเส้นทางที่ใช้งานจริง

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

สร้างกฎที่ชัดเจนและเข้าใจลำดับความสำคัญ

กฎการกำหนดเส้นทางจับคู่รูปแบบอีเมลกับปลายทางที่ยืนยันแล้วหรือ Worker Cloudflare ระบุการดำเนินการสามอย่าง คือ ส่งไปยังอีเมล ส่งไปยัง Worker และทิ้ง ให้สร้างเส้นทาง local part ที่เจาะจงที่สุดก่อน ระบุเจ้าของในบันทึกการเปลี่ยนแปลง และยืนยันว่ามีกฎที่ตั้งใจเพียงหนึ่งกฎต่อหนึ่งรูปแบบ เอกสารเตือนว่าหากมีหลายกฎใช้รูปแบบเดียวกัน จะมีเพียงกฎที่อยู่ก่อนเท่านั้นที่ประมวลผลเมลขาเข้า อย่าพึ่งพาลำดับที่มองเห็นเป็นกฎธุรกิจแบบไม่เป็นทางการ ให้ขจัดความกำกวมออกแทน ใช้กฎ drop อย่างมีเหตุผลรองรับที่แคบ เพราะการทิ้งคือการไม่ส่งถึงโดยตั้งใจ เปิด catch-all หลังจากระบุผลกระทบด้านความเป็นส่วนตัว ปริมาณสแปม การพิมพ์ผิด และการจัดเก็บครบถ้วนแล้วเท่านั้น catch-all อาจเก็บที่อยู่ที่ไม่มีใครตั้งใจสร้าง จึงควรมีปลายทางหรือนโยบาย Worker เฉพาะ การแจ้งเตือน และเส้นทางปิดใช้งานที่รวดเร็ว แทนที่จะสืบทอดกล่องจดหมายส่วนตัวอย่างเงียบ ๆ

ใช้ subaddressing อย่างตั้งใจ

Cloudflare ระบุว่ามี plus addressing แบบเลือกได้ซึ่งสอดคล้องกับ RFC 5233 เมื่อเปิดใช้ เมลสำหรับที่อยู่เช่น user+detail@example.com สามารถตรงกับกฎพื้นฐาน user@example.com โดยคงส่วน detail ไว้ในผู้รับของข้อความที่เปิดให้ Worker และบันทึกเห็น ซึ่งใช้เป็นแท็กการกำหนดเส้นทาง ตัวระบุการทดสอบ หรือ alias ต่อเวิร์กโฟลว์ได้ แต่ส่วน detail เป็นข้อความที่ผู้ส่งควบคุม อย่าถือว่าเป็นตัวตนผู้เช่าที่ผ่านการยืนยัน การอนุญาต หรือความลับ ให้ทำให้เป็นมาตรฐานและจำกัดขอบเขตก่อนนำไปใช้เป็นคีย์ฐานข้อมูล มิติของเมตริก หรือชื่อคิว Cloudflare ยังระบุว่ากฎที่ชัดเจนสำหรับ subaddress แบบเต็มมีลำดับความสำคัญเหนือกฎพื้นฐาน ให้ทดสอบทั้งกรณีที่ชัดเจนและกรณี fallback เพื่อไม่ให้กฎเฉพาะที่เพิ่มภายหลังเปลี่ยนเวิร์กโฟลว์เดิมอย่างเงียบ ๆ หลีกเลี่ยงการใส่ข้อมูลส่วนบุคคลหรือข้อมูลลับใน plus tag เพราะอาจปรากฏในเฮดเดอร์ บันทึก ข้อความที่ส่งต่อ การส่งออกของซัพพอร์ต และระบบวิเคราะห์

เลือก Worker เฉพาะเมื่อมีความต้องการประมวลผลจริง

ใช้การส่งต่อโดยตรงเมื่อความต้องการเป็นเพียงหนึ่งที่อยู่ไปยังหนึ่งกล่องจดหมายที่ยืนยันแล้ว กำหนดเส้นทางไปยัง Worker เมื่อต้องการการแตกสาขาที่ควบคุมได้ การตรวจสอบข้อความ การจัดเก็บ การปฏิเสธ การตอบกลับ หรือการส่งต่อหลายปลายทาง email handler ของ Cloudflare เปิดเผยผู้ส่งและผู้รับใน envelope เฮดเดอร์ สตรีม MIME ดิบ ขนาดของมัน และเมธอดสำหรับส่งต่อ ตอบกลับ หรือปฏิเสธ ให้เก็บ handler ให้เล็ก ตรวจสอบนโยบายผู้รับก่อน บังคับขอบเขตข้อความและการแยกวิเคราะห์ เรียกบริการภายนอกผ่านคิวที่จำกัดเวลาเมื่อทำได้ และกำหนดผลลัพธ์สำหรับทุกข้อผิดพลาด เฮดเดอร์ หัวเรื่อง ชื่อที่แสดง ไฟล์แนบ ลิงก์ และ MIME boundary ล้วนถูกผู้โจมตีควบคุมได้ อย่าบันทึกเนื้อหาดิบหรือที่อยู่แบบเต็มโดยค่าเริ่มต้น หากต้องเก็บเนื้อหา ให้เข้ารหัส จำกัดการเข้าถึงตามผู้เช่าและงาน กำหนดการลบ และสแกนไฟล์แนบนอกเส้นทางการกำหนดเส้นทางแบบซิงโครนัส ข้อผิดพลาดในการแยกวิเคราะห์ต้องไม่หลุดไปสู่การส่งต่อหรือการตอบกลับที่ไม่ได้ตั้งใจ

ใช้เส้นทางการตัดสินใจที่ชัดเจนเพียงเส้นทางเดียว

handler ที่ปลอดภัยควรคำนวณการดำเนินการที่ได้รับอนุมัติก่อนทำสิ่งที่มีผลข้างเคียง ตัวอย่างเช่น จับคู่ผู้รับใน envelope ที่ตรงตัวกับเวิร์กโฟลว์ที่ตั้งค่าไว้ ปฏิเสธผู้รับที่ไม่รู้จัก ใส่เรคคอร์ดเมทาดาทาที่มีขอบเขตเข้าคิว แล้วส่งต่อไปยังปลายทางที่ยืนยันแล้วซึ่งเลือกจากการตั้งค่าเท่านั้น อย่ารับปลายทางจากเฮดเดอร์ หัวเรื่อง plus tag หรือเนื้อหาของข้อความ เมื่อส่งต่อไปหลายปลายทาง เอกสารข้อจำกัดของ Cloudflare ระบุว่า Worker ต้องเรียก forward หนึ่งครั้งต่อหนึ่งปลายทางที่ยืนยันแล้ว ให้ตัดสินใจว่ายอมรับความสำเร็จบางส่วนได้หรือไม่ และบันทึกแต่ละความพยายามแยกกัน ใช้ตัวระบุการเชื่อมโยงภายในที่คงที่ แทนเนื้อหาของผู้รับในบันทึก หาก handler อาจตอบกลับ ให้ทำตามข้อจำกัดการตอบกลับปัจจุบันของ Cloudflare และเพิ่มการป้องกันการวนซ้ำ การตอบกลับไม่ใช่การตอบรับจากทีมที่เป็นมนุษย์ หากต้องการการรับงานของแอปพลิเคชันที่คงทน ให้จัดเก็บตั๋วหรืออีเวนต์ก่อนส่งการตอบกลับอัตโนมัติ และกระทบยอดความล้มเหลวที่กำกวม แทนที่จะสัญญาว่าสร้างงานแล้ว

มองการส่งต่อและการตอบกลับเป็นผลลัพธ์ที่มีหลักฐานตามขอบเขต

การเรียกเมธอดของ Worker ที่สำเร็จเป็นหลักฐานเกี่ยวกับการทำงานของแพลตฟอร์ม ไม่ใช่ผลลัพธ์ปลายทางของผู้ใช้ SMTP กำหนดการถ่ายโอนระหว่างระบบ ส่วนการกรอง การส่งต่อ การกักกัน กฎกล่องจดหมาย และการอ่านโดยมนุษย์ในภายหลังอยู่นอกช่วงนั้น ให้จำลองสถานะต่าง ๆ เช่น Cloudflare รับแล้ว Worker ถูกเรียก พยายามดำเนินการ เซิร์ฟเวอร์ปลายทางยอมรับ ล่าช้าหรือล้มเหลว และสร้างเรคคอร์ดของแอปพลิเคชันแล้ว แยกจากกัน อย่าตีป้ายทั้งหมดว่าส่งถึง เก็บบันทึกแบบมีโครงสร้างที่ลดข้อมูลส่วนบุคคล พร้อมตัวตนของกฎ revision ของ Worker การดำเนินการ เวลา ตัวระบุการเชื่อมโยง และผลลัพธ์แบบหยาบ เก็บที่อยู่แบบเต็มหรือเนื้อหาเฉพาะที่มีความจำเป็นในการปฏิบัติงานตามเอกสารรองรับ แจ้งเตือนเมื่อการเรียกล้มเหลว ถูกปฏิเสธเพราะขนาด ปริมาณ catch-all ผิดปกติ รูปแบบผู้ส่งซ้ำ ปลายทางล้มเหลว และทราฟฟิกเปลี่ยนแปลงกะทันหัน สุ่มตัวอย่างข้อความทดสอบแบบควบคุมอย่างต่อเนื่อง แต่อย่าใช้เนื้อหาลูกค้าจริงเป็น fixture สำหรับการสังเกตการณ์

เคารพขีดจำกัดและรูปแบบความล้มเหลวของแพลตฟอร์มในปัจจุบัน

Cloudflare ระบุขีดจำกัดของ Email Routing ในปัจจุบัน ได้แก่ กฎการกำหนดเส้นทาง 200 กฎต่อโดเมน ที่อยู่ปลายทาง 200 รายการต่อบัญชี ขีดจำกัดขนาดข้อความขาเข้า 25 MiB และขีดจำกัด CPU และหน่วยความจำของ Workers มาตรฐานสำหรับข้อความที่กำหนดเส้นทางผ่าน Worker ให้ถือว่านี่คือเอกสารของผู้ให้บริการในปัจจุบัน ไม่ใช่ค่าคงที่ถาวร อ่านหน้าขีดจำกัดฉบับล่าสุดระหว่างการวางแผน และแจ้งเตือนก่อนถึงเพดานมาก ๆ ข้อความ MIME ขนาดใหญ่อาจใช้หน่วยความจำหรือ CPU หมดได้ แม้ต่ำกว่าเพดานขนาดดิบของแพลตฟอร์ม หากถอดรหัสอย่างไม่ระมัดระวัง ให้สตรีมหรือปฏิเสธเนื้อหาที่ไม่จำเป็น จำกัดจำนวนไฟล์แนบ และวางการแยกวิเคราะห์ที่ใช้ทรัพยากรมากไว้หลังงานแบบอะซิงโครนัสที่มีขอบเขต ตามเอกสาร routing ของ Cloudflare การเปลี่ยนชื่อ Worker อาจทำให้ routing binding เสียหาย จึงควรรวมการตรวจสอบเส้นทางไว้ในการตรวจสอบการ deploy การเรียกที่ล้มเหลวควรมองเห็นได้ในบันทึกของ Workers แต่บันทึกอย่างเดียวไม่ได้ทำให้เล่นซ้ำได้ ให้ตัดสินใจว่าผู้ส่งควรลองใหม่ผ่าน SMTP หรือไม่ ผู้ปฏิบัติงานเล่นงานของแอปพลิเคชันซ้ำได้อย่างปลอดภัยหรือไม่ และป้องกันเรคคอร์ดปลายทางซ้ำอย่างไร

ทดสอบการเปิดใช้และการย้อนกลับเป็นการเปลี่ยนแปลงเดียวกัน

สร้างเส้นทางสำหรับ staging หรือความเสี่ยงต่ำก่อน ส่งข้อความทดสอบแบบควบคุมจากบัญชีที่ต่างจากปลายทางที่ยืนยันแล้ว ครอบคลุมข้อความล้วน เนื้อหา multipart ไฟล์แนบที่คาดไว้ plus addressing local part ที่ไม่รู้จัก และอินพุตที่ผิดรูปแบบโดยตั้งใจภายในขีดจำกัดที่ปลอดภัย ตรวจสอบคำตอบ DNS การตั้งค่าแดชบอร์ด revision ของ Worker ผลการส่งต่อ เรคคอร์ดปลายทาง และพฤติกรรมด้านความเป็นส่วนตัว จากนั้นทดสอบเส้นทางเชิงลบ ได้แก่ ปลายทางที่ไม่ได้ยืนยัน กฎที่ปิดใช้งาน ข้อยกเว้นของ Worker ข้อความขนาดเกิน การส่งซ้ำ และกฎที่อาจตกไปที่ catch-all บันทึกหลักฐานที่คาดหวังของแต่ละขั้น ก่อนขยายทราฟฟิก ให้ซ้อมการปิดใช้งานกฎ การคืนเรคคอร์ด MX เดิมหากจำเป็น การถอด Worker และการสื่อสารเรื่องเมลที่ล่าช้าหรือถูกปฏิเสธ ให้ย้อนกลับเมื่อมีการสูญหายของการกำหนดเส้นทางโดยไม่ทราบสาเหตุ การเปิดเผยข้ามผู้เช่า เนื้อหารั่วไหล การตอบกลับที่ไม่คาดคิด การจัดเก็บที่ไร้ขอบเขต หรือ Worker ล้มเหลวต่อเนื่อง เก็บสแนปช็อตการตั้งค่าและผลการทดสอบไว้ โดยไม่เก็บเนื้อหาข้อความนานเกินจำเป็น

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

SendHQ รองรับอีเมลขาเข้า คู่มือนี้ครอบคลุม Cloudflare Email Routing ให้ทำตามเอกสารของแต่ละบริการสำหรับการตั้งค่าและขีดจำกัดของบริการนั้น

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

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

• การกำหนดเส้นทางอีเมล — Cloudflare
• กฎและที่อยู่ของ Email Routing — Cloudflare
• Workers API สำหรับอีเมลที่กำหนดเส้นทาง — Cloudflare
• ขีดจำกัดของ Cloudflare Email Service — Cloudflare
• ข้อกำหนด RFC 5321: Simple Mail Transfer Protocol — RFC Editor
• ข้อกำหนด RFC 5233: Sieve Email Filtering: Subaddress Extension — RFC Editor