本篇文章更新時間：2026/02/13
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知或向一介資男的 LINE 社群反應。
如果本站內容對你有幫助，歡迎贊助支持 。
內容目錄
當一封「驗證信寄不進 Gmail」暴露了歐洲金流基礎建設的深層問題
編輯前言：這篇文章源自作者在 Viva.com（歐洲大型金流處理商）註冊時遇到的怪事。原文來自Major European Payment Processor Can't Send Email to Google Workspace Users。表面上只是驗證信收不到，但背後卻是歐洲金融科技基礎設施品質落差的縮影。
核心觀點 (Key Takeaways)
- Viva.com 的驗證信缺少 Message-ID，這是 RFC 5322 從 2008 年就要求的基本欄位，Google Workspace 會直接拒收。
- 支援團隊完全忽略技術細節，只因為使用者改成 Gmail 之後成功，就當作問題不存在。
- 這類問題揭露歐洲 B2B API 與金流服務普遍「有點壞掉」的現象：技術細節不夠嚴謹、競爭壓力不足、缺乏 Stripe 式的產品品味。
深入解析
作者原本只想註冊 Viva.com 帳號，一切都應該是五分鐘的流程，直到驗證信始終沒來。Google Workspace 的 Email Log 給出了明確答案：
550 5.7.1 Messages missing a valid Message-ID header are not accepted.
換句話說，Viva 發出的驗證信 連最基本的 Message-ID 都沒有。這在 2026 年幾乎不可思議。大多數框架、郵件函式庫都會自動生成這個欄位，要刻意不放反而比較難。
作者後來改用個人 Gmail，才收到驗證信。這也代表 Gmail 在不同路徑上對 Message-ID 的要求比較寬鬆。但作為使用者，為了建立一個「商用金流帳號」卻不得不用私人信箱，怎麼看都不合理。
更令人無言的是支援團隊的回覆：
"your account now has a verified email address, so there doesn't appear to be an issue."
完全略過技術錯誤本身，甚至沒有意識到這是「工程應該立即處理」的重大問題。
歐洲金流與 API 的老問題
作者把這件小插曲延伸到一個更大的觀察：歐洲很多企業級 API、金流、政府單位介接，都存在一種「功能能用，但細節很糟」的狀態。
- 文件殘缺、甚至只給 PDF
- 邊界情況處理不完善
- 錯誤訊息模糊
- 支援團隊難以理解技術回報
作者認為問題不是工程師不夠厲害，而是 市場壟斷或缺乏競爭導致優先度低。例如 Viva 是在希臘少數支援本地 IRIS 付款系統的業者，而 Stripe 尚未進場，所以使用者根本沒有選擇。
作者一句話點破核心：
I miss Stripe. I miss the feeling of integrating with an API that someone clearly cared about.
RFC 的 SHOULD、Google 的 MUST
原文最後也補充了討論串中的一個觀點：
- Message-ID 在 RFC 中屬 SHOULD，不是 MUST。
- 但 Google 與 Microsoft 等大型郵件提供者實際上把它視為硬性要求，因為 缺少 Message-ID 的信件通常是垃圾信。
所以真正的問題是：
Viva.com 即便「可以」不放 Message-ID，也應該充分理解後果，或至少公開提醒使用者。「沉默」不是合格的 SHOULD 實作。
筆者心得與啟發
這篇故事讓我重新意識到一件事：基礎設施的細節比想像中更重要，也更容易暴露一間公司的工程文化。
Message-ID 只是 email 的基本欄位。若一家大型金流業者連這種小細節都能漏掉，再加上支援團隊的輕描淡寫，我會自然懷疑：
- 他們的 API 穩不穩？
- 付款流程是否會有奇怪邊界情況？
- 系統的合規性與安全性是否真的到位？
這也是為什麼 Stripe 的成功如此關鍵：它不只是收款工具，而是把「開發者體驗」當成產品價值的一部分。而當市場缺乏這種競爭者時，整個生態的品質自然下降。
對工程團隊而言，作者給了最務實的建議：
保留 Message-ID，只要一行程式碼就能解決。
我會補一句：當使用者花時間告訴你問題在哪裡，那是免費的工程諮詢，絕對值得重視。