はじめに
gmailの送信者ガイドラインが強化されて2週間ほどが経ちました。みなさんいかがお過ごしでしょうか。
今回の件、いろいろ思うところはあると思いますが、googleはなぜこのようなことをしたのか、そして近い将来、遠い将来メールセキュリティはどうなってくのか考えてみたいと思います。
現状のおさらい
迷惑メールの再定義
迷惑メールといっても人それぞれ定義が違うかも知れません。今回googleはこの定義をより明確にしました。
例えば、「偽者のメール」。最近では、Amazonやカード会社を語った「偽者のメール」をよく目にします。いわゆるなりすましです。
このようなメールは、100%の人が迷惑メールだと考え、受信する必要はないでしょう。
では、あるショッピングサイトからのメールはどうでしょうか。例えば、趣味のおもちゃを買うときに登録したお店から毎日新製品情報が届きます。Aさんは毎日ワクワクしながら新製品のレビューを楽しんでいます。しかし、別のBさんは最初こそ楽しんでいたものの、最近は全く関心がなく、正直毎日来るメールを鬱陶しく感じています。Bさんは、このお店からのメールを「迷惑ルールとして報告」し、受信箱に届かないようにしました。
このような広告メールの場合、人によって、読みたいメールであったり、迷惑メールであったり、判断が異なります。
今回googleのやったことは、シンブルです。
- 偽者の可能性のあるメールは迷惑メールである
- 0.3%(0.1%)以上「迷惑メール報告」がある送信者からのメールは、迷惑メールである
- 広告メールは「迷惑メール報告」されないように、「登録解除」できるようにし、欲しい人だけが受信すればよい
このように今までふわっとしていた迷惑メールの定義が一部はっきりしたことになります。
偽者でないことの証明
偽者じゃない、本物だということの判断には以下の情報が使用されています。
送信元IPの逆引きホスト名の正当性
送信元のIPアドレスを逆引きして、その結果を正引きして、その中に元のIPアドレスがあるかどうかが確認します。かっこよくいうと、FCrDNSといいます。が、メールを知ってる人なら20年以上前からやってるアレです。
192.0.2.1 --> mx.example.jp --> 192.0.2.1
というような確認です。
正引きのDNSレコードはこの場合example.jpの所有者にしか書けないので、mx.example.jpが正しい逆引きホスト名だということがわかります。正引きまで検証しないと、逆引きだけでは誰のドメインでも名乗れてしまいます。
出口が分散されていて複数あるけど、それぞれにホスト名を持たないといけないのか、という話を時々聞きますが、複数のIPが同じホスト名を返したり、1つのホスト名が複数のIPアドレスを返しても問題ありません。
HELOドメインの正当性
これは、SPFで確認できます。
MAIL FROMが<>の場合に、こちらが使用されるのですが、書き忘れている環境がかなりあるようです。
gmailがこれを使用しているかは不明です。
MAIL FROMのドメインの正当性
こちらもSPFで確認できます。
ヘッダFromのドメインの正当性
これは、DKIMで確認できます。
また、ヘッダFromのドメインはSPFのドメインまたはDKIMの署名者のどちらかと一致する必要があります。推奨はSPF、DKIMの両方がヘッダFromのドメインと一致することです。
本来SPFのMAIL FROMドメインやDKIMの署名者はヘッダFromと一致する必要なく、これはDMARCの要件です。
DMARCはp=noneでいいよ、と言いつつ、実態はp=quarantineまたはreject相当というわけです。
経路の暗号化
START TLSで途中の通信経路が暗号化されていることで、中間者攻撃から守られます。
TLSのバージョンなどについては言及はありません。
これらが、正しく設定されていなければ、偽者の可能性があると判断され、迷惑メールとして扱われるということになります。
ただし、ここでいう「本物」というのは、あくまで送信元のドメインから送信された、ということです。送信元のドメインが本物か偽者かということではありません。
例えば、qiiiiiita.comからQiitaっぽいメールが来たとしても、qiiiiiita.comから来たことは保証されますが、本物のQiitaからのメールかどうかはわかりません。
購読解除
広告メールの購読解除ができなければ、受信者は迷惑メールとして報告をしてしまうので、gmailにスパム判定されてしまいます。
受信者にスパム報告されないためにも購読解除の仕組みが必要です。
購読解除の仕組みを用意することによって、読みたい人だけがメールを受け取るという世界になります。
具体的には、List-UnsubscribeヘッダとList-Unsubscribe-Postヘッダを記述します。
これで、「メーリングリストの登録解除」というボタンが表示されますので、必要のない受信者は迷惑メール報告ではなく購読を解除することになり、迷惑メールの報告はされないということになります。
また、仮に、迷惑メール報告をしたとしても、以下のように表示され登録解除に誘導されます。購読者は減りますが、迷惑メール報告の数が増えるわけではないので配信への影響はないわけです。
広告メールの配信者は、これからは登録解除されないような質の高いコンテンツが求められるのかも知れません。
送信者として今後やるべきこと
すでに大急ぎで対応した方も多くいると思いますが、方針としてはいくつか考えられます。
昨年10月に突然言い出されて困っている、という意見もあると思いますが、これらの技術はずいぶん前から存在しています。
SPFは2006年、DKIMは2007年、DMARCは2015年です。暗号化のSTART TLSは2002年です。
List-Unsubscribe-Postも2017年なので、すでに7年経過しています。
いきなり言い出したのではなく、機が熟したから必須にした、と考えた方がよさそうです。
ということで、基本的には
googleガイドラインに沿うような形でしっかり対応する
でしょう。
技術的なところ以外にも、購読解除されないようなコンテンツ作りも必要かも知れません。
ところで、gmailのガイドラインではDMARCのポリシーはnoneでも構わないことになっていますが、SPFやDKIMが必須であり、ヘッダFromとのアラインメントも必要なのであれば、実質p=rejectやquarantineと変わりません。
むしろ、SPF、DKIMの両方を推奨していることは、DMARCよりも厳しいルールだと言えます。
googleのガイドラインを満たせるのであれば、DMARCはp=rejectにしてしまいましょう。
その方がgmail以外の宛先に対してもなりすましされない対策になります。
しかし、一方で、中には対応が追いつかなかったのか、対応しない方針にしたのかわかりませんが、
gmail以外のメールアドレスで受信してもらう
という対応もあるようです。
しかし、gmail以外なら受け取ってもらえると考えるのは違うと思います。
偽者ではないと証明できていないわけなので、迷惑メールフォルダに入るかもしれないし、悪意のある偽者がなりすましてメールを送信するかも知れません。
なにより、gmail以外で受けてください、というアナウンスがあれば、これを見た悪意のある人は、このドメインはなりすませるんだな、と思うだけです。
また、迷惑メールフォルダに入ると困るから、という理由から、このメールアドレスを迷惑メールにならないようにホワイトリストに登録してください、というようなアナウンスをしたところもあったようです。
これは、絶対にやってはいけません。
このメールアドレスをなりすまして送っても、迷惑メールに分類されず、本物と区別なく届きますよ、と悪い人にわざわざ教えているようなものです。
受信サーバーとして今後やるべきこと
送信者が対策を進めれば送信元ドメインがなりすまされているかどうかがわかるようになります。
しかし、この情報を使うかどうかは受信サーバーしだいです。
gmailと同様になりすましの疑いのあるものは受信しないように制限すれば、受信者にはなりすましメールは届かなくなります。
制限しなければ、受信者には今まで通りなりすましメールが届きます。
もしかしたら、gmailにはなりすませないので、悪意のある人は制限をしていないところを狙ってくるかも知れません。そうなれば、今まで以上になりすましが増えることになるでしょう。
このような未来を予想してか、SoftbankはさっそくDMARC対応を表明してきました。
また、送信側がしっかり対応すれば、広告メールには登録解除の仕組みがついているはずです。
受信側のWebメールなどでは、List-Unsubscribe(-Post)ヘッダを利用した購読解除の仕組みを提供するのがユーザーのためになりますし、必要のないメールを受信しなくてもよくなります。
もしすべての送信者が対応したら
なりすましの存在しない世界です。
しかし、重要なのはなりすまされていないのは、あくまで送信元のドメインだということです。
このドメインが本物と似たようなドメインであれば、「本物と似たようなドメイン」から送信されたことは証明されますが、これが本物なのかどうかはわかりません。
本物の組織のドメインだということを受信者に伝えるには、本物の組織が本物のドメインはこれだ、と伝えるしかありません。
なんか、小泉進次郎みたいになってますが、これをロゴを表示することによって解決しようとする、BIMIという技術があります。
BIMIについてはこのあたりをご参照ください。
ロゴの表示には証明書が必要であり、証明書の取得には登録商標で確認します。
これには時間とお金がかかりますし、似たようなロゴを登録しようとしても、商標登録の段階ではじかれるので実質なりすませない、という考えです。
このような未来に向けて、送信者は正方形のロゴの商標登録とBIMIの準備を進めるのがいいでしょう。
また、受信側のWebメール等、BIMIのロゴを表示するように準備を進めるのがいいと思います。
BIMI以外にも、ドメインのレピュテーションなどで本物かどうかを判断するようになるかもしれません。
もうひとつ要素がありました。
すべての経路がSTART TLSで暗号化されている世界です。
START TLSを必須にする技術としてMTA-STSとDANEがあります。
現在はTLSが使えなければ、平文でやりとりする、という状態です。
gmailがTLSしていない通信を受け付けないことによって、すべての送信者がTLS対応できたら、すべての受信者は平文での通信を受け付けないようにしてもいいはずです。
逆に受信側としてはTLSに対応していなければ配送してもらえないようになるかもしれません。
そうなれば、すべての送信者は平文で送る必要がなくなり、すべてのSMTPがSTART TLSで暗号化されている世界がやってきます。
MTA-STSやDANEの普及の前に、このような独自の対策や制限でTLSが普及するのかも知れません。
実際、日本でも送信先がSTART TLSに対応していなければ、平文で送るのではなく、送信しないようにできるような製品をつくっているところがあります。PPAPとか言っているので先進性がないように見えるかも知れませんが、この点に関してはしっかり先を行ってると思います。
このサイトでは配送先がTLSに対応しているかどうかを確認できます。
さて、いくつか書きましたが、まだ未来の話だと後回しにしているとまた慌てるかも知れません。今からでも、まずは、DMARC p=noneではなく、DMARC p=rejectを書くところからはじめてはいかがでしょうか。
まとめ
2024年2月に強化され始めたgoogleの送信者ガイドラインが目指していると思われる背景について考察してみました。
これを踏まえて、将来どのような方向に向かっていくのか考察してみました。