今日、ドコモが新たな迷惑メール対策を発表した。さる12/6にも、KDDIが同様の発表をしたばかり。
ドコモのニュースリリースでは具体的な技術案件は記載されていないが、おそらくKDDIと同じ「SPF(Sender Policy Framework)/Sender ID(Caller ID for E-Mail)」認証を行うのであろう。digでTXTレコードを調べてみたところ、SPFの記述があった。
「SPF/Sender ID」はメールの送信元ドメインについて、そのドメインのDNSを問い合わせることによって送信元ドメインの正当性を評価する仕組みである。メールプロトコルの仕組み上、いままでは簡単に送信元を詐称することが可能であったのでフィッシング詐欺など大きな問題となっていた。これが、「SPF/Sender ID」を導入することによってドメイン詐称の可能性を評価できるようになったため、偽装したスパムやフィッシングメールは受信そのものを拒否し、ブラックリストへの登録によって第三者に騙られたドメインが誤ってブラックリストに登録されてしまうのを防ぐこともできる。
まだ一般的とまでには普及していない「SPF/Sender ID」認証だが、いままでのインターネットメールの仕組みでは難しかったスパムメールの抑制効果が期待されている。現時点で上記のドコモ、KDDI以外にもAOL、Gmail、IIJなど続々と対応が始まっている。
SPFとSender IDの違いだが、SPFは「Envelope-From」を確認するのに対し、Sender IDは「From:→Sender:→Resent-From:→Resent-Sender:」の優先順位でヘッダを順に評価する。メールがバウンスしたときMTAは「Envelope-From」へメールの差し戻しを試みるので、SPFのほうが扱いとして正しい気がする。現時点での普及度では、「Sender ID」でマイクロソフトがライセンスがらみで一悶着あったらしく「SPF」のほうがより導入度が高いと言えそうである。
そこで、当サイトでも「SPF/Sender ID」がもたらす「なりすましメールの根絶」の効果と、具体的にどのように設定を行えばいいのかを検証してみよう。当サイトではDNSにはbind、MTAにqmailを使用しているので、bind + qmail + SPF の構成を構築する。
「SPF/Sender ID」は送信側と受信側でそれぞれ独立した設定が必要であるが、両方行わずとも大きなメリットがある。
送信側で「SPF/Sender ID」に対応すれば、スパマーに自分が所有している大切なドメインを騙られてスパムを送らてしまうことを防ぐことができるし(厳密には、受信側で対応されてないとスパムは届いてしまうことになるが、最低限責任を果たしているといえるだろう)、受信側で対応すれば、無駄なメールを受信すらしないこともできる。
今回は、送信側の設定として上記のサイトのように、DNSゾーンに「SPF/Sender ID」対応レコードを追加してみよう。
ドコモのニュースリリースでは具体的な技術案件は記載されていないが、おそらくKDDIと同じ「SPF(Sender Policy Framework)/Sender ID(Caller ID for E-Mail)」認証を行うのであろう。digでTXTレコードを調べてみたところ、SPFの記述があった。
$ dig TXT ezweb.ne.jp
;; ANSWER SECTION:
ezweb.ne.jp. 1249 IN TXT "v=spf1 include:spf-im1.ezweb.ne.jp include:spf-im2.ezweb.ne.jp include:spf-im3.ezweb.ne.jp include:spf-im4.ezweb.ne.jp include:spf-im5.ezweb.ne.jp include:spf-im6.ezweb.ne.jp include:spf-nm.ezweb.ne.jp include:spf-az.ezweb.ne.jp ~all"
$ dig TXT docomo.ne.jp
;; ANSWER SECTION:
docomo.ne.jp. 83965 IN TXT "v=spf1 +ip4:203.138.203.0/24 ~all"
「SPF/Sender ID」はメールの送信元ドメインについて、そのドメインのDNSを問い合わせることによって送信元ドメインの正当性を評価する仕組みである。メールプロトコルの仕組み上、いままでは簡単に送信元を詐称することが可能であったのでフィッシング詐欺など大きな問題となっていた。これが、「SPF/Sender ID」を導入することによってドメイン詐称の可能性を評価できるようになったため、偽装したスパムやフィッシングメールは受信そのものを拒否し、ブラックリストへの登録によって第三者に騙られたドメインが誤ってブラックリストに登録されてしまうのを防ぐこともできる。
まだ一般的とまでには普及していない「SPF/Sender ID」認証だが、いままでのインターネットメールの仕組みでは難しかったスパムメールの抑制効果が期待されている。現時点で上記のドコモ、KDDI以外にもAOL、Gmail、IIJなど続々と対応が始まっている。
SPFとSender IDの違いだが、SPFは「Envelope-From」を確認するのに対し、Sender IDは「From:→Sender:→Resent-From:→Resent-Sender:」の優先順位でヘッダを順に評価する。メールがバウンスしたときMTAは「Envelope-From」へメールの差し戻しを試みるので、SPFのほうが扱いとして正しい気がする。現時点での普及度では、「Sender ID」でマイクロソフトがライセンスがらみで一悶着あったらしく「SPF」のほうがより導入度が高いと言えそうである。
そこで、当サイトでも「SPF/Sender ID」がもたらす「なりすましメールの根絶」の効果と、具体的にどのように設定を行えばいいのかを検証してみよう。当サイトではDNSにはbind、MTAにqmailを使用しているので、bind + qmail + SPF の構成を構築する。
「SPF/Sender ID」は送信側と受信側でそれぞれ独立した設定が必要であるが、両方行わずとも大きなメリットがある。
送信側で「SPF/Sender ID」に対応すれば、スパマーに自分が所有している大切なドメインを騙られてスパムを送らてしまうことを防ぐことができるし(厳密には、受信側で対応されてないとスパムは届いてしまうことになるが、最低限責任を果たしているといえるだろう)、受信側で対応すれば、無駄なメールを受信すらしないこともできる。
今回は、送信側の設定として上記のサイトのように、DNSゾーンに「SPF/Sender ID」対応レコードを追加してみよう。
「SPF/Sender ID」対応レコードはTXTレコードの拡張記述となっている。
「v=spf1」で始まるSPFバージョンに続き、複数の判定条件をクオリファイヤ(+,-,?,~)とメカニズムと呼ばれる条件式で連結して記述する。たとえば、以下の例だと
ドメイン「example.jp」は「1.2.3.4/24」のネットワークから「のみ」メールを送信するが、「例外もありえる」となる。
複数のネットワークから送信するのであれば都度「ip4:～」を追記すればいいし、記述した条件にマッチしない場合は拒否して欲しい場合には「-all」とする。「Include:」メカニズムを使用すれば、別のドメインの設定を継承することもできる(当然、DNSクエリは余分に発生することになる)。
詳細は、＠IT：Sender ID：送信者側の設定作業 あたりを眺めてみてもらうとして、基本的な記述方法を理解したら自動的にSPFレコードを生成できるツールを使用してみてもいいだろう。SPF公式サイト から「SPF WIZARD」メニューに設定したいドメインを入力して、条件を選択していくだけでとても簡単に設定することができる。
設定が完了したら、check-auth＠verifier.port25.com (@は大文字にしてあります)にテストメールを送ってみよう。正規の送信元であれば「pass」、会社やプロバイダ経由など条件にマッチしないメールサーバから「softfail」または「fail」の結果が返ってくればＯＫ。設定そのものが無効であれば「neutral」となる。
「v=spf1」で始まるSPFバージョンに続き、複数の判定条件をクオリファイヤ(+,-,?,~)とメカニズムと呼ばれる条件式で連結して記述する。たとえば、以下の例だと
example.jp. IN TXT "v=spf1 ip4:1.2.3.4/24 ~all"
ドメイン「example.jp」は「1.2.3.4/24」のネットワークから「のみ」メールを送信するが、「例外もありえる」となる。
複数のネットワークから送信するのであれば都度「ip4:～」を追記すればいいし、記述した条件にマッチしない場合は拒否して欲しい場合には「-all」とする。「Include:」メカニズムを使用すれば、別のドメインの設定を継承することもできる(当然、DNSクエリは余分に発生することになる)。
詳細は、＠IT：Sender ID：送信者側の設定作業 あたりを眺めてみてもらうとして、基本的な記述方法を理解したら自動的にSPFレコードを生成できるツールを使用してみてもいいだろう。SPF公式サイト から「SPF WIZARD」メニューに設定したいドメインを入力して、条件を選択していくだけでとても簡単に設定することができる。
設定が完了したら、check-auth＠verifier.port25.com (@は大文字にしてあります)にテストメールを送ってみよう。正規の送信元であれば「pass」、会社やプロバイダ経由など条件にマッチしないメールサーバから「softfail」または「fail」の結果が返ってくればＯＫ。設定そのものが無効であれば「neutral」となる。
コメントする