คดีลึกลับของจุดที่หายไป

ปริศนาของจุดที่หายไปจากเนื้อหาอีเมล

โปรโตคอลการส่งเมลง่าย ๆ ที่ไม่ง่ายอย่างที่คิด

• Tjaart
  • 20 กุมภาพันธ์ 2024

---

เกิดปัญหาขึ้น

• ได้รับคำอธิบายว่าจุดในเนื้อหาอีเมลที่ส่งให้ลูกค้ารายหนึ่งหายไป
• แต่เมื่อส่งอีเมลฉบับเดียวกันให้ลูกค้ารายอื่น จุดกลับไม่หายไป

ย้อนมองโปรเจกต์

• เมื่อราว 7 ปีก่อน ได้พัฒนาโซลูชันสำหรับรวมเทมเพลตเอกสารให้เป็นระบบเดียว
• ลูกค้าใช้เทมเพลต Microsoft Word เพื่อใส่ placeholder ลงในเอกสาร
• ทุกครั้งที่พนักงานส่งเอกสารทางอีเมล จำเป็นต้องแทนที่ placeholder ด้วยเนื้อหาจริง

ปัญหาการจัดการเทมเพลต

• มีเทมเพลตหลายเวอร์ชัน ทำให้จัดการได้ยาก
• เทมเพลตบางส่วนยังใช้เงื่อนไขเก่า โลโก้เก่า ฟอนต์เก่า เป็นต้น
• จึงพัฒนาโซลูชันที่สามารถจัดการเทมเพลตทั้งหมดจากส่วนกลางได้

การนำโซลูชันไปใช้

• ลูกค้าสามารถจัดการเทมเพลตจากส่วนกลางเพื่อสร้างเอกสาร PDF ข้อความ SMS และเนื้อหาอีเมลได้
• ตัวอย่างเช่น สามารถตั้งค่าเทมเพลตจดหมายต้อนรับที่จะส่งให้ลูกค้าใหม่ได้
• และสามารถกำหนดเทมเพลตต่างกันตามแต่ละช่องทางการส่งมอบ เช่น อีเมล ข้อความ SMS หรือไปรษณีย์

การจำลองปัญหา

• พบปัญหาที่จุดหายไปเฉพาะในอีเมลที่ส่งให้ลูกค้ารายหนึ่งเท่านั้น
• ในซอร์สโค้ดของเทมเพลตมีจุดอยู่ตามปกติ
• เมื่อลองพรีวิวเนื้อหาอีเมลในสภาพแวดล้อมโลคัลก็ยังเห็นจุดตามปกติ

การวิเคราะห์สาเหตุของปัญหา

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

วิธีแก้ไข

• แก้โค้ดให้เมื่อบรรทัดเริ่มต้นด้วยจุด ระบบจะเพิ่มจุดอีกหนึ่งตัว เพื่อให้ต่อให้เซิร์ฟเวอร์ลบไปก็ยังเหลือจุดอยู่
• หลังทดสอบโค้ดที่แก้ไขแล้ว ยืนยันได้ว่าจุดไม่หายอีกต่อไป
• แก้ปัญหาเสร็จและแจ้งบั๊กนี้ให้ทีมอื่นทราบด้วย

ปัญหาที่ตามมา

• ไม่กี่เดือนต่อมา ทีมอื่นไม่ได้แก้บั๊กเดียวกันนี้ ทำให้จุดหายไปจากอีเมลสำคัญ
• ลูกค้าบางรายได้รับอีเมลที่แสดงค่าบริการรายเดือนใหม่เป็น $2700 แทนที่จะเป็น $27.00
• จากนั้นจึงแพตช์โค้ดทันทีและแก้ปัญหาได้

---

ความเห็นของ GN⁺

1. ความสำคัญของการเข้าใจสเปก SMTP: การเข้าใจสเปก SMTP อย่างลึกซึ้งเป็นสิ่งสำคัญในการแก้ปัญหาที่อาจเกิดขึ้นระหว่างการส่งอีเมล
2. ความซับซ้อนของการจัดการเทมเพลต: การดูแลเทมเพลตหลายเวอร์ชันอาจซับซ้อน และจำเป็นต้องมีระบบจัดการจากส่วนกลาง
3. ทักษะการดีบัก: ทักษะในการจำลองปัญหาและวิเคราะห์สาเหตุเป็นสิ่งสำคัญ
4. การสื่อสารระหว่างทีม: หลังแก้ปัญหาแล้ว การแชร์ข้อมูลกับทีมอื่นเป็นเรื่องสำคัญ
5. การทดสอบอัตโนมัติ: ควรนำการทดสอบอัตโนมัติมาใช้เพื่อป้องกันปัญหาลักษณะนี้

[surfindia]

เหมือนว่าในชื่อเรื่องจะตีความ period เป็น "ช่วงเวลา" แทนที่จะเป็น "จุด" นะครับ 555

[GN⁺]

ความเห็นจาก Hacker News

สรุปรวมความคิดเห็นจาก Hacker News

• ความยากของการพัฒนาไคลเอนต์ SMTP

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

• เรื่องเล่าของจดหมายรับรองในเยอรมนี

  • ในเยอรมนี การได้รับจดหมายรับรองเมื่อสิ้นสุดการจ้างงานเป็นเรื่องปกติ หากประโยคสุดท้ายของจดหมายรับรองไม่มีเครื่องหมายมหัพภาค ก็จะสื่อความหมายเชิงลบ
  • ตอนให้ทนายตรวจจดหมายรับรอง พบว่ามีปัญหาเพราะประโยคสุดท้ายไม่มีเครื่องหมายมหัพภาค

• Cron job และไคลเอนต์ SMTP

  • Cron job ที่ส่งอีเมลไม่จำเป็นต้องพัฒนาไคลเอนต์ SMTP ขึ้นมาเอง สามารถใช้โปรแกรมอย่าง mailutils ได้
  • การพัฒนาอินเทอร์แอ็กชัน SMTP พื้นฐานผ่านซ็อกเก็ตโดยตรงไม่มีประสิทธิภาพ เพราะต้องมีการเชื่อมต่อ TLS และการยืนยันตัวตน
  • Cron มีความสามารถในการส่งอีเมลอยู่แล้ว สามารถตั้งค่าอีเมลด้วยตัวแปร MAILTO ได้

• นิสัยแย่สองอย่าง

  • ไม่ควรพัฒนามาตรฐานแบบขอไปที ควรใส่ใจอย่างเพียงพอหรือใช้ไลบรารีที่มีอยู่แล้ว
  • ไม่ควร vendor dependency ไลบรารีควรถูกอัปเดตเป็นประจำ หากเลื่อนการอัปเดตออกไปอาจเกิดปัญหาใหญ่ได้

• ความจำเป็นของ dot stuffing

  • SMTP และ POP3 จำเป็นต้องใช้ dot stuffing สามารถอ้างอิงเอกสาร RFC ที่เกี่ยวข้องได้

• ปัญหาไฟล์แนบ HTML MIME

  • ประโยค "We are happy to welcome you to our family." ไม่ชนข้อจำกัดความยาวบรรทัด จึงอาจเป็นไฟล์แนบ HTML MIME
  • หากตัด HTML เป็นบรรทัดแบบสุ่ม อาจทำให้แท็กเสียหายได้

• กรณีที่อักขระตัวแรกเป็นจุด

  • หากอักขระตัวแรกเป็นจุดและยังมีอักขระอื่นตามมา อักขระตัวแรกจะถูกลบ เพราะจุดเดี่ยวหมายถึงจุดสิ้นสุดของเมล
  • เป็นเรื่องยากที่จะเข้าใจว่าทำไมต้องลบจุด ทั้งที่สามารถเก็บหนึ่งไบต์ไว้เพื่อตรวจสอบอักขระถัดไปได้

• การแจ้งเตือนแพตช์บั๊ก

  • โค้ดไคลเอนต์ SMTP ถูกนำมาจากโปรเจกต์ก่อนหน้า จึงได้แจ้งบั๊กนี้ให้ทีมอื่นทราบ
  • เป็นไปได้ว่าทีมอื่นยังไม่ได้แพตช์บั๊กนี้

• ประสบการณ์การพัฒนาเซิร์ฟเวอร์ NNTP

  • ระหว่างพัฒนาเซิร์ฟเวอร์ NNTP โดยอิงตามสเปก RFC ก็เข้าใจปัญหา dot stuffing ได้ทันที เป็นโปรโตคอลจากยุค 80