SMTP ../密輸
user@sender.example として送信しながら、攻撃者.example ドメインで SPF チェックに合格します。
図 4: user@sender.example として送信しながら、攻撃者.example ドメインで SPF チェックに合格する
これらの IP 範囲のいずれかから送信していない場合、SPF チェックは失敗し、 電子メールは転送されないか、スパムとしてマークされる可能性が高くなります。
しかし、実際にチェックされているのはどのドメインでしょうか? SPF 自体の問題は、メール エンベロープの MAIL FROM ドメインのみがチェックされることです。
メッセージ データの From ヘッダーは、受信した電子メールにさらに 表示されます。図 4 (青色のテキスト) に示すように、任意の値を設定できます。
攻撃者が制御する DKIM キーを攻撃者のサーバーから送信することにより、SPF および DKIM チェックに合格する
*DKIM*(DomainKeys Identified Mail) についても同様です。DKIM では、From ヘッダーを含むメッセージ データに署名できます。この署名は、受信者が DNS に存在する公開キーを使用して検証できます。ただし、どのドメインが公開鍵を 保持するかは強制されません (図 5 を参照)。
この場合、「user@sender.example」からのメッセージは署名されている可能性 がありますが、検証キーは「dkim._domainkey.attacher.example」にあります。 この場所は、セレクター (s=)「dkim」、静的値「_domainkey」、およびドメイ ン (d=)「攻撃者.example」を連結することで得られます。そのため、電子メー ルに有効な SPF レコードと有効な DKIM 署名が含まれているとしても、その電 子メールが悪意のある送信者から送信されたものであるかどうかを判断するメカ ニズムはありません。
1. DMARC
幸いなことに、 「Domain-based Message Authentication, Reporting and Conformance」の略称である*DMARC*があります。DMARC は、SPF と DKIM にいわ ゆる「識別子アライメント」を導入し、送信者が両方のメソッドのアライメント ポリシーを指定できるようにします。電子メールの「差出人」ドメインが SPF チェックや DKIM 署名と一致しているかどうかを検証します。したがって、MAIL FROM と From ドメインの間に不一致がある場合、DMARC チェックは失敗しま す。そうでない場合は SPF チェックが合格します。DMARC ポリシーの例は、常 に _dmarc.[domain] の TXT レコードにあります。ここで確認できます。
v=DMARC1; p=拒否; sp=なし; fo=0; adkim=r; aspf=r; pct=100; RF=AFRF
ポリシー (p=) は、DMARC チェックに失敗したメッセージを 100 パーセント (pct=) 拒否するように受信サーバーに指示します。したがって、有効な SPF レ コードや DKIM 署名が提供された場合にのみ、メッセージは受け入れられます。
しかし、DMARC レコードがない場合はどうなるのでしょうか? 一般に、電子メー ルの信頼性の処理は、受信 SMTP サーバーの構成とソフトウェアに大きく依存し ます。経験則として、SPF または DKIM が一致していれば、電子メールが受け入 れられる可能性が高くなります。
さて、基礎が整ったので、*SMTP 密輸*に移りましょう。