MTA-STSについて

[2018年09月26日](https://datatracker.ietf.org/doc/rfc8461/)に**[RFC 8461](https://tools.ietf.org/html/rfc8461)**が公開されました。**MTA-STS（SMTP MTA Strict Transport Security）**と呼ばれるSMTPのセキュリティに関連する新しい仕様です。最初のドラフトは2016年5月に公開されている[^1]ので2年半ほどかけてRFCとなったようです。最終的な仕様は[Google](http://www.google.com)、[Microsoft](https://www.microsoft.com)、[Comcast](https://corporate.comcast.com/)、[Oath](https://www.oath.com/)[^2]で策定しています。

[^1]: 当時はSMTP-STSと呼ばれていた
[^2]: [ドラフト時点](https://tools.ietf.org/html/draft-ietf-uta-mta-sts-21)ではYahoo!, Incと表記

日本語情報をあまりみかけないので少し調べてみました。

# MTA-STSとは？

ざっくり書くと**「SMTPで厳格にTLSを使うために、メールサーバ(MTA)がTLSに対応していることをポリシーとして宣言して、検証できるようにする仕組み」**です。宣言・検証はDNSとHTTPSを組み合わせて行います。

MTA-STSが生まれた背景について、[RFC 8461のIntroduction](https://tools.ietf.org/html/rfc8461#section-1)でSTARTTLSの問題点を触れています。

[RFC 3207](https://tools.ietf.org/html/rfc3207)のSTARTTLSはSMTPの通信をTLSにする仕組みですが、日和見暗号化（Opportunistic Encryption）のため、相手先がTLSに対応していない場合は平文での通信となります。これには問題があって、たとえば中間者攻撃(man-in-the-middle attack、MITM)で仲介して平文にダウングレードさせたり、DNSクエリによる問合せを仲介して攻撃者の管理下にあるサーバのMXを返したり、といったことをして内容の傍受が可能となってしまいます。

![Untitled (56).png](https://qiita-image-store.s3.amazonaws.com/0/47737/18eba6a8-893e-fd7a-1784-275bbb01d850.png)


この問題を解決するためにMTA-STSが考えられました。[^3]

[^3]: 関連する技術に[DANE(DNS-Based Authentication of Named Entities)](https://tools.ietf.org/html/rfc7672)があるとRFCにはありますが、よくわかっていないので別の機会に…。 ([参考1](https://www.nic.ad.jp/ja/basics/terms/dane.html),[参考2](http://causeless.hatenablog.jp/entry/2015/06/11/205049)）

# MTA-STSに対応するには？
次のステップを踏みます。

- TLSに対応し、証明書等に問題がないことを確認する
 
https://en.internet.nl/test-mail/ などで確認できるようです。

- DNSに[MTA-STS TXTレコード](https://tools.ietf.org/html/rfc8461#section-3.1)を追加する

ドメインがexample.comの場合は次のようなTXTレコードをDNSに定義して、MTA-STSのポリシーに対応することを示します。idはポリシーの更新をチェックするためのもので、タイムスタンプやランダムな数値を入れるとのこと。

```
_mta-sts.example.com.  IN TXT "v=STSv1; id=20181111085700Z;"
```

- [MTA-STS Policies](https://tools.ietf.org/html/rfc8461#section-3.2)を配置する

[RFC 5785のwell known](https://tools.ietf.org/html/rfc5785) URLを使って、次のパスにtxtファイルを配置します。


```
https://mta-sts.example.com/.well-known/mta-sts.txt
```

ファイルの中身は次のようなkey/valueの値です。

```
version: STSv1
mode: enforce
max_age: 10368000
mx: mail.example.com
mx: *.example.net
mx: backupmx.example.com
```

versionは「STSv1」で固定です。

modeは「enforce」「testing」「none」のいずれかで、検証結果を定義します。enforceは、失敗した場合はSTARTTLSに対応していないと判断します。testingの場合は[RFC 8460の SMTP TLS Reporting](https://tools.ietf.org/html/rfc8460)に沿ってレポートが行われるとのことで、たとえば次のようなTXTレコードでレポート先を指定できるようです。mxではワイルドカード(*)も使えるとのこと。

```
 _smtp._tls.example.com v=TLSRPTv1; rua=mailto:mta-sts@example.com
```

このような流れになるようです。
![Untitled (55).png](https://qiita-image-store.s3.amazonaws.com/0/47737/44b284dc-354e-2caa-c8b6-379ef96096a4.png)

このチェックフローが読み取りにくかったのですが、以下がわかりやすかったです。
https://www.youtube.com/watch?v=VJKjfosckuU

# Gmailの確認結果

Gmailは既にMTA-STSに対応しているようなので確認してみました。

まずはMTA-STS TXTレコードを調べてみます。

```shell
dig -t txt _mta-sts.gmail.com
```

結果は次のとおり、定義されていました。

```
;; ANSWER SECTION:
_mta-sts.gmail.com.     300     IN      TXT     "v=STSv1; id=20171114T070707;"
```

続いてMTA-STSのポリシーを確認してみます。以下のURLにアクセスするだけです。

https://mta-sts.gmail.com/.well-known/mta-sts.txt

Gmailではmodeが「enforce」となっていました。（記事執筆時はtestingでしたが、その後、時期不明ですがenforceに変わりました。）

![2019-06-05_18h02_54.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/47737/73c11566-b720-b40e-77b7-c892cdb05e8b.png)

ということは、SMTP TLS Reportingもありそうです。

```shell
 dig -t txt _smtp._tls.gmail.com
```

結果をみると次のとおり定義されていました。

```
;; ANSWER SECTION:
_smtp._tls.gmail.com.   300     IN      TXT     "v=TLSRPTv1;rua=mailto:sts-reports@google.com"
```

今回は手動で1つ1つ確認しましたが、以下のサイトを使って簡単に確認できるようになっています。
https://www.hardenize.com/
![2018-11-08_23h53_20.png](https://qiita-image-store.s3.amazonaws.com/0/47737/2111aed5-590e-92ba-5618-6df96c95fa73.png)

![2018-11-08_23h52_35.png](https://qiita-image-store.s3.amazonaws.com/0/47737/265a4427-cbe9-a17a-b5a1-792855b58a08.png)

![2018-11-08_23h53_02.png](https://qiita-image-store.s3.amazonaws.com/0/47737/10808600-d066-0705-ede5-6c67108f4646.png)

https://aykevl.nl/apps/mta-sts/ (コマンドベースもある https://github.com/aykevl/mta-sts )
![2018-11-08_23h51_47.png](https://qiita-image-store.s3.amazonaws.com/0/47737/af8e2d20-fe14-7973-0cbe-751105436374.png)

# 参考

- [Introducing MTA Strict Transport Security (MTA-STS)](https://www.hardenize.com/blog/mta-sts)
- [ENCRYPTING THE CONNECTION BETWEEN EMAIL SERVERS](https://www.trustzone.com/mta-sts-encrypting-connection-between-email-servers)