Go to Qiita Advent Calendar 2024 Top
LoginSignup
1
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@Brutusinインフラ勉強会

迷惑メールから学ぶメール技術　送信ドメイン認証の仕組み

Posted at

はじめに

2024年2月以降、Gmailアカウントに対してメールを送信する送信者は、Googleから公開されているメール送信者のガイドラインに沿った対応が必要になりました。

ガイドラインに準拠しない場合、Gmailアカウントのメールアドレスに対してメールが届かなくなります。

本記事では送信ドメイン認証の仕組みを中心に、迷惑メール対策で使用されているメール技術の概要について記載しています。

Simple Mail Transfer Protocol（SMTP）

Simple Mail Transfer Protocol（SMTP）は、インターネットで電子メールを転送するプロトコルです。

SMTPは、メールクライアントのソフトウェアからメールサーバに対する通信やメールサーバ間の通信で使用されています。また、TCPの25番を使用して通信を行います。

代替テキスト
出典元：ウィキペディアのSimple Mail Transfer Protocol

現在のSMTPに関する仕様は、IETFによってRFC5321で標準化されています。
また、Internet Message Format1はRFC5322で標準化されています。

RFC5321は、SMTPのメール送信や転送に関するプロセスを規定します。RFC5322については、電子メールのメッセージに関するフォーマットを規定します。仕様を定義することによって、異なるメールシステム間におけるメールの互換性が保証されています。

認証機能

SMTP認証は、SMTPの拡張機能としてメール送信時にユーザー認証を行う仕組みです。

メールクライアントのソフトウェアからからメールサーバへメール送信を行う際に、ユーザー名とパスワードを認証することで、成功した場合のみメール送信ができます。

SMTP認証については、RFC4954で標準化されています。

Outbound Port 25 Blocking（OP25B）

Outbound Port 25 Blocking（OP25B）は、スパムメール対策として機能する仕組みです。

SMTPは認証機能がないため、脆弱性があるプロトコルと言われています。理由として25番ポートへ接続可能な場合、認証がないことによってスパムメールが簡単に送信できてしまうためです。

このような背景からほとんどのインターネットサービスプロバイダは25番ポートをブロックしています。メッセージ送信用の安全なポートとして、587番ポートを使用してSMTP認証を行うことで、転送（transfer）と送信（submission）を分ける考え方が生まれました。

暗号化

SMTPS（SMTP over SSL/TLS）は、SMTP通信で使用されるコネクションをSL/TLSによって保護する仕組みです。

SMTPSを使用するためには、お互いがSMTPSに対応していることを確認するためのSTARTTLSという拡張機能を使用します。

SMTPSについては、RFC3207で標準化されています。

送信元メールアドレス

送信元メールアドレスは、Envelope Fromアドレス2と、Header Fromアドレス3の2種類が存在します。

一般的なメールクライアントのソフトウェアで表示されているのは、Header Fromアドレスです。Header Fromアドレスを詐称することで、フィッシングメールなどなりすましメールが可能です。

メール技術.png

Envelope Fromアドレスと、Header Fromアドレスが分かれていることで、様々なシナリオに対応できます。以下にHeader Fromアドレスの正しい使用例について記載します。

メーリングリストの場合、Envelope Fromアドレスは管理用途で使用されるため、Header Fromアドレスを実際のメール送信者に設定することが一般的です。このようにアドレスを使い分けることで、メールシステムは返信やバウンスメッセージをメーリングリストの管理者に転送できます。

ニュースレターやマーケティングなどメール配信代行サービスを利用する場合、Envelope Fromアドレスは配信代行サービスのドメインを使用し、Header Fromアドレスは企業などクライアントのメールアドレスを設定します。従ってニュースレターに登録したユーザーから見ると、Header Fromアドレスは企業などクライアントからメールが送られているように見えます。

フィッシングメールについては以前書いたソーシャルエンジニアリング攻撃　フィッシングメールについて理解するもご参考にください。

Sender Policy Framework（SPF）

Sender Policy Framework（SPF）は、受信したメールの送信元IPアドレスを基に送信元ドメインが詐称されていないかを判定する技術です。

メール技術-SPF.png

現在のSPFに関する仕様は、RFC7208で標準化されています。

DNSのTXTレコードに対して、所定のフォーマットで記述したものをSPFレコードと呼びます。メールの受信者はSPFレコードを参照することで、なりすましかどうかを判定します。

例として、digコマンドを用いてapple.comのSPFレコードを確認すると、以下の様な結果が出力されます。

$ dig -t txt apple.com | grep "v=spf1"

apple.com.		3600	IN	TXT	"v=spf1 include:_spf.apple.com include:_spf-txn.apple.com ~all"

includeは、指定されているドメインに対して再起的に処理することを意味します。同様にincludeに指定されているドメインを引数にして実行すると、許可されたIPアドレスが確認できます。

$ dig -t txt _spf.apple.com | grep "v=spf1"

_spf.apple.com.		3600	IN	TXT	"v=spf1 ip4:17.151.62.66 ip4:17.151.62.67 ip4:17.151.62.68 ip4:17.171.2.60 ip4:17.171.2.68 ip4:17.171.2.72 ip4:17.179.253.33 ip4:17.179.253.34 ip4:17.179.253.38 ip4:17.179.253.39" " ip4:17.179.253.43 ip4:17.179.253.44 ip4:17.179.253.48 ip4:17.179.253.49 ip4:17.179.253.22/31 ip4:17.179.253.24/31 ip4:17.32.222.22/31 ip4:17.32.222.24/31 ip4:17.72.136.23 ip4:17.72.136.24/31" " ip4:17.132.96.0/31 ip4:17.132.100.0/31 ~all"

SPFレコードの最後の~allは、includeを除くその他全てのメールを表します。メールは受信できますが、全て不審なメールとして扱われます。

例として、appleid.comドメインのSPFレコードを確認すると、以下の様な結果が確認できます。

appleid.com.		3481	IN	TXT	"v=spf1 -all"

上記の場合、appleid.comドメインから直接メールが送信しないことを意味するため、この様なドメインからメールを受信した場合は、フィッシング詐欺やなりすましと解釈することができます。

SPFの課題

SPFでは送信元のIPアドレスを基に認証を行うため、転送などによって送信元のIPアドレスが異なる状況では認証に失敗する場合があります。

この課題に対する対策として、Sender Rewrite Scheme（SRS）というにSPFエラーを回避できる仕組みがあります。

メールのメタデータの一部を書き換えることによって、元の送信者のドメインではなく、転送したメールサーバに対してSPFをチェックするようメールサーバに指示することで、SPFエラーを回避できます。

DomainKeys Identified Mail（DKIM）

DomainKeys Identified Mail（DKIM）は、送信者がメールヘッダに電子署名を付加することで、メールの受信者側でメッセージが改ざんされていないことを検証することによって、送信元ドメインが詐称されていないかを判定する技術です。

メール技術-DKIM.png

現在のDKIMに関する仕様は、RFC6376で標準化されています。

DKIMもSPF同様にDNSのTXTレコードに記述します。

DKIMの仕組み

DKIMは以下の仕組みによって構成されています。

  • 電子署名の付与
    • メールを送信する側（送信元のドメイン）にて秘密鍵を生成し、メールサーバで保持する
    • メールを送信する側のメール送信時、DKIM-Signatureヘッダに電子署名を付与する
    • 電子署名には、署名の作成に利用したアルゴリズム、署名したヘッダ、セレクタ4などの情報が含まれている
  • 公開鍵の公開
    • 秘密鍵に対応する公開鍵は、SPFレコードと同じようにDNSのTXTレコードで公開する
  • 電子署名の検証
    • メールを受信する側のメールサーバでは、DKIM-Signatureヘッダから送信元ドメインとセレクタを読み取り、送信元ドメインに関するDNSレコードを参照して公開鍵を取得する
    • 取得した公開鍵を用いて電子署名を検証して、電子署名から取り出したハッシュ値と受信したメールから計算したハッシュ値を比較することで、改ざんされていないことを確認する

Domain-based Message Authentication, Reporting and Conformance（DMARC）

Domain-based Message Authentication, Reporting and Conformance（DMARC）は、SPFやDKIMの課題を解決するために策定された電子メールの認証方式です。

メール技術-DMARC.png

現在のDMARCに関する仕様は、RFC7489から確認できます。（※Category: Informational）

例として、digコマンドを用いてapple.comのDMARCレコードを確認すると、以下の様な結果が出力されます。

$ dig -t txt _dmarc.apple.com

_dmarc.apple.com.	3600	IN	TXT	"v=DMARC1; p=quarantine; sp=reject; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com;"

DMARCの認証

DMARCはSPF及びDKIMの認証結果を踏まえて、以下の様な動作を行ないます。

  • DMARCレコードの取得
    • メールを受信するメールサーバ側にて、メールのHeader Fromアドレスのドメインに対応するDMARCレコードをDNSサーバから取得する
  • SPFとDKIMの結果に基づくDMARC認証
    • SPFまたはDKIMのいずれか、もしくは両方にpassした場合、DMARCのアライメント（Alignment）を確認する
  • ポリシーに基づくアクションの実行
    • DMARCレコードに定義されたポリシー基づき、ポリシーに基づくアクションを実行する
  • レポーティング
    • ドメインの所有者に、メールを受信したメールサーバの認証失敗に関するレポートをフィードバックする

DMARCの認証を成功させるためには、SPFまたはDKIM認証にpassしたドメインがHeader Fromアドレスと一致している必要があります。

DMARCのポリシー

SPFやDKIMを実装した場合でも、認証に失敗したメール自体は受信できるため、受信者側でなりすましメールを開いてしまうなどのリスクが発生します。

また、Header Fromアドレスが詐称できることを踏まえて、悪意のあるものがSPFやDKIMを設定して認証を成功させることで、依然なりすましメールを送ることができます。

このような課題を解決するために、DMARCでは検証に失敗した場合、以下の様な振る舞いを制御するためのDMARCのポリシーが用意されています。

ポリシー 意味
none 何もしない
quarantine 隔離する（メッセージを迷惑メールフォルダに入れるなど）
reject 拒否する

迷惑メールのフィルタリング

Microsoft Outlookをはじめ一般的なメールソフトウェアでは、迷惑メールを受信した場合、迷惑メール用のフォルダに振り分けられます。

メールソフトウェアが迷惑メールを判定するためには、これまで解説したSPF・DKIM・DMARCなど送信ドメイン認証の結果や以下の様な仕組みを組み合わせてフィルタリングを実現しています。

  • キーワード判定
  • ブラックリスト
  • ブラックリスト
  • ベイジアンフィルタ
  • ヒューリスティックフィルタ

フィッシングメールとスパムメールを例として、迷惑メールに振り分けられた理由を確認してみます。

フィッシングメール

以下は実際に筆者が受信した「E T C利用照会サービス」のフィッシングメールです。

スクリーンショット 2024-03-26 23.58.10.png

※ETC利用照会サービスのウェブサイトにてフィッシングサイト・不審メールにご注意くださいの注意喚起がされています。

迷惑メールとして判定された理由は、以下の様な理由が考えられます。

  • DMARCポリシーの結果

    • Header Fromアドレスのezairyu.mofa.go.jpドメインがDMARCポリシーに違反していないため、DMARCポリシーの結果はfailとなっています
    Authentication-Results: bimi.icloud.com; bimi=skipped reason="insufficient dmarc"
X-ARC-Info: policy=fail; arc=none
Authentication-Results: arc.icloud.com; arc=none
Authentication-Results: dmarc.icloud.com; dmarc=fail header.from=ezairyu.mofa.go.jp
X-DMARC-Info: pass=fail; dmarc-policy=none; s=r0; d=r0; pdomain=ezairyu.mofa.go.jp
X-DMARC-Policy: v=DMARC1; p=none; adkim=r; aspf=r

  • 差出人情報の不一致

    Sender: <noreplyy24@j-flat.com>
From: =?utf-8?B?RSBUIEMg5Yip55So54Wn5Lya44K144O844OT44K5?= <no-reply@ezairyu.mofa.go.jp>

  • 怪しいリンク

    • メール内にユーザーを誘導するための怪しいリンクが含まれている

Header Fromアドレスで使用しているezairyu.mofa.go.jpのドメインは、外務省で管理しているmofa.go.jpドメインのサブドメインです。

また、リンクで使用されていた怪しいドメインを分析した結果は以下の通りです。

  • ccTLDは.coとなっているため、コロンビアでありDynadot Incのレジストラで管理されている
  • ドメインに対して逆引きしたIPアドレスは、香港を中心としたホストティング会社である「CTG Server Ltd.」を使用

スパムメール

以下はメールの宛先としてundisclosed-recipients:;5に届いたスパムメールの例です。

スクリーンショット 2024-03-28 0.33.43.png

迷惑メールのメールヘッダを参照すると、以下のエラーやヘッダが確認できます。

  • SPFのsoftfail

    • softfailは、送信元のIPアドレスが~限定子の条件に一致したことを意味します 
      Authentication-Results: spf.icloud.com; spf=softfail

  • DKIMの認証失敗

    • DKIMの署名検証に失敗したことを意味します

      Authentication-Results: dkim-verifier.icloud.com;
	dkim=fail reason="signature verification failed" (1024-bit key) header.d=amyshealthandwellness.co.uk header.i=@amyshealthandwellness.co.uk header.b=qL8c1fmC

  • x-spam-flag

    • 受信したメールがスパムと判定された場合、ヘッダに追加される

      x-spam-flag: yes

  • suspected-spam

    • 受信したメールがスパムとして疑わしい場合、ヘッダに追加される

      x-suspected-spam: true

  • X-ICL-SCORE

    • スパムかどうかを判定するために使用されるスコア

      X-ICL-SCORE: 4.142034030044

組織内の迷惑メールを調査する方法

例としてGoogle Workspaceでは、セキュリティ ダッシュボードから迷惑メールフィルタ レポートを参照することで、迷惑メールの状況を確認することができます。

おわりに

メール技術の歴史を踏まえて、どの様にして課題と向き合ってきたかを考えると、より面白いと思います。

参考

  1. ヘッダフィールド、本文の構造などメッセージを定義することを目的とした仕様 ↩

  2. SMTPのMAILコマンドで設定するアドレス ↩

  3. メールデータの中身であるFromヘッダに設定するアドレス ↩

  4. 公開鍵の識別を行う仕組みであり、一つのドメインに対して複数の公開鍵での運用が可能 ↩

  5. プライバシー保護を目的として、Blind Carbon Copy（Bcc）など複数の受信者に対してメールを一括送信する際に利用される（迷惑メールでも利用されることが多い） ↩

1
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?