ทีมผลิตภัณฑ์ควรนำ Mailgun API ไปใช้อย่างปลอดภัยได้อย่างไร

กำหนดการดำเนินการของผลิตภัณฑ์ให้แคบก่อนเรียก Mailgun

เริ่มจากอีเวนต์ของผลิตภัณฑ์ที่อนุมัติแล้ว เช่น การยืนยันบัญชี ใบเสร็จ การแจ้งเตือนความปลอดภัย หรือการแจ้งเตือนที่ผู้รับร้องขอ วาง Mailgun ไว้หลังบริการแอปพลิเคชันหรือ queue worker ที่เชื่อถือได้ แทนที่จะเปิดเผยข้อมูลรับรองของผู้ให้บริการหรือฟอร์มข้อความแบบใดก็ได้ให้เบราว์เซอร์และแอปมือถือ ตรวจสอบสิทธิ์ของผู้เรียก tenant ตัวตนผู้ส่ง ผู้รับ ประเภทข้อความ และเทมเพลต ก่อนสร้างฟิลด์ของผู้ให้บริการ เก็บบันทึกขาออกภายในที่มี event key คงที่ tenant revision ของเทมเพลต ที่อยู่ที่อนุมัติ และสถานะเริ่มต้น บันทึกนี้คือระบบตัดสินใจ ส่วน Mailgun เป็นเพียงส่วนพึ่งพาด้านการขนส่ง การแยกเจตนาทางธุรกิจออกจาก payload ของผู้ให้บริการทำให้การลองใหม่และการตรวจสอบปลอดภัยขึ้น และเปิดทางให้ย้ายผู้ให้บริการในภายหลัง ทราฟฟิก transactional และที่ขึ้นกับความยินยอมควรแยกกันในโมเดลข้อมูล เพื่อให้ความต้องการของผู้รับ กฎการระงับการส่ง และเหตุการณ์ด้านชื่อเสียงไม่กลายเป็นเพียงธรรมเนียมของเทมเพลต

ยืนยันโดเมนผู้ส่งที่ตรงกันและเรคคอร์ด DNS

เพิ่มโดเมนที่องค์กรควบคุม และเผยแพร่เรคคอร์ด DNS ที่ Mailgun ให้ในปัจจุบันสำหรับการยืนยัน การยืนยันตัวตน การติดตาม และฟีเจอร์การรับที่เลือกใช้จริง ตรวจสอบเรคคอร์ด SPF และ DMARC ที่มีอยู่ก่อนเปลี่ยน DNS อย่าสร้างเรคคอร์ด SPF ที่สองที่โฮสต์เดียวกัน หรือแทนที่นโยบาย DMARC ขององค์กรโดยไม่มีเจ้าของอนุมัติ ตรวจสอบตัวตน From และผู้ลงลายเซ็นที่งานใช้จริง ไม่ใช่แค่โดเมนแม่ที่อยู่ติดกัน ใช้ซับโดเมนเฉพาะวัตถุประสงค์เมื่อความเป็นเจ้าของ การแยกทราฟฟิก หรือการย้ายระบบสมควร หลัง Mailgun รายงานว่ายืนยันแล้ว ให้ตรวจข้อความที่ได้รับแบบควบคุมสำหรับที่อยู่ From ที่มองเห็น โดเมนลงลายเซ็น DKIM return path ผลการยืนยันตัวตน และพฤติกรรมการตอบกลับ การยืนยันของผู้ให้บริการเป็นหลักฐานว่าการตรวจสอบการตั้งค่าของผู้ให้บริการผ่านแล้ว ไม่ได้พิสูจน์ความยินยอมของผู้รับ การยอมรับของปลายทาง ชื่อเสียงผู้ส่ง หรือการเข้ากล่องจดหมาย เก็บประวัติการเปลี่ยน DNS และคำแนะนำการย้อนกลับไว้นอกแดชบอร์ดของผู้ให้บริการ

ใช้ข้อมูลรับรองที่จำกัดขอบเขตและ endpoint ประจำภูมิภาคที่ถูกต้อง

Mailgun ระบุการยืนยันตัวตนแบบ HTTP Basic สำหรับ API โดยข้อมูลรับรอง API ต่างกันตามอำนาจและวัตถุประสงค์ worker ที่ส่งควรได้รับเฉพาะข้อมูลรับรองที่จำเป็นสำหรับโดเมนและการดำเนินการที่อนุมัติ แยกคีย์บัญชีหลัก คีย์ส่งของโดเมน วัสดุลงลายเซ็น webhook และข้อมูลรับรองของสภาพแวดล้อมระดับล่างออกจากกัน เก็บความลับไว้ในที่เก็บความลับที่มีการจัดการโดยตรง และเปิดเผยเฉพาะกระบวนการเซิร์ฟเวอร์ที่ต้องใช้ ห้ามใส่ข้อมูลรับรองในโค้ดฝั่งไคลเอนต์ ระบบควบคุมซอร์ส URL ล็อก ระบบวิเคราะห์ เทมเพลต ตั๋ว หรือพรอมต์ เลือก base URL ของ API ตามที่มีเอกสารสำหรับภูมิภาคของบัญชี แทนที่จะสันนิษฐานว่าทุกโดเมนใช้โฮสต์เดียวกัน ซ้อมการหมุนเวียนโดยสร้างตัวแทนที่มีขอบเขตเทียบเท่า อัปเดต worker ตรวจสอบทราฟฟิกและอีเวนต์แบบควบคุม แล้วจึงเพิกถอนข้อมูลรับรองเดิม แจ้งเตือนเมื่อมีความล้มเหลวด้านการยืนยันตัวตนและการอนุญาตที่ไม่คาดคิด เพราะอาจบ่งชี้การเพิกถอน ภูมิภาคไม่ถูกต้อง ขอบเขตคลาดเคลื่อน หรือการรั่วไหล

สร้างคำขอ Messages API ที่ทนทานหนึ่งรายการ

endpoint Messages ที่จำกัดขอบเขตตามโดเมนของ Mailgun รับฟิลด์ฟอร์มแบบ multipart สำหรับผู้ส่ง ผู้รับ หัวเรื่อง เนื้อหาข้อความหรือ HTML และตัวเลือกที่มีเอกสาร เช่น เทมเพลต ไฟล์แนบ เฮดเดอร์ แท็ก ตัวแปรของผู้รับ การติดตาม และการส่งตามกำหนดเวลา เปิดเผยเฉพาะส่วนย่อยที่ผลิตภัณฑ์ต้องใช้ ตรวจสอบไวยากรณ์ที่อยู่และความเป็นเจ้าของ tenant จำกัดจำนวนผู้รับและไฟล์แนบ ปฏิเสธการแทรกบรรทัดใหม่ และเรนเดอร์เทมเพลตที่อนุมัติด้วยตัวแปรที่มีชนิด อย่าใส่ความลับหรือข้อมูลส่วนบุคคลที่ไม่จำเป็นในแท็ก ตัวแปรกำหนดเอง หรือเฮดเดอร์ เพราะอีเวนต์และมุมมองกิจกรรมของผู้ให้บริการอาจแสดงเมทาดาทาแยกจากเนื้อหาข้อความ ส่งจากงานภายในที่มีการ claim แล้ว และเก็บตัวระบุข้อความที่ Mailgun ส่งกลับมากับความพยายามนั้นโดยตรง เก็บชื่อตัวเลือกเฉพาะของผู้ให้บริการไว้ใน adapter เดียว โค้ดทางธุรกิจควรได้รับผลลัพธ์ที่แคบ คือยอมรับ ปฏิเสธ หรือไม่แน่นอน แทนที่จะต้องรู้ทุกฟิลด์และรูปแบบข้อผิดพลาดของ Mailgun

ออกแบบการลองใหม่โดยคำนึงถึงการยอมรับและความกำกวม

จำแนกการตอบกลับก่อนลองใหม่ แก้ฟิลด์ที่ผิดรูป โดเมนที่ไม่ได้รับอนุญาต ข้อมูลรับรองที่ไม่ถูกต้อง ความล้มเหลวด้านสิทธิ์ และข้อผิดพลาดนโยบายถาวร แทนการเล่นซ้ำ ลองใหม่ความล้มเหลวของการขนส่ง ข้อผิดพลาดเซิร์ฟเวอร์ของผู้ให้บริการ และคำขอที่ถูกจำกัดอัตราที่เข้าเกณฑ์ ด้วย exponential backoff, jitter, จำนวนครั้งจำกัด และขีดจำกัดอายุคิว การตอบกลับ API ที่ยอมรับของ Mailgun หมายความว่าผู้ให้บริการยอมรับคำขอส่งเพื่อประมวลผล ไม่ได้พิสูจน์ว่าเซิร์ฟเวอร์ปลายทางยอมรับข้อความ การ timeout ของไคลเอนต์กำกวม เพราะ Mailgun อาจยอมรับคำขอแล้วแม้ worker พลาดการตอบกลับ ให้ค้างงานนั้นในสถานะไม่ทราบ ค้นหาข้อมูลเชื่อมโยงที่เก็บไว้หรืออีเวนต์ภายหลัง และใช้กฎกระทบยอดที่ตั้งใจไว้ก่อนส่งซ้ำ การขนส่งผ่าน Mailgun ไม่ได้ลบความจำเป็นของ event key ของแอปพลิเคชันที่คงที่ การอ้างสิทธิ์โดย worker เดียว ประวัติความพยายาม และการควบคุมความเสี่ยงการส่งซ้ำ แจ้งเตือนเมื่อล้มเหลวซ้ำ ๆ ตามข้อมูลรับรอง โดเมน เทมเพลต tenant และผู้ให้บริการปลายทาง

ยืนยันตัวตนของคำขอ webhook ก่อนแยกวิเคราะห์

ตั้งค่า endpoint webhook แบบ HTTPS และเก็บฟิลด์ที่ตรงกันทุกตัวอักษรซึ่งใช้ในขั้นตอนการลงลายเซ็นของ Mailgun Mailgun ระบุ timestamp, token และ signature ที่คำนวณด้วย webhook signing key ตรวจสอบลายเซ็นด้วยการเปรียบเทียบแบบ constant-time และปฏิเสธ timestamp ที่อยู่นอกช่วงความสดใหม่ของแอปพลิเคชันก่อนยอมรับอีเวนต์ ติดตาม token หรือตัวระบุอีเวนต์ตามที่ต้องใช้เพื่อป้องกันการเล่นซ้ำ แยก webhook signing key ออกจากข้อมูลรับรองสำหรับส่ง และหมุนเวียนผ่านกระบวนการที่ทดสอบแล้ว กำหนดขีดจำกัดขนาดคำขอ และอย่าเชื่อ URL ผู้รับ แท็ก หรือฟิลด์อีเวนต์เพียงเพราะเนื้อหาแยกวิเคราะห์ได้ หลังยืนยันตัวตน ให้จัดเก็บหรือเข้าคิวอีเวนต์อย่างทนทานก่อนส่งการตอบกลับสำเร็จ เพื่อป้องกันไม่ให้กระบวนการล่มทำให้หลักฐานการส่งหาย การยืนยัน webhook พิสูจน์ต้นทางและความสมบูรณ์ภายใต้ความลับที่ตั้งค่าไว้ ไม่ได้พิสูจน์ว่าเหตุการณ์ทางธุรกิจเป็นของ tenant ที่คาดไว้ จนกว่าแอปพลิเคชันจะเชื่อมโยงโดเมนและตัวระบุข้อความของผู้ให้บริการ

จัดการการลองใหม่ของ webhook และอีเวนต์ซ้ำแบบ idempotent

Mailgun ระบุพฤติกรรมการลองใหม่ของ webhook เมื่อ endpoint ไม่ตอบกลับสำเร็จตามที่คาดไว้ ผู้รับต้องสมมติว่าการส่งอาจล่าช้าและซ้ำ ตัดข้อมูลซ้ำด้วยตัวระบุอีเวนต์ของผู้ให้บริการที่คงที่เมื่อมี หรือด้วยค่าผสมแบบระมัดระวังที่ไม่รวมผู้รับหรือชนิดอีเวนต์ที่ต่างกัน เก็บเวลาที่เกิดเหตุการณ์เดิมและเวลาประมวลผลแยกกัน ทำให้การเปลี่ยนสถานะเป็นแบบทิศทางเดียว เพื่อไม่ให้การสังเกตว่ายอมรับหรือส่งถึงที่เก่ากว่าลบความล้มเหลวถาวร การร้องเรียน หรือการยกเลิกการรับที่ใหม่กว่าเพียงเพราะการลองใหม่มาไม่เรียงลำดับ ส่งการตอบกลับสำเร็จหลังบันทึกอย่างทนทานเท่านั้น แต่ให้การประมวลผลทางธุรกิจที่หนักเป็นแบบอะซิงโครนัส เพื่อให้ endpoint เชื่อถือได้ ติดตามความล้มเหลวของลายเซ็น ความหน่วงของการตอบกลับ ปริมาณการลองใหม่ ความล่าช้าของอีเวนต์ และเรคคอร์ด dead-letter เก็บ payload ดิบของผู้ให้บริการเท่าที่ความจำเป็นด้านการปฏิบัติการและนโยบายให้เหตุผล โดยจำกัดการเข้าถึงและลดข้อมูลที่อยู่ webhook เป็นฟีดหลักฐาน ไม่ใช่สิทธิ์ในการเปิดเผยประวัติผู้รับข้าม tenant

สร้างโมเดลอีเวนต์ของ Mailgun โดยไม่กล่าวเกินจริงเรื่องการส่งถึง

Mailgun ระบุชนิดอีเวนต์สำหรับ accepted, delivered, ความล้มเหลวชั่วคราวและถาวร, opened, clicked, unsubscribed, complained, stored และผลลัพธ์การประมวลผลที่เกี่ยวข้อง แมปชื่อเหล่านี้เข้ากับโมเดลภายใน พร้อมเก็บชนิดอีเวนต์ของผู้ให้บริการ ตัวระบุข้อความ ขอบเขตผู้รับ เวลา ระดับความรุนแรง และการตอบกลับ SMTP ที่มี Accepted อธิบายการรับเข้าหรือความคืบหน้าในคิวของ Mailgun Delivered อธิบายการสังเกตการส่งถึงที่มีเอกสาร ซึ่งมักหมายถึงเซิร์ฟเวอร์ปลายทางยอมรับ แต่ไม่ได้เปิดเผยโฟลเดอร์สุดท้ายของกล่องจดหมาย การเปิดและการคลิกเป็นเครื่องมือวัดการมีส่วนร่วม ไม่ใช่หลักฐานการขนส่ง และเทคโนโลยีความเป็นส่วนตัวอาจส่งผลต่อค่าเหล่านั้น ความล้มเหลวชั่วคราวอาจสมเหตุสมผลให้ลองใหม่แบบมีขอบเขตภายในระบบขนส่ง ส่วนความล้มเหลวถาวร การร้องเรียน และการยกเลิกการรับ ต้องอัปเดตสถานะความปลอดภัยของผู้รับก่อนส่งงานของแอปพลิเคชันถัดไป เก็บบัญชีอีเวนต์แบบ append-only และสร้างสถานะที่ผู้ใช้เห็นจากกฎที่ชัดเจน เพื่อให้ซัพพอร์ตแยกหลักฐานออกจากการตีความได้

บังคับใช้ความล้มเหลว การร้องเรียน และการยกเลิกการรับ ณ เวลาส่ง

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

พิจารณา SendHQ เป็นทางเลือกแทน Mailgun

SendHQ มีอีเมล transactional และอีเมลการตลาดที่ได้รับความยินยอม พร้อมการส่งจากโดเมนที่ยืนยันแล้ว อีเมลขาเข้า อีเวนต์การส่ง และการระงับการส่ง ตรวจทานเอกสาร API สาธารณะและทดสอบการยืนยันตัวตน payload ข้อผิดพลาด ตัวระบุ อีเวนต์ โดเมน และเวิร์กโฟลว์ความปลอดภัยของผู้รับก่อนย้ายระบบ

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

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

• Mailgun Messages API — Mailgun
• การยืนยันตัวตน Mailgun API — Mailgun
• การยืนยันโดเมน Mailgun — Mailgun
• ชนิดอีเวนต์ของ Mailgun — Mailgun
• การรักษาความปลอดภัย Mailgun Webhook — Mailgun
• การลองใหม่ของ Mailgun Webhook — Mailgun
• การติดตามความล้มเหลวในการส่งของ Mailgun — Mailgun
• การติดตามการร้องเรียนสแปมของ Mailgun — Mailgun
• การติดตามการยกเลิกการรับของ Mailgun — Mailgun
• ข้อกำหนด RFC 5321: Simple Mail Transfer Protocol — RFC Editor
• สัญญา OpenAPI ของ SendHQ — SendHQ