ผู้ให้บริการประมวลผลการชำระเงินรายใหญ่ในยุโรปส่งอีเมลถึงผู้ใช้ Google Workspace ไม่ได้

 (atha.io)
1 คะแนน โดย GN⁺ 2026-02-13 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ผู้ให้บริการชำระเงินรายใหญ่ของยุโรป Viva.com ส่งอีเมลยืนยันตัวตนโดยไม่มีเฮดเดอร์ Message-ID ทำให้ เซิร์ฟเวอร์ Google Workspace ปฏิเสธอีเมลดังกล่าว
  • RFC 5322 (ประกาศใช้ในปี 2008) กำหนดให้ Message-ID เป็นเฮดเดอร์ระดับที่ควรมีอย่างยิ่ง และ Google บังคับใช้อย่างเข้มงวด
  • อีเมลสามารถส่งถึงที่อยู่ Gmail ส่วนบุคคลได้ จึงเผยให้เห็นถึง ความแตกต่างในการประมวลผลระหว่าง Google Workspace กับ Gmail
  • ฝ่ายสนับสนุนลูกค้าของ Viva.com ไม่ยอมรับว่ามีปัญหาทางเทคนิค และเพียงยืนยันผลลัพธ์ที่ผู้ใช้หาทางอ้อมแก้เองได้ ซึ่งเป็นการตอบสนองที่ ไม่เป็นมืออาชีพ
  • นี่เป็นกรณีที่แม้แต่การปฏิบัติตาม RFC ขั้นพื้นฐานก็ยังทำไม่ได้ และสะท้อนถึง ปัญหาด้านคุณภาพและความสามารถในการแข่งขันของโครงสร้างพื้นฐานฟินเทคยุโรป

ปัญหาอีเมลยืนยันตัวตนไม่มาถึง

  • ระหว่างขั้นตอนสร้างบัญชี Viva.com อีเมลยืนยันตัวตนไม่มาถึงเลย
    • ใช้อีเมลโดเมนกำหนดเองที่ทำงานบน Google Workspace และไม่พบอีเมลในโฟลเดอร์สแปมเช่นกัน
  • ผลจาก Email Log Search ของ Google Workspace แสดงสถานะเป็น “Bounced”
    • เหตุผลของการตีกลับคือ “Messages missing a valid Message-ID header are not accepted”
    • Google ปฏิเสธอีเมลเนื่องจากละเมิดข้อกำหนด RFC 5322
  • อีเมลที่ส่งจาก Viva.com ไม่มีเฮดเดอร์ Message-ID ซึ่งเป็นรายการที่มีการกำหนดให้ต้องมีมาตั้งแต่ปี 2008

วิธีแก้ชั่วคราว

  • เมื่อลองเปลี่ยนเป็นที่อยู่อีเมล @gmail.com ส่วนบุคคล อีเมลยืนยันตัวตนก็ได้รับตามปกติ
    • ดูเหมือนว่าโครงสร้างพื้นฐานการรับอีเมลของ Gmail จะยืดหยุ่นกว่า หรือประมวลผลผ่านเส้นทางที่ต่างออกไป
  • อย่างไรก็ตาม มีการชี้ว่าการต้องใช้อีเมลส่วนบุคคลเพื่อลงทะเบียนกับ แพลตฟอร์มการชำระเงินสำหรับธุรกิจ เป็นเรื่องที่มีปัญหา

การตอบสนองของฝ่ายสนับสนุนลูกค้า

  • มีการส่งภาพหน้าจอบันทึกล็อกของ Google Workspace พร้อมคำอธิบายปัญหาไปยังฝ่ายสนับสนุนของ Viva.com
  • ทีมสนับสนุนตอบกลับว่า “บัญชีของคุณมีอีเมลที่ผ่านการยืนยันแล้ว จึงไม่มีปัญหา”
    • ไม่มีการรับรู้ถึงปัญหาทางเทคนิคหรือการส่งต่อให้ทีมวิศวกรรม
    • เป็นการมองว่าผลลัพธ์ที่ผู้ใช้แก้ปัญหาด้วยตัวเองคือหลักฐานว่าไม่มีปัญหา

แก่นของปัญหา

  • Message-ID เป็น เฮดเดอร์พื้นฐาน ที่ระบบอีเมลทุกระบบสร้างขึ้นโดยปกติ
    • หากเฮดเดอร์นี้หายไป แสดงว่าท่อส่งอีเมลถูกตั้งค่าผิดอย่างร้ายแรง
  • แม้ RFC 5322 จะระบุ Message-ID ว่าเป็น “SHOULD” แต่ Google ปฏิบัติต่อสิ่งนี้ในทางปฏิบัติเป็น ข้อบังคับเสมือนจริง (MUST)
  • เมื่อ Viva.com ไม่ปฏิบัติตาม อีเมลจึงไปไม่ถึงผู้ใช้ Google Workspace
  • การที่บริษัทซึ่งประมวลผลการชำระเงินทั่วทั้งยุโรปไม่สามารถทำตามมาตรฐาน RFC ขั้นพื้นฐานได้ ก่อให้เกิด คำถามต่อความน่าเชื่อถือทางเทคนิค

ปัญหาเชิงโครงสร้างของโครงสร้างพื้นฐานฟินเทคยุโรป

  • ใน API และบริการสำหรับองค์กรของยุโรป มักเกิดปัญหา เอกสารไม่ครบถ้วน การจัดการข้อผิดพลาดไม่ดี และการสนับสนุนที่ไม่เป็นมืออาชีพ ซ้ำแล้วซ้ำเล่า
  • มีการชี้ว่านี่ไม่ใช่ปัญหาความสามารถของวิศวกร แต่เป็น ปัญหาจากการแข่งขันในตลาดที่ไม่เพียงพอและการจัดลำดับความสำคัญ
  • แม้ Stripe จะยกระดับมาตรฐานด้านประสบการณ์นักพัฒนาไว้สูง แต่ก็ยังไม่รองรับ เครือข่ายการชำระเงินในยุโรปบางส่วน (เช่น IRIS) อย่างครบถ้วน ทำให้มีตัวเลือกทดแทนน้อย
  • หากยังไม่มีคู่แข่งระดับเดียวกับ Stripe เกิดขึ้น ปัญหาคุณภาพลักษณะนี้ก็มีแนวโน้มจะดำเนินต่อไป

ข้อเสนอในการแก้ไขทางเทคนิค

  • Viva.com ควรเพิ่มเฮดเดอร์ Message-ID ลงในอีเมลขาออก
    • ตัวอย่าง: Message-ID: <unique-id@viva.com>
    • ไลบรารีอีเมลส่วนใหญ่สร้างสิ่งนี้ให้อัตโนมัติอยู่แล้ว และ แก้ได้ด้วยการปรับเพียงหนึ่งบรรทัด
  • จำเป็นต้องแก้ไขทันที เพื่อให้ผู้ใช้ Google Workspace ได้รับอีเมลยืนยันตัวตนตามปกติ

ความแตกต่างของคำศัพท์ใน RFC กับนโยบายของ Google

  • ตาม RFC 2119
    • MUST: ข้อกำหนดที่ต้องปฏิบัติโดยเด็ดขาด
    • SHOULD: ละเว้นได้เฉพาะเมื่อมีเหตุผลพิเศษเท่านั้น
    • MAY: เป็นทางเลือกโดยสมบูรณ์
  • เหตุผลที่ Message-ID เป็น SHOULD เพราะไคลเอนต์บางตัวมอบหมายให้เซิร์ฟเวอร์เป็นผู้สร้างให้
  • Google ใช้สิ่งนี้เป็น ข้อกำหนดบังคับ เพื่อป้องกันสแปม และทำหน้าที่เป็นมาตรฐานเชิงปฏิบัติที่เข้มกว่าตัว RFC เอง
  • หาก Viva.com ตั้งใจละเว้นสิ่งนี้ อย่างน้อยก็ควรแสดงคำเตือนว่า “ไม่รองรับ Google Workspace”
    • การให้บริการโดยไม่มีคำแนะนำใด ๆ ขัดกับเจตนารมณ์ของข้อกำหนด SHOULD เช่นกัน

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-02-13
ความคิดเห็นจาก Hacker News

  • มีการชี้ว่าปัญหาอยู่ที่อีเมลยืนยันของ Viva.com ไม่มี ส่วนหัว Message-ID
    ตาม section 3.6 ของ RFC 5322 ระบุว่า “every message SHOULD have a Message-ID field” แต่ก็มีข้อสงสัยว่าเมื่อ SHOULD ไม่ใช่ MUST จะถือเป็น ‘ข้อกำหนดบังคับ’ ได้จริงหรือไม่

    • มีคำอธิบายว่า SHOULD นั้นแทบจะเป็น ข้อกำหนดที่ต้องปฏิบัติตาม
      ต้องทำตามเว้นแต่จะมีเหตุผลพิเศษ และแค่ “ขี้เกียจ” ไม่อาจถือเป็นข้อยกเว้นได้
      ในอดีตมีการใช้คำว่า SHOULD เพราะถ้า MUA ส่งเมลโดยไม่มี Message-ID เซิร์ฟเวอร์จะเพิ่มให้โดยอัตโนมัติ
      เรื่องนี้ระบุไว้ชัดเจนใน RFC 6409 section 8.3
    • ตาม RFC2119 คำว่า SHOULD หมายถึง “สามารถละเว้นได้ในบางสถานการณ์ แต่ต้องเข้าใจผลลัพธ์อย่างถ่องแท้และพิจารณาอย่างรอบคอบ”
      และไม่แน่ชัดว่า Google ตีความเรื่องนี้อย่างไร
    • ในฐานะ postmaster ของบริษัทโฮสติ้ง มีการย้ำว่าในสภาพแวดล้อมการใช้งานจริง Message-ID จำเป็นอย่างยิ่ง
      เมลทดสอบอาจไม่เป็นไร แต่ถ้าเป็นเมลบริการจริงแล้วไม่มี จะมีปัญหาเรื่องการกรองสแปมและอื่น ๆ
      การไม่มี Message-ID มักเป็นสัญญาณของ ระบบส่งเมลแบบทำเองที่หละหลวม
    • Message-ID ไม่ได้บังคับเสมอไป แต่ก็มีคนบ่นว่าบริการอย่าง Amazon SES ชอบเขียนทับ Message-ID เดิม
    • ในทางเทคนิคอาจไม่มีได้ แต่ถ้าจะให้ถูกจัดว่าเป็น อีเมลปกติอย่างแท้จริง ก็แทบขาดไม่ได้
      โดยเฉพาะเมื่อเป็นบริการชำระเงินแต่กลับไม่ได้ทดสอบกับผู้ให้บริการเมลรายใหญ่อย่าง Google Workspace เลย ก็ดูน่าตกใจมาก

  • มีคนเล่าว่าเคยทำงานที่ ESP (Email Service Provider) และบอกว่าซอฟต์แวร์เซิร์ฟเวอร์ส่วนใหญ่ปฏิเสธเมลที่ไม่มี Message-ID
    จึงแทบนึกไม่ออกว่าจะมีใครเมิน bounce ที่มาจากผู้รับรายใหญ่อย่าง Google ได้

    • ในโลกความจริง การป้องกัน ปัญหาของผู้ใช้สำคัญกว่ามาตรฐาน
      ต่อให้อีกฝั่งจะไร้เหตุผล การยอมปรับตามเพื่อไม่ให้ผู้ใช้เดือดร้อนก็ยังดีกว่า
    • ถ้าจะส่งเมลไปยัง Google Workspace แล้ว Message-ID นั้นแทบจะเป็น MUST
      ถ้าไม่อยากใส่ ก็ควรระบุไปตรง ๆ ว่า “ไม่รองรับผู้ใช้ Google Workspace”
    • แต่บริษัทส่วนใหญ่ไม่ได้สนใจรายละเอียดทางเทคนิคแบบนี้ และมีท่าทีว่า “ขอให้เปิดบริการได้ไวก็พอ”
      ทั้ง Viva และ Google ต่างก็ใหญ่เกินกว่าจะใส่ใจปัญหาของลูกค้าบางส่วน
    • มีคนตั้งข้อสังเกตด้วยว่าเพราะบริษัทเหล่านี้เน้นตลาดยุโรป สัดส่วนผู้ใช้ Google Workspace อาจไม่ได้มากนัก

  • ยังมีการบ่นเรื่องบริการที่ส่ง พาร์ตทางเลือก text/plain ของอีเมลมาแบบเละเทะ
    เช่น ส่งเวอร์ชันข้อความที่ไม่มีลิงก์ หรือมีแต่ข้อความไร้ประโยชน์อย่าง “นี่คืออีเมลแบบ plain text”

    • มีคนบอกว่าสิ่งที่น่าหงุดหงิดที่สุดคือเวอร์ชัน plain text ที่มีแต่ “คำพูดน่ารัก ๆ” โผล่ในหน้าการแจ้งเตือน
      พร้อมแซวว่าควรมีฟีเจอร์ให้ไคลเอนต์อีเมลใช้ AI สรุป HTML
    • มีคนเล่าว่าบางบริการเคยใส่ข้อมูลการจองของลูกค้าคนอื่นลงใน plain text ด้วย (กรณีของ Avis)
    • มีคนเคยเห็นการทำ text/plain โดย dump HTML ผ่านเบราว์เซอร์ Lynx และสงสัยว่านั่นมีคุณค่าใช้งานจริงแค่ไหน
    • บางกรณีก็เห็นการยัดซอร์ส HTML หรือ CSS ลงไปตรง ๆ ใน text/plain ด้วย

  • มีคอมเมนต์เหน็บแนม ความไร้ความสามารถทางเทคนิค ของสถาบันการเงินด้วย
    โดยบอกว่า “Major European Payment Processor” แท้จริงแล้วคือ “Major European Incompetence Center”

    • ผู้ใช้อีกคนบอกว่าแม้จะฟังดูพูดเกินจริง แต่ในความเป็นจริงระดับความปลอดภัยของสถาบันการเงินนั้นเลวร้ายมาก
      เช่น Harland Financial Systems ใช้การเข้ารหัสแบบ 2-byte XOR และส่งกุญแจมาเป็นข้อความล้วนตั้งแต่ช่วงต้นของการเชื่อมต่อ
    • อีกคนหนึ่งยกตัวอย่าง กรณีทุจริตของสถาบันการเงินในสหรัฐฯ เช่น การอนุมัติผิดพลาดหรือการเปิดบัญชีโดยไม่ได้รับอนุญาต แล้วถามว่ายุโรปก็คล้ายกันหรือไม่

  • ผู้ใช้ที่ย้ายจาก Gmail ไป Fastmail บอกว่าพอจะเข้าใจเรื่อง การกรองสแปมที่เข้มงวด ของ Google อยู่บ้าง
    เพราะใน Fastmail มีทั้งสแปมและฟิชชิงหลุดเข้ามามากกว่า

    • อีกคนมองว่า Message-ID เป็น มาตรฐานโดยพฤตินัยของอุตสาหกรรม สำหรับเมลอัตโนมัติ จึงไม่คิดว่าการจัดการของ Google จะเกินเลย
      และยังมีกรณีที่สตาร์ตอัปใช้เทมเพลตพื้นฐานเดิม ๆ จนถูกเข้าใจผิดว่าเป็นฟิชชิงด้วย
    • มีคำแนะนำว่าเมื่อใช้ไปสักพัก ตัวกรองสแปมของ Fastmail จะเรียนรู้และดีขึ้นเอง
    • ผู้ใช้ Fastmail มานานคนหนึ่งพูดติดตลกว่า บางครั้งมีสแปมหลุดมาบ้าง แต่ มีแค่อีเมล LinkedIn เท่านั้นที่ทะลุผ่านมาได้เสมอ
    • อีกความเห็นบอกว่า Fastmail มีช่วงที่ตอบสนองต่อสแปมได้ช้าลงเป็นพัก ๆ แต่โดยรวมก็ยังพอใจ

  • บางคนมองว่าตาม RFC นั้น Viva.com ผิดจริง แต่ Google เองก็ ไม่ควรปฏิเสธอีเมลเพียงเพราะเป็นข้อ SHOULD
    หากสงสัยว่าเป็นสแปม ก็ควรส่งลงโฟลเดอร์สแปมมากกว่าจะปฏิเสธไปเลย

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

  • มีการชี้ว่าประเด็นที่ร้ายแรงที่สุดคือ Viva.com ไม่ได้ทดสอบเลยด้วยซ้ำ ว่าการส่งเมลทำงานกับ Google Workspace หรือไม่

    • มีคนประชดว่าจริง ๆ แล้วพวกเขากำลัง “ทดสอบแบบเรียลไทม์” ผ่านการที่ผู้ใช้สมัครไม่สำเร็จ
      และเสริมว่าต่อให้เป็นความเปลี่ยนแปลงฝั่ง Google แต่ การไม่มีระบบมอนิเตอร์ ก็เป็นปัญหาที่ใหญ่กว่า
    • ก็มีเสียงโต้แย้งว่า “ไม่ใช่ทุกบริษัทในโลกจะใช้ Google Workspace เสียหน่อย”

  • มีคนตั้งคำถามว่า Viva.com ไม่รู้ตัวมาได้นานแค่ไหนแล้ว ว่ามีปัญหาแบบนี้
    พร้อมบอกว่าถ้าใช้ซอฟต์แวร์เมลทั่วไป ปัญหาเช่นนี้ก็คงไม่เกิดขึ้น และอาจเป็นความผิดพลาดในการตั้งค่า
    SHOULD ไม่ใช่ MAY และถ้าไม่ทำตามก็ต้องยอมรับความเสี่ยงของปัญหาที่ตามมา
    อย่างน้อย Google ก็ยังดีที่ส่งข้อความผิดพลาดกลับมาบอกสาเหตุ

  • มีคำอธิบายว่าเดิมที Message-ID เป็น ฟิลด์บังคับที่มาจาก Usenet
    และจำเป็นต่อทั้ง การทำเธรด การตอบกลับ และการจัดเก็บถาวร ของอีเมล
    การไม่มี Message-ID ทำให้ดูเหมือน “ไม่ต้องการให้ตอบกลับ และไม่ต้องการให้มีบันทึกหลงเหลือ” ซึ่งจึงดูเป็น พฤติกรรมน่าสงสัย

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