最近のGmailのメール送信者のガイドラインの変更等もあり、ユーザ側の送信ドメイン認証の設定が強化された場合や、受信メールサーバで送信ドメイン認証の検証の強化が行われた場合に、WEBフォームなどのシステムから内部へのメールが届かない場合が発生するのではないかと想像している。
この記事の主旨
「内部へのメールのヘッダFromのアドレスがユーザの入力したアドレスになっていないか?なっている場合、そのままで大丈夫な状況か?」確認しませんか?
はじめに
これまでの経験上、WEBフォームから内部へのメールが届いていない状況に遭遇し、また、自分でもWEBフォームから内部へのメール送信を行うシステムを作成・管理しているので、気づいた点を書いた。
ユーザの入力メールアドレスをヘッダFromにして送信するメールに対する送信ドメイン認証は、意外と盲点となっているような気がしている。
前提
以下の2つの図のような、WEBサーバに問い合わせWEBフォームがあり、そこにユーザが記入した内容を元に、ユーザ向けに控えのメール・内部向けに問い合わせ内容がメールで届くという形を想定
上記2つの、WEBサーバが直接メールを出す場合でも、APIを使って別サーバがメールを出す場合でも同じなので、以下は1つ目のWEBサーバが直接メールを送信する場合だけで記述します。
メールのヘッダ
上記図のように、ユーザ向けの控えと内部向けの問い合わせメールのヘッダは、以下になると想定します。
EnvFrom: webmaster@www.example.com
From: support@example.com
To: user@example.jp
EnvFrom: webmaster@www.example.com
From: user@example.jp <- ユーザのメールアドレス
To: support@example.com
注意のヘッダ(内部向け問い合わせメールのヘッダFrom)
今回のポイントは、内部向けの問い合わせメールのヘッダFromがユーザが入力したユーザのメールアドレスになっていることです。これは、内部の受信者が対応するときに、単純に返信を行うだけで、ユーザのメールアドレスが宛先になるため、このような設定にしている場合も多いと考えています。
送信ドメイン認証でどうなるか?
控えのメールに対する送信ドメイン認証
適切な設定ならば、特に問題ない。
内部向けの問い合わせメールに対する送信ドメイン認証
下記のような送信ドメイン認証(SPF,DKIM,DMARC)の設定をしていた場合は要注意と考えます。
DMARC: p=reject; rua=postmaster@example.com
SPF: ip4:(送信メールサーバのIP) ip4:(webserverのIP) -all
DKIM: (適切設定)
この場合、図の右下のメールサーバ(内部のメールサーバ)で送信ドメイン認証の検証を行うと、
SPF: PASS
DKIM: PASS(example.com / 第三者署名)
DMARC: FAIL
SPF:webserverのIPは、EnvFrom のドメイン(example.com)のSPFに含まれるはず
DKIM:www.example.com ドメインexample.comでDKIM署名されているはず
DMARC:ヘッダFromのドメイン(example.jp) != EnvFromのドメイン(example.com)のため、SPFアライメント失敗。
ヘッダFromのドメイン(example.jp) != DKIM署名のドメイン(example.com)のため、DKIMアライメント失敗。
そのため、DMARCはFAIL
結果: ヘッダFrom のドメイン(example.jp)のDMARCのポリシーにより、REJECT
DMARCの結果 = REJCET ということは
考察
- WEBサーバが、ユーザドメインのメールを転送しているのと、類似の状況?
- ユーザのドメイン(example.jp)からみると、DMARCレポートより、WEBサーバが迷惑メールを送っているのと、類似の状況?
- WEBサーバが直接ではなく、APIなどで外部メール送信サービスがメールを送信しても、ヘッダFromがユーザメールアドレスならば、同じ状況
- 右下のメールサーバ(内部のメールサーバ)が、Google Workspace や MS365 などでも、DMARCの検証を行うならば、同じ状況
- 右下のメールサーバ(内部のメールサーバ)が、プロバイダ等のサーバなどでも、DMARCの検証を行うならば、同じ状況
- 右下のメールサーバ(内部のメールサーバ)を自前サーバにした場合は、WEBサーバのIPをホワイトリスト等で許可すれば、問題は発生しない。(しかし、WEBサーバ変更毎に対応必要)
- WEBサーバ自身にメールを保存するようにする。(WEBサーバでメールサーバも動作させると同じ?・取得が一定間隔毎になる?)
- EnvFromのドメインをユーザのドメイン(example.jp)にした場合は、ユーザドメインのSPF設定に依存(-all ならば、同じ状況)
- WEBサーバで、ARCヘッダ付与で対応可能?
- ヘッダFrom をユーザのメールアドレスでなく、自社のドメイン(example.com)にする。(内部の受信者・システムでの対応が必須となりそう)
まとめ
以下の条件がそろうと、メールが届かない場合が発生する可能性があると推測。
- WEBフォームなどからのメールのヘッダFromにユーザのメールアドレスを設定
- ユーザのドメインのDMARCのポリシーがreject
- WEBフォームなどからのメールを受信するメールサーバがDMARCの検証を実施し、ポリシー通りに処理
確認ポイント
「WEBフォームなどから内部へのメール届いているか?」
- WEBフォームの設置者
「内部へのメールのヘッダFromのアドレスがユーザの入力したアドレスになっていないか?なっている場合、そのままで大丈夫な状況か?」
- メールサーバ管理者・WEBフォームの設置者
「WEBフォームからのメールの経路を確認しなくて大丈夫か?」 - メールサーバ管理者
「送信ドメイン認証で拒否を行うサーバが、WEBフォームなどからのメールの経路に存在しているか?存在しても大丈夫な状況か?」
おわりに
ご指摘等ありましたら、是非お願いいたします。