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

# はじめに
2024年2月以降、Gmailアカウントに対してメールを送信する送信者は、Googleから公開されている[メール送信者のガイドライン](https://support.google.com/a/answer/81126?visit_id=638418586891004291-3788428211&rd=1)に沿った対応が必要になりました。

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

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

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

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

![代替テキスト](https://upload.wikimedia.org/wikipedia/commons/0/01/SMTP%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8B%E3%82%B5%E3%83%BC%E3%83%90%E3%81%A8%E3%82%AF%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%88%E3%81%AE%E5%BD%B9%E5%89%B2.png)
出典元：ウィキペディアの[Simple Mail Transfer Protocol](https://ja.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol)

現在のSMTPに関する仕様は、IETFによって[**RFC5321**](https://www.rfc-editor.org/rfc/rfc5321.html)で標準化されています。
また、Internet Message Format[^1]は[**RFC5322**](https://www.rfc-editor.org/rfc/rfc5322.html)で標準化されています。

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

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

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

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

SMTP認証については、[**RFC4954**](https://www.rfc-editor.org/rfc/rfc4954.html)で標準化されています。

### 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**](https://www.rfc-editor.org/rfc/rfc3207.html)で標準化されています。

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

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

![メール技術.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/221759/4e657859-057f-6c98-b233-0e6f2a3ee542.png)

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

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

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

::: note
フィッシングメールについては以前書いた[ソーシャルエンジニアリング攻撃　フィッシングメールについて理解する](https://qiita.com/Brutus/items/1f93dd797ba29acb0fcb)もご参考にください。
:::

[^2]: SMTPのMAILコマンドで設定するアドレス
[^3]: メールデータの中身であるFromヘッダに設定するアドレス

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

![メール技術-SPF.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/221759/2398e9a5-7205-c66a-9270-dc276f8a8684.png)

現在のSPFに関する仕様は、[**RFC7208**](https://www.rfc-editor.org/rfc/rfc7208.html)で標準化されています。

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

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

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

```console
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"`

```console
_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レコードを確認すると、以下の様な結果が確認できます。

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

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

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

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

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

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

![メール技術-DKIM.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/221759/949d4d7a-146a-49b7-cf65-8661368ab668.png)

現在のDKIMに関する仕様は、[**RFC6376**](https://www.rfc-editor.org/rfc/rfc6376.html)で標準化されています。

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

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

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

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

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

![メール技術-DMARC.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/221759/26e1659e-03ee-4056-6886-4d2be82a46e2.png)

現在のDMARCに関する仕様は、[**RFC7489**](https://www.rfc-editor.org/rfc/rfc7489.html)から確認できます。（※Category: Informational）

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

`$ dig -t txt _dmarc.apple.com`

```console
_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レコードに定義されたポリシー基づき、ポリシーに基づくアクションを実行する
- レポーティング
    - ドメインの所有者に、メールを受信したメールサーバの認証失敗に関するレポートをフィードバックする


::: note
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](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/221759/389805fe-a276-8026-dd11-cef567f5151f.png)

**※ETC利用照会サービスのウェブサイトにて[フィッシングサイト・不審メールにご注意ください](https://www.etc-meisai.jp/caution/caution_phishing.html)の注意喚起がされています。**

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

- DMARCポリシーの結果
    - Header Fromアドレスのezairyu.mofa.go.jpドメインがDMARCポリシーに違反していないため、DMARCポリシーの結果はfailとなっています

    ```text
    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
    ```
- 差出人情報の不一致
    - 上記DMARCポリシーの結果を踏まえて、Fromヘッダにはno-reply@ezairyu.mofa.go.jpが使用されているものの、Senderヘッダにはnoreplyy24@j-flat.comが設定されている

    ```text
    Sender: <noreplyy24@j-flat.com>
    From: =?utf-8?B?RSBUIEMg5Yip55So54Wn5Lya44K144O844OT44K5?= <no-reply@ezairyu.mofa.go.jp>
    ```
- 怪しいリンク
    - メール内にユーザーを誘導するための怪しいリンクが含まれている

::: note warn
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](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/221759/82ea73d2-e864-1f68-0d23-9fc639a42d5e.png)

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

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

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

        ```text
        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
    - 受信したメールがスパムと判定された場合、ヘッダに追加される

        ```text
        x-spam-flag: yes
        ```

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

        ```text
        x-suspected-spam: true
        ```

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

        ```text
        X-ICL-SCORE: 4.142034030044
        ```

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

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

- [迷惑メールフィルタ レポート](https://support.google.com/a/answer/7491892?sjid=10351328005065962086-AP)

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

## 参考
- [送信ドメイン認証技術導入マニュアル](https://www.dekyo.or.jp/soudan/data/anti_spam/meiwakumanual3/manual_3rd_edition.pdf)
- [特定電子メール等による電子メールの送受信上の支障の防止に資する技術の研究開発及び電子メール通信役務を提供する電気通信事業者によるその導入の状況](https://www.soumu.go.jp/main_content/000905619.pdf)
- [2-1 パソコンの対策](https://www.dekyo.or.jp/soudan/contents/taisaku/2-1.html)