- 欧州の大手決済企業 Viva.com が
Message-ID ヘッダーなしで認証メールを送信し、Google Workspace サーバーがこれを拒否
- RFC 5322（2008年制定）では
Message-ID は必須級のヘッダーとして規定されており、Google はこれを厳格に適用
- Gmail の個人アドレスではメールを受信でき、Google Workspace と Gmail の処理の違い が明らかに
- Viva.com のカスタマーサポートは技術的問題を認めず、ユーザーが回避した結果だけを確認する 非専門的な対応 を見せた
- 基本的な RFC 準拠すら守れなかった事例として、欧州フィンテック基盤の品質と競争力低下の問題 を浮き彫りにした
認証メールが届かなかった問題
- Viva.com のアカウント作成過程で認証メールがまったく届かなかった
- Google Workspace ベースのカスタムドメインメールを使用しており、迷惑メールフォルダにもメールはなかった
- Google Workspace の Email Log Search の結果、状態は「Bounced」と表示された
- 返送理由は「Messages missing a valid Message-ID header are not accepted」
- Google は RFC 5322 規格違反としてメールを拒否した
- Viva.com の送信メールには
Message-ID ヘッダーが欠落しており、これは2008年から必須とされている項目
一時的な解決策
- 個人用の @gmail.com アドレスに変更すると、認証メールは正常に受信できた
- Gmail の受信基盤の方が寛容か、別経路で処理されたとみられる
- しかし、業務用の決済プラットフォーム 登録に個人メールを使わなければならなかった点は問題として指摘される
カスタマーサポートの対応
- Viva.com のカスタマーサポートに Google Workspace のログのスクリーンショットと問題の説明を送付した
- サポートチームは「お客様のアカウントはすでに認証済みのメールを持っているため問題ない」と返信した
- 技術的問題への認識やエンジニアリングチームへの共有はなかった
- ユーザーが自力で回避した結果を問題なしとみなす対応だった
問題の本質
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>
- ほとんどのメールライブラリはこれを自動生成し、1行の修正で解決可能
- Google Workspace ユーザーが正常に認証メールを受け取れるよう、即時の修正が必要
RFC 用語の区別と Google の方針
- RFC 2119 によれば
- MUST: 絶対的要件
- SHOULD: 特別な理由があるときにのみ省略可能
- MAY: 完全に任意
Message-ID が SHOULD である理由は、一部のクライアントがサーバーに委任するため- Google はスパム防止のため、これを 強制的な要件として適用 し、RFC よりも実質的な標準として機能している
- Viva.com がこれを意図的に省略していたなら、少なくとも「Google Workspace と互換性がない」という警告を提供すべき
- 何の案内もなく運用するのは SHOULD 規定の趣旨にも反する
1件のコメント
Hacker Newsのコメント
問題は、Viva.comの認証メールに Message-ID ヘッダー がない点だと指摘されている
RFC 5322のセクション 3.6には「every message SHOULD have a Message-ID field」とあるが、SHOULDはMUSTではないので、「要件」と見るのは難しいのではないかという疑問が出ている
特別な理由がない限り従うべきで、単に「面倒だから」は例外にならないとしている
以前は、MUAがMessage-IDなしでメールを送ってもサーバーが自動で追加していたため、SHOULDという表現になったという
関連内容は RFC 6409 セクション 8.3 に明記されている
Googleがこれをどう解釈したのかは分からないとしている
テストメールならともかく、本番サービスのメールにないとスパムフィルタリングなどで問題が起きる
Message-IDがないのは通常、杜撰なカスタム送信システム の兆候だとしている
特に決済サービスがGoogle Workspaceのような主要メールサービスでテストすらしていないのはひどいという
ESP（Email Service Provider）で働いていた経験から、ほとんどのサーバーソフトウェアはMessage-IDのないメールを拒否していたという
Googleのような主要受信者からの バウンス を無視するのは想像しがたいとも述べている
相手のシステムが不合理でも、ユーザーの不便を防ぐために合わせる方がよいという
それを入れたくないなら、「Google Workspaceユーザーにはサービス提供不可」と明記すべきだと主張している
VivaもGoogleも大きすぎて、一部顧客の問題は気にしていないのだろうと見ている
メールの text/plain の代替パート をひどい状態で送るサービスへの不満も出ている
リンクが欠けたテキスト版や、「これはプレーンテキストメールです」といった無意味な内容しか送らない場合があるという
メールクライアントがAIでHTMLを要約してくれる機能が必要だ、という冗談も出ている
金融機関の 技術的無能さ を皮肉るコメントもあった
「Major European Payment Processor」は、実質的には「Major European Incompetence Center」だという表現まで出ている
例えばHarland Financial Systemsは 2バイトのXOR暗号化 を使い、しかも鍵を接続の冒頭で平文送信していたという
GmailからFastmailへ移ったユーザーは、Googleの 厳格なスパムフィルタリング にある程度共感している
Fastmailではスパムやフィッシングメールがより多く届くという
スタートアップが基本テンプレートをそのまま使っていて、フィッシングと誤認されることもあるという
RFC上はViva.comが間違っているが、Googleも SHOULD項目を理由にメールを拒否するのは不適切 だと見る意見もある
ただしスパムの可能性が高いならスパムフォルダに送るべきで、拒否までするのはやりすぎだとしている
Viva.comがGoogle Workspaceとのメール送信問題を テストすらしていなかった点 が最も深刻だと指摘されている
問題はGoogle側の変更かもしれないが、モニタリング不足 の方がより大きな問題だという
Viva.comがこの問題を どれだけ長く認識していなかったのか という疑問も出ている
一般的なメールソフトウェアならこんな問題は起きなかったはずだとして、misconfigurationの可能性に言及している
SHOULDはMAYではなく、実装しなければ問題を受け入れるしかないという
Googleがエラーメッセージで原因を知らせてくれたのは、むしろ幸運だったと評価している
Message-IDはもともと Usenetに由来する必須フィールド で、
メールの スレッド化、返信、アーカイブ のすべてに必要だと説明している
Message-IDがないのは「返信も望まず、記録も残したくない」という意味で、怪しい振る舞い に見えるという
欧州企業APIの品質問題を指摘した元記事に対し、
こうした現象は地域の問題ではなく、世界中のスタートアップや金融機関に共通するパターン だという
大企業はAPIを付随事業と見なしたり、規制対応のためにしぶしぶ運用 している場合が多いという
一方でStripeのような会社はAPIが生命線なので品質が高いとしている
スタートアップはリソース不足のため、「使いやすいAPI」より「動くAPI」 を優先せざるを得ないとも付け加えている