雑記帳

整理しない情報集

更新情報

Gmailは仕様に準拠しないメールの転送を拒否する模様

公開日:

カテゴリ: Webサービス

Google WorkspaceのGmail宛のメールが一部届かなくなったので調べてみたお話。

ご注意

本記事での転送はメールクライアントの転送機能(件名にFw:やFwd:をつけて送り直すもの)ではなく、メールの配信ルート上でエンベロープ受信者を変更して別のアドレスに配信することを指します。

発端

先日あるサービスにログインする際に、確認コードのメールがボックスに届きませんでした。迷惑メールに入ったのかと思ってそちらも確認しましたが、特に紛れ込んでいるわけでもないようでした。ならば遅延しているのかと思って少し待ってみましたが、一向に届く気配がありません。

今年の前半期は普通に受信できていたので、DKIMで拒否されたとは考えにくい(GmailでDKIMが必須化されたのは昨年だったはず)ですが、一応念の為Google Workspaceのメールログ検索(ELS)で確認してみます。

メールのログを調べてみる

ELSで直近のログを確認してみたところ、該当の確認コードのメールがログにいました。中を開いてみると見慣れないログが残っていました。IPアドレスやユニークIDっぽいものは一応*で伏せています。

2025/XX/XX XX:XX:XX SMTP クライアント（IP アドレス: *.*.*.*）から受信（TLS 適用）

2025/XX/XX XX:XX:XX 返送

DKIMが通過できずに廃棄されたメールは「拒否」と出てきますが、該当の確認コードのメールは「返送」となっています。不思議に思ったので、さらにメッセージの詳細を確認してみます。

Google tried to deliver your message, but it was rejected by the server for the recipient domain gmail.com by gmail-smtp-in.l.google.com. [****].

The error that the other server returned was:

550-5.7.1 [****] Messages missing a valid Message-ID header are not

550-5.7.1 accepted. For more information, go to

550-5.7.1 https://support.google.com/mail/?p=RfcMessageNonCompliant and review

550 5.7.1 RFC 5322 specifications. *************-***********************.*** - gsmtp

どうやらMessage-IDがRFC5322に準拠していないので転送先のサーバから拒否されたようです。Message-IDといえば、メールクライアントがメールヘッダに自動で付加するランダムな文字列のあれですよね。少し上のメッセージ概要にこのメールのメッセージIDが載っていたような気がします。

<********.********.******.****[email protected]>

おや、ランダムな文字列だけでなく意味のあるSMTPIN_ADDED_BROKENという文字列が。そして確かメッセージIDにドメインが入る場合は大抵送信サーバのドメインが後ろに付いていた気がしますが、どう見ても受信側のドメインが付いています。

ELSでは件名・送信者・受信者・日時・メッセージID・メッセージサイズ・添付ファイルの数は記録されていますが、その他のメールヘッダや本文等は保存されないため、ログデータからはこれ以上の情報を得ることは難しそうです。

仕様を見てみる

上記のメッセージにあったRFC 5322の内容を見てみます。3.6.4. Identification FieldsにMessage-IDについて載っていました。

Though listed as optional in the table in section 3.6, every message SHOULD have a "Message-ID:" field. Furthermore, reply messages SHOULD have "In-Reply-To:" and "References:" fields as appropriate and as described below.

MUSTではないようですので、Message-IDは一応オプション扱いのようです。ただしSHOULDなので余程のことがない限りは遵守すべき項目のようです。

さらに読み進めていくとMessage-IDが遵守すべき内容のうち、今回のメールで当てはまる可能性があるのは以下の3パターンのいずれかとみられます。

  • Message-IDが存在しない
  • Message-IDが複数回宣言されている
  • Message-IDのフォーマットが異なる
    • Message-IDが<left@right>の形式でない
      • Message-IDの値の前後には山括弧<>が必要
    • Message-IDに使用できない文字が使用されてる

使用できない文字はそのセクションを読んだだけでは理解できませんが、RFCには見やすくBNF記法でも仕様が書かれているので、折角なのでついでに読んでみます。

message-id      =   "Message-ID:" msg-id CRLF
msg-id          =   [CFWS] "<" id-left "@" id-right ">" [CFWS]
id-left         =   dot-atom-text / obs-id-left
id-right        =   dot-atom-text / no-fold-literal / obs-id-right
no-fold-literal =   "[" *dtext "]"

dot-atom-text   =   1*atext *("." 1*atext)
atext           =   ALPHA / DIGIT /    ; Printable US-ASCII
                    "!" / "#" /        ;  characters not including
                    "$" / "%" /        ;  specials.  Used for atoms.
                    "&" / "'" /
                    "*" / "+" /
                    "-" / "/" /
                    "=" / "?" /
                    "^" / "_" /
                    "`" / "{" /
                    "|" / "}" /
                    "~"
dtext           =   %d33-90 /          ; Printable US-ASCII
                    %d94-126 /         ;  characters not including
                    obs-dtext          ;  "[", "]", or "\"

ALPHA           =   %x41-5A / %x61-7A  ; A-Z / a-z
DIGIT           =   %x30-39            ; 0-9

obs-は廃止(Obsolete)したものであるため、ここでは考えないことにします。ALPHAとDIGITはRFC 5234参照となっていたので、RFC 5234から定義を持ってきました。

atextは英数字+一部の記号が1文字以上、dtextは角括弧[]内に英数字+[]\を除く全記号0文字以上のようです。Message-IDは山括弧<>で囲われた中に@区切りで左側はatext、右側はatextもしくはdtextが許容されているといった感じの形式のようですね。

過去に届いたメールを見てみる

結局のところ実際のメールが残っていない以上この先の調査は困難なのですが、そういえばこれまでは正常にメールを受信できていたので、過去に届いていたメールから何か手がかりがないか調べてみます。

確認コードの類のメールは邪魔なので溜めずにどんどん削除してしまっていて残っていないのですが、辛うじて過去に受信したメールが1件だけ削除し損ねて残っていました。Gmailの3点メニューから「原文を表示」でメールのソースを表示してみます。

Message-ID

まずはMessage-IDを探してみます。メールヘッダは上にどんどん追記されていく関係で、Message-IDはそれなりにスクロールした先にあります。面倒なのでCtrl+FでMessage-IDを検索して一発で飛びます。

Message-ID: <********.********.******.****[email protected]>

メールヘッダからMessage-IDを探したところ、ELSで見たメッセージIDと同じフォーマットのものがセットされていました。どうやらGmail側のメールサーバの仕様変更で拒否されるようになった可能性が高そうです。

X-Google-Original-Message-ID

Ctrl+FでMessage-IDを検索したところ上のMessage-IDのすぐ下の行にこんな行がありました。

X-Google-Original-Message-ID: PRODUCTION:********

X-Google-Original-Message-IDという見慣れないヘッダ項目がありました。HTTPのヘッダ名で、X-とOriginalが入っているものは、大抵ヘッダの書き換えを行った際に、元のヘッダ情報を残すために使う風習があるイメージです。

軽くネット検索してみた限りでは、どうやらビンゴのようです。Message-IDが存在していなかったり、フォーマット違反の場合にGmailのサーバがMessage-IDを書き換えるらしく、その際に元のMessage-IDが存在した場合はX-Google-Original-Message-IDに残されているようです。

そして書き換えるMessage-IDには@の左側にSMTPIN_ADDED_BROKENという文字列を追加しているようです。

今回の場合は以下のパターンに当てはまっていてRFCを遵守していないため、GmailのサーバによってMessage-IDが書き換えられたと推測されます。

  • Message-IDのフォーマットが異なる
    • Message-IDが<left@right>の形式でない
      • Message-IDの値の前後には山括弧<>が必要
    • Message-IDに使用できない文字が使用されてる(今回の場合は:コロン)

もしかしたら山括弧はX-Google-Original-Message-IDに残す際に外されてしまっていただけかもしれません。

DKIM

このメールを眺めていて1点気になったことがあります。それはDKIM認証に失敗しているという点です。

ARC-Authentication-Results: i=3; mx.google.com;
       dkim=fail ********;
       arc=pass (i=2 spf=pass ******** dkim=pass ******** dmarc=pass ********);
       spf=pass ********;
       dmarc=pass ********;
       dara=pass ********
ARC-Authentication-Results: i=2; mx.google.com;
       dkim=pass ********;
       spf=pass ********;
       dmarc=pass ********
ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass ********;
       spf=pass ********;
       dmarc=pass ********

最初からDKIM認証に失敗しているのであれば、このサービス提供者側の問題である可能性が高いですが、ARC認証の結果を見る限りメール配送の最初の段階では失敗しておらず、最後の到着時に失敗しているようなので、受信側でのメール転送のどこかで問題(改竄)が発生している可能性が高いです。

ここでDKIMのRFC 6376を読んでみると、DKIMは本文だけでなくメールヘッダも署名でき、Fromは署名が必須として他の項目も任意に署名できるとのこと。署名したヘッダはDKIM-Signatureのhタグに羅列されるようです。

ということでDKIM-Signatureを確認してみます(見やすいようにタグごとに改行を入れています)。

DKIM-Signature:
 v=1;
 a=rsa-sha256;
 c=relaxed/relaxed;
 d=********;
 s=default;
 t=********;
 h=Mime-Version:Date:From:To:Subject:Message-ID:Content-Type;
 bh=********;
 b=********

この送信者のメールはMessage-IDが署名の対象に入っています。つまりMessage-IDが変更されるとDKIM認証が通らなくなります。確証は全くありませんが、拒否の要因となりそうな事情は見えてきましたね。

Message-IDが正しくないメールについて、GmailのサーバによってMessage-IDの書き換えが行われ、その結果としてDKIMでMessage-IDに署名が入っているメールはDKIM認証が通らなくなっているようです。

結論・推論

公式情報は見つけられなかったのでどこまで行っても推測でしかありませんが、ここまで調べた結果から以下の結論が見えてきました。

  • Gmailのサーバは受信メールのMessage-IDがRFCの推奨要件に準拠しない場合はMessage-IDを独自に書き換え
    • Message-IDはMUSTではないがSHOULD
  • Gmailは前項のメールの転送を拒否するようになった
    • Message-IDを書き換えるとDKIM認証が通らなくなる可能性があるためやめた？

昨今の迷惑メール対策の強化によって、そもそもRFCに準拠しないおかしなメールは排除しようということですかね。Googleが独自に謎仕様を入れているわけではなさそうです。MUSTではなくSHOULDなのでGoogleがなんとかすべきという考え方もあるかもしれませんが、SHOULDも強い単語ですので軽視すべきではないと思います。

とはいえメール送信側の問題なので受信側のユーザにはどうすることもできません。メール送信側の管理者に改善依頼をするか、別のログイン手段に頼るか、きっぱりそのサービスの利用を辞めるかのいずれかとなりそうです。

色々書きましたが、つまるところ標準化された技術(今回の場合はメール)を使う人や事業者は、余程のことがない限りは仕様に準拠しましょう、ということですね。

カテゴリ: Webサービス

最新の記事

カテゴリ

その他