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

กำหนดขอบเขตของแอปพลิเคชันก่อนถึง Postmark

เริ่มจากอีเวนต์ทางธุรกิจที่ได้รับอนุญาต เช่น ใบเสร็จ การยืนยัน การแจ้งเตือนที่ร้องขอ หรือประกาศด้านความปลอดภัย บันทึกงานขาออกที่คงทนพร้อม event key ที่คงที่ ผู้เช่า ประเภทข้อความ revision ของเทมเพลต ผู้ส่งและผู้รับที่ได้รับอนุมัติ ฐานความยินยอมหรือความจำเป็น การตัดสินใจเรื่องการระงับการส่งปัจจุบัน และสถานะเริ่มต้น อินพุตจากเบราว์เซอร์ มือถือ เทมเพลต และผู้ใช้ต้องไม่เลือกโทเค็นเซิร์ฟเวอร์ของ Postmark ตัวตน From ตามอำเภอใจ message stream webhook ผู้รับที่ไม่จำกัด หรือเมทาดาทาของผู้ให้บริการ ให้วางการเรียกผู้ให้บริการทั้งหมดไว้หลัง adapter ฝั่งเซิร์ฟเวอร์ตัวเดียว แยกทราฟฟิก transactional ออกจากทราฟฟิก broadcast หรือการตลาดตามโมเดลความยินยอมและชื่อเสียงของผลิตภัณฑ์ API ของ Postmark ขนส่งข้อความ แต่ไม่ได้กำหนดการอนุญาตของผู้เช่า ความยินยอมของผู้รับ หรือ idempotency ทางธุรกิจ ให้อ้างสิทธิ์งานภายในเพียงครั้งเดียว บันทึกทุกความพยายามของผู้ให้บริการ และเก็บตัวระบุของผู้ให้บริการเป็นหลักฐานที่เชื่อมกับอีเวนต์ของแอปพลิเคชัน แทนที่จะใช้เป็นระบบบันทึกหลักเพียงระบบเดียว

ใช้โทเค็นเซิร์ฟเวอร์ที่มีขอบเขตการปฏิบัติงานแคบ

email API ของ Postmark มีเอกสารเกี่ยวกับเฮดเดอร์ X-Postmark-Server-Token สำหรับการเข้าถึง API ระดับเซิร์ฟเวอร์ เก็บโทเค็นแต่ละตัวไว้ในบริการความลับที่มีการจัดการ และเปิดให้เฉพาะ worker ที่ต้องใช้เซิร์ฟเวอร์และสภาพแวดล้อมนั้น ห้ามใส่โทเค็นในโค้ดฝั่งไคลเอนต์ ระบบควบคุมซอร์ส URL บันทึก ระบบวิเคราะห์ เทมเพลต ภาพหน้าจอ ตั๋ว prompt หรือ test fixture แยกระบบจริงออกจากการพัฒนาและผลิตภัณฑ์ที่ไม่เกี่ยวข้อง เพื่อให้การเพิกถอนหรือการใช้ในทางที่ผิดมีผลกระทบจำกัด ซ้อมการหมุนเวียนโดยเตรียมโทเค็นใหม่ผ่านการดูแลระบบที่ได้รับอนุมัติ อัปเดต worker ส่งข้อความทดสอบแบบควบคุม ยืนยันหลักฐานจาก API และอีเวนต์ แล้วจึงเพิกถอนโทเค็นเก่า ให้ถือว่าข้อผิดพลาดด้านการยืนยันตัวตนที่ไม่คาดคิดเป็นเงื่อนไขให้หยุดชั่วคราว ไม่ใช่เหตุให้ลองข้อมูลรับรองซ้ำอย่างรวดเร็ว จำกัดการดูแลแดชบอร์ดด้วยการยืนยันตัวตนที่แข็งแกร่งและบทบาท โทเค็นเซิร์ฟเวอร์อนุญาตการดำเนินการ Postmark API สำหรับเซิร์ฟเวอร์ของมัน แอปพลิเคชันยังต้องอนุญาตผู้เช่า ผู้ส่ง ผู้รับ เทมเพลต และประเภทข้อความ

ยืนยันตัวตนผู้ส่งที่แน่นอน

ใช้ sender signature หรือโดเมนที่ยืนยันแล้วซึ่งองค์กรควบคุม และยืนยันที่อยู่ From ที่ตรงตัวที่ทุกสตรีมใช้ ตรวจสอบโดเมน From ที่มองเห็น SMTP return path โดเมน DKIM d= และ selector ที่อยู่ตอบกลับ และ message stream ที่ใช้ส่ง จากตัวอย่างดิบที่ได้รับ เผยแพร่เฉพาะเรคคอร์ด DNS ที่ Postmark ต้องการในปัจจุบันสำหรับการตั้งค่าที่เลือก หลังตรวจสอบความเป็นเจ้าของ SPF, DKIM และ DMARC ที่มีอยู่ เก็บค่าก่อนหน้าและคำแนะนำการย้อนกลับไว้ การยืนยันของผู้ให้บริการเป็นหลักฐานว่าการตรวจสอบการตั้งค่าของตนผ่าน ไม่ได้พิสูจน์ว่าทุกเส้นทางของแอปพลิเคชันใช้ตัวตนนั้น มี DMARC alignment ผู้รับยินยอม หรือข้อความเข้ากล่องจดหมาย เก็บการอนุญาตผู้ส่งเฉพาะผู้เช่าไว้ในแอปพลิเคชัน และบล็อกค่า From ข้ามผู้เช่า ทดสอบซับโดเมน การตอบกลับ อีเมลตีกลับ สภาพแวดล้อมระดับล่าง และเส้นทางเทมเพลต อย่าลดความเข้มงวดของนโยบาย SPF หรือ DMARC ขององค์กรเพียงเพื่อให้ตัวบ่งชี้ในแดชบอร์ดเป็นสีเขียว

สร้างคำขอ POST email ที่ชัดเจนหนึ่งรายการ

Postmark มีเอกสารเกี่ยวกับ POST /email พร้อมฟิลด์ JSON สำหรับผู้ส่ง ผู้รับ หัวเรื่อง เนื้อหาข้อความหรือ HTML ReplyTo เฮดเดอร์ แท็กหรือเมทาดาทา message stream ไฟล์แนบ และตัวเลือกการติดตาม เปิดเผยเฉพาะฟิลด์ที่ผลิตภัณฑ์ต้องการ ตรวจสอบและทำให้ที่อยู่เป็นมาตรฐาน จำกัดจำนวนผู้รับและไฟล์แนบ ปฏิเสธ header injection escape ค่าเทมเพลตตามบริบทของเอาต์พุต และสร้างข้อความและ HTML จาก revision ที่ได้รับอนุมัติเดียวกัน อย่าใส่ความลับหรือข้อมูลส่วนบุคคลที่ไม่จำเป็นในแท็ก เมทาดาทา เฮดเดอร์ หัวเรื่อง หรือชื่อไฟล์แนบ เพราะอาจปรากฏในกิจกรรมและอีเวนต์ของผู้ให้บริการ เลือก MessageStream จากการตั้งค่าที่เชื่อถือได้ ไม่ใช่อินพุตของคำขอตามอำเภอใจ เก็บ payload ของผู้ให้บริการไว้ใน adapter เดียว เพื่อไม่ให้โค้ดทางธุรกิจพึ่งพาทุกฟิลด์ของ Postmark เก็บ revision ของเนื้อหาหรือแฮชที่ปลอดภัยต่อความเป็นส่วนตัวเมื่อความต้องการด้านการตรวจสอบสมเหตุสมผล แทนการบันทึกเนื้อหาข้อความทั้งหมด

ตีความการตอบกลับทันทีอย่างแคบ

endpoint ส่งอีเมลเดี่ยวของ Postmark มีเอกสารเกี่ยวกับฟิลด์การตอบกลับ ได้แก่ ErrorCode, Message, MessageID, SubmittedAt และข้อมูลผู้รับ บันทึกสถานะ HTTP ที่แน่นอนและการตอบกลับแบบมีโครงสร้างของผู้ให้บริการไว้กับความพยายามของแอปพลิเคชัน การตอบกลับที่สำเร็จและ MessageID แสดงว่า Postmark ยอมรับคำขอ API ตามความหมายที่ระบุไว้ ไม่ได้แสดงว่าเซิร์ฟเวอร์ปลายทางยอมรับข้อความหรือข้อความเข้ากล่องจดหมาย จัดประเภทข้อผิดพลาดด้านการตรวจสอบ sender signature การยืนยันตัวตน payload ผิดรูป โควตา และนโยบายก่อนลองใหม่ การหมดเวลาของคำขอกำกวม เพราะ Postmark อาจยอมรับการดำเนินการแล้วขณะที่ไคลเอนต์พลาดการตอบกลับ ให้คงความพยายามนั้นเป็นสถานะไม่ทราบ ค้นหากิจกรรมของผู้ให้บริการหรืออีเวนต์ภายหลังด้วยข้อมูลเชื่อมโยงที่ปลอดภัย และใช้กฎการกระทบยอดเฉพาะประเภทข้อความก่อนส่งซ้ำ อย่ารับปากว่าส่งถึงแบบ exactly-once หรือสร้างอีเวนต์เชิงตรรกะใหม่เพียงเพราะคำขอ HTTP หนึ่งรายการล้มเหลว

ออกแบบการลองใหม่ตามหลักฐานของผู้ให้บริการและ transport

ลองใหม่เฉพาะความล้มเหลวของเครือข่าย rate limit และข้อผิดพลาดเซิร์ฟเวอร์ของผู้ให้บริการที่เข้าเงื่อนไข ด้วย exponential backoff jitter จำนวนครั้งที่จำกัด และขีดจำกัดอายุคิว แก้ไขข้อผิดพลาดถาวรของคำขอ ผู้ส่ง ผู้รับ โทเค็น เทมเพลต และนโยบาย แทนการเล่นซ้ำ คง event key ของแอปพลิเคชันเดิมและบันทึกความพยายามที่เชื่อมโยงกัน ตรวจสอบการระงับการส่งและการอนุญาตอีกครั้งทันทีก่อนการลองใหม่แต่ละครั้ง เพราะสถานะของผู้รับหรือทางธุรกิจอาจเปลี่ยนขณะอยู่ในคิว จำกัดการทำงานพร้อมกันและอัตราตามเซิร์ฟเวอร์ ผู้เช่า message stream โดเมนผู้ส่ง และกลุ่มปลายทาง เพื่อไม่ให้ระบบล่มครั้งเดียวกินความจุทั้งหมด หยุดเมื่ออีเวนต์หมดอายุ ตัวตนผู้ส่งถูกเพิกถอน การร้องเรียน การยกเลิกการรับ ผู้รับล้มเหลวถาวร หรือมีการหยุดชั่วคราวจากเหตุการณ์ผิดปกติ เฝ้าติดตามอายุการลองใหม่ ผลลัพธ์ที่ไม่ทราบ ประเภทการตอบกลับ ความล้มเหลวของโทเค็น และความหน่วงของผู้ให้บริการ หาก Postmark ลองใหม่ผ่าน SMTP ปลายทางหลังยอมรับอยู่แล้ว อย่าสร้างลูปของแอปพลิเคชันที่ก้าวร้าวซ้ำซ้อนทับพฤติกรรมของ transport นั้น

รักษาความปลอดภัย webhook การส่งถึงและอีเมลตีกลับ

ตั้งค่าเฉพาะประเภท webhook ของ Postmark ที่แอปพลิเคชันต้องการ และใช้ HTTPS ใช้การควบคุมความปลอดภัยของ webhook ตามเอกสารปัจจุบัน จำกัด endpoint ให้ตรงกับเซิร์ฟเวอร์หรือสตรีมที่คาดไว้ บังคับขอบเขตขนาดคำขอและ content-type และอย่าเชื่อตัวระบุข้อความ ผู้รับ แท็ก เมทาดาทา หรือข้อมูลวินิจฉัย เพียงเพราะ JSON แยกวิเคราะห์ได้ บันทึกหรือใส่คิวอีเวนต์ที่ผ่านการยืนยันตัวตนหรือได้รับการรับเข้าอย่างปลอดภัยก่อนตอบสถานะสำเร็จ ตัดข้อมูลซ้ำด้วยตัวระบุอีเวนต์ของผู้ให้บริการที่คงที่เมื่อมี หรือค่าผสมที่ระมัดระวังซึ่งไม่รวมผู้รับ ประเภทอีเวนต์ หรือความพยายามเข้าด้วยกัน เก็บเวลาที่เกิดและเวลาที่ประมวลผลแยกกัน คาดว่าจะมีความล่าช้า การลองใหม่ การซ้ำ และการมาถึงไม่เรียงลำดับ เชื่อมโยง MessageID และเมทาดาทาที่เชื่อถือได้กับผู้เช่าและงานภายในก่อนเปลี่ยนสถานะ หมุนเวียนข้อมูลรับรองหรือ URL ของ webhook แยกจากโทเค็น API เฝ้าติดตามคำขอที่ไม่ได้รับอนุญาตและความล่าช้า และเก็บ payload ดิบเท่าที่ความต้องการด้านการปฏิบัติงานและนโยบายสมเหตุสมผล

จำลองสถานะการส่งถึง อีเมลตีกลับ และการระงับการส่ง

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

ทดสอบ sandbox ระบบจริง และเส้นทางความล้มเหลว

ใช้ฟีเจอร์ทดสอบหรือ sandbox ตามเอกสารของ Postmark และผู้รับที่ควบคุมได้โดยเฉพาะ ไม่ใช่ที่อยู่ลูกค้าจริง เพื่อทดสอบความล้มเหลวที่กำหนดได้แน่นอน ทดสอบโทเค็นที่ถูกต้องและไม่ถูกต้อง ตัวตน From ที่ไม่ได้รับอนุญาต ผู้รับที่อนุมัติและที่ถูกบล็อก ข้อความและ HTML Unicode ไฟล์แนบ การลดเมทาดาทา message stream การหมดเวลาของคำขอก่อนและหลังการยอมรับ การตอบกลับ rate การยืนยันตัวตน webhook การส่งซ้ำ อีเวนต์ที่ไม่เรียงลำดับ การจัดประเภทอีเมลตีกลับ การระงับการส่ง และการหมุนเวียนโทเค็น ตรวจสอบเฮดเดอร์ดิบที่ได้รับ DKIM และ DMARC alignment Reply-To การตั้งค่าการติดตาม และการเชื่อมโยง MessageID ยืนยันว่าสภาพแวดล้อมระดับล่างส่งถึงผู้รับในระบบจริงไม่ได้ ทดสอบการส่งออกและการย้ายระบบสำหรับการระงับการส่งและหลักฐานการปฏิบัติงาน ให้การเปิดตัวล้มเหลวเมื่อมีการเข้าถึงผู้ส่งหรืออีเวนต์ข้ามผู้เช่า บังคับใช้การระงับการส่งไม่ได้ การรับ webhook ที่กำกวม ความลับในบันทึก การลองใหม่ที่ไร้ขอบเขต หรือไม่สามารถหยุดเซิร์ฟเวอร์หรือสตรีมที่ได้รับผลกระทบได้อย่างปลอดภัย

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

SendHQ คือ Email API ระดับเวิร์กสเปซสำหรับการสื่อสารผลิตภัณฑ์ที่คาดหวัง เอกสารสาธารณะครอบคลุมการส่งจากโดเมนที่ยืนยันแล้ว อีเมลขาเข้า เทมเพลตแบบโฮสต์ อีเวนต์การส่ง การระงับการส่ง และแดชบอร์ดเว็บ

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

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

• Postmark Email API — Postmark
• ภาพรวม Postmark API — Postmark
• ภาพรวม Postmark Webhooks — Postmark
• Postmark Bounce webhook — Postmark
• ข้อกำหนด RFC 5321: Simple Mail Transfer Protocol — RFC Editor