Eメールは時代遅れでもダサくもない！ SPF, DKIM, DMARC, そして BIMI について

1. Eメールはまだまだ⾯⽩い
Kei Onimaru <otegami@devel.keys.jp>
Twitter: @keionim

2. もくじ
• Eメールはオワコンなのか？
• メールサーバはVPSと相性がいい件
• SPF, DKIM, DMARC の処理の流れ
• BIMI の処理の流れ、現状、今後
• まとめ
• (おまけ)インターネット老人会のみなさまへ
2

3. はじめに
• ハウツーの話はしません、技術自体の話をします
• メールサーバを建てる方法はググるとかなり出てきます
• さくらのVPS部分のことがあれば書きたかったですが、なかったです
• DNSのレコードを設定する画面、ちょっと癖がある気が
• ただ、せっかくなので後でQiitaに書こうかと思ってます
• IPv6を使って構築したという情報がないので……！
3

4. Eメールはオワコンなのか
• オワコンと思う人は多い、らしい
• ずっと前からスパムが多く、印象がよくない
• 最近はフィッシングで使われるので印象は劇的に悪化
• 若い技術者からは「脆弱で、時代遅れな、ダサい技術」と思われている
• しかしオワコンではない
• 置き換えるものが今のところ見当たらない
• 組織間でやりとりするにはメールしか方法がない場合も
• 一般論として、新しいものを作るより現状を改善していく方が楽(なことが多い)
(IPv4……NAT……CGN……)
• 欠点を埋めるための仕様が今も策定進行中
4

5. だからメールサーバとあそぼう？
• オワコンの技術を知ろうとするのはモチベが沸かない
• もちろん、そう思わない人もいると思います
• でも未来のある技術だったらモチベが沸くよね？
• だったら、メールサーバを建てて遊びながら勉強だ！
• その環境は……？
5

6. メールサーバとVPSは相性いいよ！
• よりよいメールサーバの要件
• IPアドレスが固定であること
• IPアドレスの逆引きができること
• 24時間365日稼働すること
→ クラウドでも可能、でもVPSなら何も考えなくても要件を満たす
• さくらのVPSだと……
• VPSを契約するとDNSのゾーンを追加費用なしで使える
→ 必要なDNSレコードもばっちり設定できる( ^o^)ﾉ
6

7. SPF, DKIM
7

8. SPF (Sender Policy Framework)
• メールを送信するサーバを限定している、と受信側に伝える
• 基本的な技術で歴史が長く、普及率も高い
• 2019年1月段階で87.6%というデータも
• 独自ドメイン名を持っている人はすぐ導入できる
• レンタルサーバでもできる
• さくらならこちら
https://help.sakura.ad.jp/206206521/
• ただし設定をミスすると判定に失敗してスパム扱いされる可能性が
• DMARCをあわせて設定しておくとミスに気付きやすい
8

9. SPFの設定例
• DNSサーバに以下のようなレコードを追加する
example1.com IN TXT "v=spf1
ip6:2001:db8:11:beaf:198:51:100:53 ip4:198.51.100.53 ~all”
• 以上
• すごくシンプル、すごく簡単
• 指定の方法は他にもあり、運用よっては複雑になることも
9

10. DKIM (DomainKeys Identified Mail)
• 送信するメールに電子署名をして本人の証明をする
• 「ディーキム」と発音する(正式なものかどうかは不明)
• 送信するサーバで署名
• 電子署名用の鍵ペア(秘密鍵、公開鍵)を作って、公開鍵をDNSに記載
• 送信するメールに秘密鍵を使って電子署名を施す
• 受信するサーバで検証
• 検証するための公開鍵をDNSから取得する
• その鍵を使って電子署名を検証し、真正性を確認する
10

11. DKIMの⻑所・短所
• なりすまし防止策として、かなり強力
• 署名用の秘密鍵がなければ、なりすましはできない
• ただし設定に失敗していると、なりすましを疑われる可能性が低い
• メールサーバに専用のソフトウェアを導入する必要がある
• レンタルサーバでは不可能(なことが多いはず)
• レンタルサーバ自体が対応して機能を提供することはできるかも
11

12. DKIMの⾒本 (送信側)
• 事前に、DNSサーバに以下のようなレコードを設定する
s20200818._domainkey.example1.com IN TXT "v=DKIM1; k=rsa;
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDApQlxn7nTC9J2oO9BsEZi8YhFbwpzlOIK++73IrH7bqw3qEmXOlHtIdU
GVtaIV4yVCQoSKJ+0tsLnniL8wUB2POrtBDW99HSFg8D5txEnpRe0JfzRqjGvIyWxaIByL+UDRxikXPA1WcTfpqaq+THv9lqC
Dku49gSjH+sNQ8qrNQIDAQAB”
(p が検証に使う公開鍵)
• メール送信時に、署名するソフトウェアが以下のようなヘッダを追加する
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=s20200818; t=1597738195;
bh=vsw5ndfzuVGo/Fn9b23m+399ZsWK/YC0pZEdcs8lxvI=; h=From:Subject:Date:To:From;
b=tm68BF7O8b+4RYYHSzSGKUXW3VoR4Ex9tIH7oytXTKA942pJ+kT0DY91TVHQFW5DZ
olfSeUrGTRYNRIsjGhbnuc6wq2y8POrdjPBGwEhtYn2mHdWYxKbt9ohDY5ioBvf+vI
stz3kkZLz6Y+QX9B9jZwwzIs0iAm0dg43zFYmDy4=
(黄色の部分が署名対象のヘッダで、この内容と本文を公開鍵で検証する)
12

13. DKIMの⾒本 (受信側)
• 受信したメールに署名のヘッダがあった場合、公開鍵を取得する
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example1.com; s=s20200818;
t=1597738195; bh=vsw5ndfzuVGo/Fn9b23m+399ZsWK/YC0pZEdcs8lxvI=; h=From:Subject:Date:To:From;
b=tm68BF7O8b+4RYYHSzSGKUXW3VoR4Ex9tIH7oytXTKA942pJ+kT0DY91TVHQFW5DZ
olfSeUrGTRYNRIsjGhbnuc6wq2y8POrdjPBGwEhtYn2mHdWYxKbt9ohDY5ioBvf+vI
stz3kkZLz6Y+QX9B9jZwwzIs0iAm0dg43zFYmDy4=
• 署名ヘッダの d と s の値をもとに、DNSサーバのTXTレコードから得られる
これを手動でやってみると、以下のようになる
dig s20200818._domainkey.example1.com txt
• この公開鍵をつかって検証する
13

14. DMARC
14

15. DMARC
(Domain-based Message Authentication, Reporting, and Conformance)
• SPF, DKIMでの認証結果の扱い方を受信側に伝える
• たとえば
• SPFの結果は使わず、DKIMの結果だけで判定してほしい
• 判定に失敗したときは受信を拒否(reject)してほしい
• などなど
• 受信側がメールをどう扱ったか、送信側に伝えてもらう
• 自分が送ったメールの判定の集計情報や、失敗したものはどのような
ものかを通知してほしい旨と、そのメールアドレスを指定する
15

16. DMARCの⾒本
• 送信側で設定するDNSレコード
_dmarc.example1.com IN TXT “v=DMARC1; p=quarantine;
rua=mailto:rua@example1.com; ruf=mailto:ruf@example1.com”
• p で認証に失敗したメールの扱いを設定する
• ここではquarantine=隔離して扱ってほしいと指示している
• 他にnone(何もしない)やreject(受信拒否)がある
• rua, ruf で集計情報や失敗報告の送信先を設定する
• スキームの設定(mailto:)が必要だが、今のところメールアドレスのみ
16

17. DMARCの⾒本 (cont.)
• 受信サーバが検証結果を記録したメールヘッダ
Authentication-Results: mx.google.com;
dkim=pass header.i=@example1.com header.s=s20200818 header.b=tm68BF7O;
spf=pass (google.com: domain of user@example1.com designates
2001:db8:11:beaf:198:51:100:53 as permitted sender)
smtp.mailfrom=user@example1.com;
dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE)
header.from=example1.com
• SPF,DKIMで認証成功し、DMARCの判定でも成功した、という意味
• p/sp はDNSで指示された内容を指す
17

18. DMARCのレポート機能
• 集計情報は、標準では1日1回送られてくる
• 受信サーバから各々送られてくる
• 仮に、ある日に送信したメールの宛先のドメインが1万個あり、受信側がすべてDMARCに
対応していた場合、翌日1万通のメールが届く
• XML形式
→ 機械処理が前提
• 使い方
• SPFやDKIMの設定確認、見直し
• 判定失敗の報告が多い場合、設定ミスや設定漏れがある可能性を考える
• なりすましの発見
• 報告の割合が増えた場合、自分のなりすましが表れた可能性がある
18

19. BIMI
19

20. BIMI
(Brand Indicators for Message Identification)
• メールのアイコン画像(ブランドロゴ)の表示を指示する
• 紛らわしいドメイン名を使ったなりすましへの対策
• 商標登録された画像を用いることを想定
• DMARCで判定が成功しなければ処理しない
• なりすましでないことはサーバで確認済み
• 利用者に、なりすましでないことを分かりやすくすることが目的
• 原理はEV証明書と全く同じ
• CAは、画像が商標登録されているか、などを確認して電子証明書を発行する
• 証明書が正当に使われている時だけユーザに表示
• “Bih-mee” と発音する(日本語だとビーミー？)
20

21. BIMIの設定例
• 送信サーバが加えるメールヘッダ
BIMI-Selector: v=BIMI1; s=s20200818
• セレクタ s20200818 のBIMIを表示してほしいという指示
21

22. BIMIの設定例 (cont.)
• 送信サーバ側で設定するDNSレコード(その1)
s20200818._bimi.example1.com IN TXT "v=BIMI1;
l=https://www.example1.com/logo.svg; a=https://www.example1.com/logo-
cert.pem”
• セレクタ s20200818 のBIMIの画像は l パラメータのURLにあり、その
証明書は a パラメータのURLにある
22

23. BIMIの設定例 (cont.)
• 送信サーバ側で設定するDNSレコード(その2)
s20200818._bimi.example1.com IN TXT "v=BIMI1;
l=https://www.example1.com/logo.svg”
• a パラメータ(証明書)がないバージョン
• 現時点では証明書はオプションだけど、最終的には必須になりそう
23

24. BIMIの挙動
• 受信サーバのBIMIの扱い
• DKIMと似ている
• メールヘッダのセレクタが示すTXTレコードを取得
• 指定された画像を読み込む
• 証明書が指定されている場合、証明書で画像の真正性を確認する
• 結果をメールヘッダに追加する
• BIMI-Location にTXTレコードのURLをそのまま設定
• BIMI-Indicator に読み込んだ画像をbase64エンコードして埋め込む
24

25. BIMIのユーザへの⾒え⽅
25

26. 試すハードル⾼い！
• 画像を用意するのが難しい
• SVG、かつ Tiny 1.2 Portable/Secure プロファイル(新規格)
• 元となる Tiny 1.2 対応のソフトウェアが少ない
• Illustrator は対応、Inkscape は非対応
• 出力後、Tiny 1.2 P/S へ変更するため手で書き換える必要がある
• マニュアルには Illustrator での作り方しか書いていない
• 他のソフトウェアで出力したものも、マニュアル通りにできるのかは不明
• 動作確認が難しい
• 対応しているサービスが少ない
• Yahoo! Mail (米) でテスト中
• Googleが実証実験開始(2020/7/22)、ただし証明書必須
26

27. BIMIの動向
• 規格の正式版に向けて作業中
• 最新の版は2020年7月30日の第2版
• なのでここに書いたものがすぐobsoleteになる可能性も……
• 証明書発行のガイドラインも制定中
• 既存のEV証明書より発行要件を厳格化・明文化する、など
• 今のところ設定しても検証は困難
• ただ概要を知っておくだけでも有益かと
27

28. まとめ
Eメールの未来
28

29. まだまだ
• Eメールはまだまだ使われる
• 信頼を取り戻すための取り組みが続いている
• Eメールを置き換えるものが今のところ見当たらないし
• Eメールはまだまだ楽しいよ！
• いまでも新しいことが追加されている
• 枯れた技術の組み合わせではあるのですが……
• もっと(orまた)触ってみませんか？ その価値はありますよ！
29

30. 参考資料
• SPF, DKIMなどの仕様の解説
• なりすまし対策ポータル ナリタイ
https://www.naritai.jp/
• 送信ドメイン認証（SPF/DKIM/DMARC）の仕組みと、なりすまし
メール対策への活用法を徹底解説 – IIJエンタープライズITコラム
https://ent.iij.ad.jp/articles/172/
30

31. 参考資料 (BIMI)
• WGのサイト
• BIMI: AuthIndicators Working Group
https://bimigroup.org/
• 規格書(ドラフト版)
• 基本設計書
Brand Indicators for Message Identification (BIMI)
https://datatracker.ietf.org/doc/draft-blank-ietf-bimi/
• 受信側の実装ガイドライン
Receivers Guidance for Implementing Branded Indicators for Message
Identification (BIMI)
https://datatracker.ietf.org/doc/draft-brotman-ietf-bimi-guidance/
31

32. おまけ
32

33. んん……？
メールヘッダに……画像……？
なんだかデジャヴが……
33

34. X-Face！
34

35. X-Faceとは
• 前世紀に登場した、48x48のモノクロ画像をメールヘッダに埋め込む手法
X-Face: #0cNb<$ep84N|?4"q?{DwR3a5gYAZIl#e%qPNgeZB"yv^74xPm(¥,sh.cGj38vYXq@p;r*n
*fo1eyh&GWWhumq5sQVF/->tb+NP8mw&w$pT."nrPBsYLM{3DVX)16M|7er,VG+178cHW8OvuR+tlx -%@+^TK`1GRF-
Q#yMIKO|O{:LUwArJ@D{)>[b)=cC+J^OwKpe|+NA)j.rol$@,#<C@H[F[w
• BIMIはその点で、X-Faceの進化版といえる()
35
引用元: (作者: 平田泰行さん)
https://www.wdic.org/w/WDIC/X-Face

36. アバター埋め込みたい……
• プライベートでもアバター使いたくないですか？
• BIMI本来の目的とは別に、単にアバター表示に使いたい
• ユーザに見せるとき、はっきりと分かることが大事
• Twitterのバッジとは逆で、証明書のないときに付ける
• BIMIとは趣旨が違うので、形式が同じで名前の違うヘッダを付ける
• BIMIと同じコードをそのまま流用できるので実装コストは低いはず
• BIMIに触れて同じことを思う人が増えたら、道が開かれないかな
• ……という夢想をしております( ^o^)ﾉ
36