Internet Infrastructure Review（IIR）Vol.62
2024年3月

2. フォーカス・リサーチ（1）

送信者レピュテーションの構築手法に関する研究

2.1 はじめに

今から20年前の2004年1月、グローバルで迷惑メール対策を議論するワーキング・グループであるMAAWG（Messaging Anti-Abuse Working Group）にIIJは参加しました。私は2004年4月の最初のFounding Meetingから参加し、その後も継続してメンバー会合であるGeneral Meetingに参加してきました。現在はM³AAWG^（注1）と名称を少し変更し、対象範囲も広げて活動しており、2024年2月に20周年となる60回目のGeneral Meetingが開催されました。

MAAWGでの当初の技術的な議論は、電子メールシステムの欠陥ともいうべきメール送信者が誰かを正確に把握できない問題に対する、送信ドメイン認証技術、特にSPF^（注2）やDKIM^（注3）に関する検討や普及が中心でした。その後も技術的な議論は継続し、DMARC^（注4）やARC^（注5）、BIMI^（注6）といった技術の仕様がM³AAWGメンバーを中心に作られてきました。これら送信ドメイン認証技術の議論では、当初から次のステップとして認証されたドメイン名を受け取るべき送信者であるかの判断、つまり送信者レピュテーションが必要になると考えられてきました。実際、SPFの最初の仕様RFC4408でもドメイン名のレピュテーションについて触れられており、最近でもGoogle社と米国Yahoo社が受信メールの対策強化として、メール送信側に送信ドメイン認証への対応を強く求めています。実際に、この受信施策強化の発表のあと、国内でもDMARCに対応するドメイン名が急増しました。IAjapanの客員研究員としてjpドメイン名の調査を行っていますが、2024年2月の時点で、メールに利用しているドメイン名の約1/4がDMARCレコードを設定しており、これは設定割合が約3倍増加したことを示しています。

IIJ技術研究所では、送信者レピュテーションの構築手法に関する研究を行っています。本稿は、情報処理学会の論文誌で発表した論文^（注7）を紹介するものです。論文では、送信者レピュテーションの構築手法とフィードバックループについて述べていますが、本稿ではそのうち送信者レピュテーション部分について紹介します。また本論文は、情報処理学会から特選論文として選定されました。

2.2 送信者レピュテーション

メールの送信元情報を用いて受け取りを判断する手法としては、送信元のIPアドレスを利用し、DNSの仕組みを利用して参照するDNSBL（DNS Block List）が長い間利用されてきました。送信元のIPアドレスは、メール送信者を特定する情報としては適切ではありませんが、メール送信者を示すメールアドレスは信頼できないことから、DNSBLが利用されてきました。これを送信ドメイン認証のSPFやDKIMの普及により、認証した信頼できる情報であるドメイン名を受け取り判断に利用しようというのが、ドメイン名の送信者レピュテーションです。

送信者レピュテーションでは、単に受け取るべきではない負の評価を持つドメイン名以外にも、受け取るべき正のドメイン名も考えられます。それらの評価をドメイン名ごとに数値化すれば、レピュテーションとなります。より単純にドメイン名のBlock ListとAllow Listと捉えることもできます。

送信ドメイン認証技術の普及と共に、独自にドメイン名を登録し、SPFやDKIMの設定を正しく行って送信する迷惑メールも多くなりました。こうした迷惑メールに利用するドメイン名は、使い捨て的に登録し利用されるため、Block Listのドメインレピュテーションを構築したとしても、その効果は残念ながら限定的です。それよりは、受け取るべきAllow Listを構築し、それによって判定できないメールをメールフィルタなどによってメール内容から判断するといった組み合わせ的な手法が効果的である可能性があります。特に現在は、以前に比べて迷惑メール自体の割合が減っていますので、大部分の受け取るべきメールを、より簡便な送信ドメイン認証と送信者レピュテーションによって判断することができれば、より多くの計算機資源をメール内容の判断に利用することもできるようになります。

本稿では、こうした背景から、特に受け取るべき正規のメールのドメイン名を収集し、レピュテーションとして構築する手法について述べます。

2.3 送信ドメイン認証技術の特徴

送信ドメイン認証技術のSPFやDKIMについては、例えば送信ドメイン認証技術導入マニュアル^（注8）などに詳しく述べられていますので、ここでは、送信者レピュテーションの構築手法に関わる部分について示します。

SPFは、メール配送プロトコル（SMTP）上のメール送信者としてのメールアドレスのドメイン名を認証します。認証の方法は、送信側が予めドメイン名のDNS上にSPFレコードとしてメールの送信元のIPアドレスなどを記載し、メール受信側がそれをメール受信時に参照し、正しい送信元からのメールであるかを判断します。この仕組みのため、SPFの送信側の導入は、DNSにSPFレコードを設定するだけなので比較的容易であり、普及も進んでいます。しかしながら、受信側にとって最初のメール送信者以外から送信された場合は、正しく認証できなくなるという課題があります。

DKIMは、送信するメールそれぞれに、メールヘッダと本文からなる電子署名を作成し、関連情報と共にメールヘッダとして記載します。メールの配送経路によらない認証方式を用いていることにより、SPFのような例えば転送されたメールが正しく認証できないなどの課題はありません。しかしながら、送信メールサーバに電子署名を作成しDKIMの署名情報を追加する処理を新たに付け加える必要があるため、SPFに比べて普及がそれほど進んでいないという課題があります。

2.4 送信者レピュテーションの構築手法

ここでは、送信ドメイン認証技術を用いて受け取るべきSPFの認証ドメイン名を収集する手法について述べます。一般的に、受け取るべきではない迷惑メールについては、メール自体が不要なものであるため、収集することは比較的容易です。収集した迷惑メールからその特徴や送信者情報を抽出することで、迷惑メールフィルタのための情報やブロックリストを収集することが行われてきました。その一方で受け取るべきメールについては、メッセージという機密性の高い情報が含まれるといった課題もあり、逆に収集が一般的に難しいという性質があります。また、受け取るべきという判断に利用しますので、誤って迷惑メールの送信元を登録してしまった場合の被害などの影響も大きく、登録に際しては正確性も要求されます。

ここでは、転送メールが受け取るべきメールであることを示し、その送信元を判断し収集する手法について述べます。

2.4.1 転送メールの性質

転送メールは、複数のメールアカウントを利用している場合で、それらを1ヵ所で参照したい場合など、メールを集約する手段として利用されたりします。メールシステムでは古くから利用されてきた仕組みであり、例えばオープンソースのSendmailなどでは、ホームディレクトリの.forwardファイルに転送先のメールアドレスを記述することで、受信したメールを自動的に転送してきました。つまり、転送元でメール転送設定しているのは、転送先のメール受信者であり、このことから転送先のメール受信者にとって、転送元のメール送信者は受け取るべきメール送信元であると言えます。

こうしたメール転送元を収集することができれば、受け取るべきメール送信元のレピュテーションを構築することができるはずです。

2.4.2 転送メールと送信ドメイン認証技術

一般的なメール転送では、SPFの認証ドメイン名であるエンベロープFrom^（注9）は、最初のメール送信者が設定したメールアドレスをそのまま利用します。この仕組みにより、転送先のメール受信側ではSPFの認証が失敗します。一方で、DKIMはメール送信元のIPアドレスを認証に利用しませんので、最初にDKIM署名を追加したメールは、転送先でもDKIM認証ができます。この結果を図-1に示します。図のSDID（Signing Domain Identifier）はDKIM認証での認証ドメイン名です。

また最近では、なりすましメール対策を強化する目的で、SPF認証できないメールを受け取らないメール受信側が増えました。そのため、メール転送時にエンベロープFromを転送元のドメイン名に書き換えて送信するような転送元も存在します。この場合、転送先ではSPF及びDKIMの両方の認証がpassします。しかしながら、それぞれの認証ドメイン名は通常異なります。この結果を図-2に示します。

拡大する

図-1 転送メールの送信ドメイン認証結果

拡大する

図-2 送信者情報を書き換える転送メールの送信ドメイン認証

2.4.3 送信ドメイン認証結果を利用した転送メール元の判断

転送メールの転送方法が2種類あること、それぞれでSPFとDKIMの認証結果が異なることを示しました。そこで、送信ドメイン認証の結果を利用して、転送メールかどうかを判断し、その転送メールの送信元をレピュテーションとして収集します。まず、転送時にRFC5321.Fromを書き換えない転送元は、以下の認証結果の条件から判断し、受け取るべきSPF認証ドメイン名を収集します。

• SPFの認証が失敗し、DKIMの認証がpassする送信元IPアドレス
• 上記のIPアドレスから送信され、SPFの認証がpassするSPF認証ドメイン名

最初の条件では、転送メールの送信元IPアドレスを収集します。送信メールサーバが複数ある場合もあるため、より広く正規のメール送信元を収集するために、その送信メールの管理元を得る目的で、転送メールの送信元IPアドレスから送信され、かつSPF認証がpassするSPF認証ドメイン名を収集します。これが2つ目の条件です。この転送元のIPアドレスと、そこから送信されるSPF認証ドメイン名の両方が、受け取るべき送信者レピュテーションとなります。このIPアドレスは、受け取るべき正規の送信元ですので、そこから送信されるメールで、転送メールではないメールも、受け取るべきメールと判断します。これにより、IPアドレスだけでなくSPFの認証ドメイン名を送信者レピュテーションとして利用できることになります。

次に転送時にエンベロープFromを書き換える転送元を、以下の条件から判断し、同様に受け取るべきSPF認証ドメイン名を収集します。

• SPFとDKIMの両方の認証がpassし、それぞれのドメイン名の関連がない送信元IPアドレス
• 上記のIPアドレスからDKIM認証し、そのDKIM認証ドメイン名が複数得られるメール送信元IPアドレス
• 上記IPアドレスから送信され、SPFの認証がpassするSPF認証ドメイン名

転送メールでなく、SPFとDKIMの両方に対応した送信メールは、通常それぞれのドメイン名が同じか上位ドメイン名が同じであるなど、関連が強いことが期待できます。例えばDMARCでは、組織ドメイン名を定義し、SPFかDKIMの認証ドメイン名とヘッダ上の送信ドメイン名が同じか、同じ組織ドメイン名を持つことを前提としています。こうした仕様もあり、通常のメールでもSPFとDKIMの認証ドメイン名は、高い関連性があります。最初のメール送信元がDKIM対応している場合、転送時にSPFの認証ドメイン名を書き換えると、最初のDKIM認証ドメイン名と転送先でのSPF認証ドメイン名は関連のないドメイン名となることが一般的です。メール転送時にエンベロープFromを書き換える転送元を判断するために、SPFとDKIMの認証ドメイン名の関連性に着目します。この送信元IPアドレスを機械的に収集するために、同じ送信元IPアドレスからのメールで、SPF認証がpassし、さらにDKIMの認証ドメイン名が複数得られるメール送信元のIPアドレスを、メール転送元と判断し収集します。このメール転送元IPアドレスと、そこから送信されたSPF認証ドメイン名が、受け取るべき送信者レピュテーションとなります。

2.5 送信者レピュテーションの構築と検証

これらの手法の有効性を確かめるために、実際に送信者レピュテーションを構築し、受信メールに対して適用します。利用したのは、実際のメールサービスで受信したメールの受信ログです。このメールサービスでは、メール受信時にSPFとDKIMの送信ドメイン認証を行い、更にすべてのメールに迷惑メールフィルタを適用していますので、それらの結果をログから得ることができます。送信者レピュテーションによる判定結果の評価基準として、この迷惑メールフィルタの判定結果を利用しました。

つまり、SPFとDKIMの認証結果から送信者レピュテーションを構築します。次に受信したメールを送信者レピュテーションに適用し、それが迷惑メールフィルタの結果と比較し、迷惑メールでないメール（ham）に該当したか、迷惑メール（spam） に該当したか、それぞれの数を計測します。

送信者レピュテーションは、2019年9月の1ヵ月間の受信メールのログ、約3億4千万通から構築しました。この時の迷惑メール（spam）割合は11.7%で、SPFの認証pass割合は71.1%、DKIM認証pass割合は38.1%でした。これらのデータから抽出できた転送元IPアドレスは15,169、通常の転送元から送信されたSPFドメイン名数は744,660、転送時に送信ドメイン名を書き換えるドメイン名数は11,164得られました。

これら抽出した受け取るべき送信者レピュテーションを、レピュテーションの収集期間の直後、2019年10月の1週間、約3千6百万通の受信メールに適用しました（表-1）。適用には、同じく受信メールのログを利用しました。2つのレピュテーションの違いを以下に示します。

1. （1）転送時に送信者情報を書き換えない通常の転送元（IP）とSPF認証ドメイン名
2. （2）（1）に転送時に送信者情報を書き換える送信元とSPF認証ドメイン名を追加

表-1のham（%）は、迷惑メールフィルタで迷惑メールと判定されなかったメールの中で、構築した送信者レピュテーションが適用できた割合。つまり真陽性（TP：True Positive）の割合を示しています。spam（%）は、迷惑メールフィルタで迷惑メールと判定されたメールで、送信者レピュテーションが適用されてしまった割合。つまり偽陽性（FP：False Positive）の割合を示しています。今回の評価は、例えばメールフィルタでの迷惑メール判定の場合の正の意味と異なり、受け取るべきメールが正となるため、レピュテーションとしての正解（TP）と誤判定（FP）の関係には注意が必要です。

拡大する

表-1 送信者レピュテーションの適用結果

2.6 考察

送信ドメイン認証技術を用いてメール転送元を判断し、それらを送信者レピュテーションとして構築することで、受け取るべきメール（ham）の約58%のメールを判断することができました。この時期、SPFの認証割合は7割程度であることから、そのうちのかなりの割合を送信者レピュテーションによって判定することができたと言えます。これは、転送時に送信者情報を書き換える転送元を検知し、それらを利用して送信者レピュテーションを追加できたことで、より効果を上げることができました。TP（真陽性）の割合を10pt以上高めることができています。それにもかかわらずFP（偽陽性）の割合は0.25ptだけの増加に抑えられています。送信者レピュテーションの適用期間では、受信メールに対するspam割合は約9%でしたので、誤判定したメールの実数としてはかなり低いものとなりました。また、このFPの原因についてもある程度は分かっていますので、よりFP割合を減らすことも可能と考えています。

本手法による送信者レピュテーションの構築手法は、メールの内容を参照して判断することなく、送信ドメイン認証技術の認証結果だけを利用しています。一般的なメールフィルタの手法と異なり、簡易的な手法であるにもかかわらず、高い精度の判定結果を得ることができました。転送メールの送信元判定についても、普及率が低いDKIMの認証結果を利用してはいますが、レピュテーション利用時に送信側がDKIMに必ず対応している必要はなく、転送元判定のために数通のDKIM認証されたメールだけを利用します。そのためDKIMの普及率が低くても、十分送信者レピュテーションを構築することができます。今回は送信者レピュテーションの構築及び適用対象として、普及率の高いSPFの認証ドメイン名を利用しましたが、SPFの普及率がより高くなれば、更に判定できるメールを増やすことも期待できます。DKIMあるいはDMARCの普及率が高くなれば、それらの認証ドメイン名も送信者レピュテーションとして利用することも考えていくことができると思います。

これまでメール転送によってSPFの認証が転送先で失敗してしまうことは、SPF認証の欠陥と考えられてきました。しかしながら、逆にこのネットワーク方式のSPFと電子署名方式のDKIMそれぞれの特徴を活用する、送信者レピュテーションの構築手法を本稿で示し、その高い評価結果を示すことができたことは、SPFの普及のためにも有益であると考えています。

2.7 おわりに

フィッシングなどの迷惑メールの内容がより高度化し、本物と見分けがつかなくなってきている現在では、信頼できる送信者情報を利用してメールの受け取りを判断できる本手法の意義は大きいと考えています。また、送信者レピュテーション構築手法として、メール内容を参照する必要がないことは、プライバシー保護の観点からも有益な手法といえます。更に本手法の検証時に示したように、例えば受信メールログを利用して送信者レピュテーションが構築できる手法であるということは、自組織で受信するメールに適した送信者レピュテーションが得られるということであり、より精度の高い判定も期待できます。本レピュテーションで適用できないごく少数の受信メールに対しては、より多くの計算機資源が利用できるようになるわけですので、それらを活用し、メール内容などから深く判断する、といったことも可能になります。

送信ドメイン認証技術は、これまで導入しなくてもメールが届くという状態が続き、特に比較的新しいDMARCなどの普及がなかなか進んできませんでした。しかしながら今回、Google社や米国Yahoo社などの新たな受信対策の発表により、DMARC およびそのベースとなるSPF、DKIMの普及が進んできたことは、なりすましメールの対策ができるようになったのと同時に、こうしたドメインレピュテーションが適用できる機会が増えることにもつながります。引き続き、より精度の高いドメインレピュテーションに関する研究を続けていきます。

1. （注1）Messaging, Malware and Mobile Anti-Abuse Working Group
2. （注2）Sender Policy Framework (SPF) for Authorizing Use of Domains in *Email, Version 1 (RFC7208)。
3. （注3）DomainKeys Identified Mail (DKIM) Signatures (RFC6376)。
4. （注4）Domain-based Message Authentication, Reporting, and Conformance (RFC7489)。
5. （注5）Authenticated Received Chain。
6. （注6）Brand Indicators for Message Identification (Internet-Draft)。
7. （注7）櫻庭秀次、他: 送信ドメイン認証を用いた送信者レピュテーションの構築手法とフィードバックループの提案, 情報処理学会論文誌, Vol.64, No.1, pp.13-23 (2023)。
8. （注8）日本データ通信協会迷惑メール相談センター、送信ドメイン認証技術導入マニュアル（https://www.dekyo.or.jp/soudan/aspc/report.html#dam）。
9. （注9）メール配送の規格（SMTP）上の送信者メールアドレスで、その規格番号からRFC5321.Fromと表現する場合があります。

2. フォーカス・リサーチ（1）
送信者レピュテーションの構築手法に関する研究

• 2.1 はじめに
• 2.2 送信者レピュテーション
• 2.3 送信ドメイン認証技術の特徴
• 2.4 送信者レピュテーションの構築手法
• 2.5 送信者レピュテーションの構築と検証
• 2.6 考察
• 2.7 おわりに