SPF Pass になる spam

SPF(Sender Policy Framework)とは、メールを送出した MTA(Mail Transfer Agent/メールサーバ) が正当な MTA であることを証明するための仕組みです。平たく言うと、「ウチのドメインからメールを送る場合、この IP アドレスを持ったメールサーバを使います」って世界に公言するって感じです。(ウチのサイトでも SPF 設定方法を解説していたりします)

ドメイン管理者が正当な MTA を宣言しているので、送られてきたメールが、正当なものであるかを確認することができます｡つまり､SPF は spam(迷惑メール)の判定材料の一つとして使うことが出来るってワケです。(spam 判定をSPF だけに依存するのは無理がありますけどね)

最近、SPF Pass になっている spam が結構な数あるので、どうしてなのか原因を調査してみました。

英語の spam

まずは、メールヘッダーを見ましょう

Return-Path: <sherif5756tzi@afrotribe.com>
Received: from cardinalcherry.com (66.pool85-53-13.dynamic.orange.es [85.53.13.66])
by xxx.xxx.xxx.jp (1.85P) with ESMTP id uksvKwHJu6uJS4lRq6oUPN8BXLB9X37G
for <xxx@xxx.xxx.xxx.jp>; Fri, 11 Jun 2010 03:35:02 +0900
Message-ID: <3f5a01cb08ca$4d467d11$e410745f@afrotribe.com>
From: "Alisander Ball" <sherif5756tzi@afrotribe.com>
To: <xxx@xxx.xxx.xxx.jp>
Subject: foregoes desegregated Ogden
Date: Thu, 10 Jun 2010 20:35:02 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0023_6C_01CB08CF.D7113152"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-FGSPAM-SMTP:
Sender: <sherif5756tzi@afrotribe.com>
X-SPF: PASS (sherif5756tzi@afrotribe.com)
X-FGSPAM-POP:

接続してきている MTA(メールサーバ)が、66.pool85-53-13.dynamic.orange.es といきなり動的 IP アドレス空間からなので、典型的な spam ですね。

では、どうしてこれが SPF Pass になるのか、確認してみましょう。

C:>nslookup -q=txt afrotribe.com
サーバー: dc01.vwnet.jp
Address: fd75:f582:7ae3::1

afrotribe.com text =

"v=spf1 +all"

うはは、+all (全ての IP アドレスから送信する)になっていますね。そりゃ動的 IP アドレス空間から送っても SPF Pass になっちゃうワケです。
多分 SPF 設定ミスでしょう。SPF では、送出するメールサーバを + で表現して、それ以外はあり得ない(-all　~all等)と設定するのですが、こいつをミスしているのが spamer にバレて悪用されているのでしょう。

日本語の spam

続いて、日本語の場合です。これは少し手が込んでいます｡

Return-Path: <komu@bg03.clarith.info>
Received: from bg03.clarith.info (112.90.147.74 [112.90.147.74])
by xxx.xxx.xxx.jp (1.85P) with ESMTP id N86kuAMX26q4s7ep6ud685urP9wyu0jU
for <xxx@xxx.xxx.xxx.jp>; Sun, 13 Jun 2010 22:17:22 +0900
Subject: =?ISO-2022-JP?B?gZqBmoNvhKCDQ4Sgg0GEoINPhKCDiYGagZqR44j4gquUzJSEgUWRppP6lK2Rlw==?=
From: "--VIAGRA代引即日発送--" <ppol@bg03.clarith.info>
To: xxx@xxx.xxx.xxx.jp
Message-ID: 20100613221650
Content-Type: text/html; charset="SHIFT_JIS"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
Date: Sun, 13 Jun 2010 22:17:09 +0900 (JST)
X-FGSPAM-SMTP:
Sender: <komu@bg03.clarith.info>
X-SPF: PASS (komu@bg03.clarith.info)
X-FGSPAM-POP:

それでは、接続してきた MTA を確認しましょう。

C:\>nslookup bg03.clarith.info
サーバー: dc01.vwnet.jp
Address: fd75:f582:7ae3::1

名前: bg03.clarith.info
Address: 112.90.147.74

C:\>nslookup 112.90.147.74
サーバー: dc01.vwnet.jp
Address: fd75:f582:7ae3::1

*** dc01.vwnet.jp が 112.90.147.74 を見つけられません: Non-existent domain

正引きは出来ますが、逆引きはできませんね。見るからに怪しいです。SPF を確認してみましょう

C:\>nslookup -q=txt bg03.clarith.info
サーバー: dc01.vwnet.jp
Address: fd75:f582:7ae3::1

bg03.clarith.info text =

"v=spf1 ip4:112.90.147.74 ~all"

ほう、ちゃんと SPF 登録されていますね。この設定なら SPF Pass になるのは当然です。では、どうしてこのようなことが起きるのか、dig (Windows 標準コマンドではないので、サードパーティ製をダウンロードする必要があります)で名前解決をトレースしてみましょう。

D:\dig>dig @dc01 bg03.clarith.info txt +trace

; <<>> DiG 9.3.2 <<>> @dc01 bg03.clarith.info txt +trace
; (1 server found)
;; global options: printcmd
. 3600 IN NS l.root-servers.net.
. 3600 IN NS k.root-servers.net.
. 3600 IN NS j.root-servers.net.
. 3600 IN NS i.root-servers.net.
. 3600 IN NS h.root-servers.net.
. 3600 IN NS g.root-servers.net.
. 3600 IN NS f.root-servers.net.
. 3600 IN NS e.root-servers.net.
. 3600 IN NS d.root-servers.net.
. 3600 IN NS c.root-servers.net.
. 3600 IN NS b.root-servers.net.
. 3600 IN NS a.root-servers.net.
. 3600 IN NS m.root-servers.net.
;; Received 449 bytes from 192.168.33.1#53(192.168.33.1) in 4 ms

info. 172800 IN NS a0.info.afilias-nst.info.
info. 172800 IN NS a2.info.afilias-nst.info.
info. 172800 IN NS b0.info.afilias-nst.org.
info. 172800 IN NS b2.info.afilias-nst.org.
info. 172800 IN NS c0.info.afilias-nst.info.
info. 172800 IN NS d0.info.afilias-nst.org.
;; Received 442 bytes from 199.7.83.42#53(l.root-servers.net) in 123 ms

clarith.info. 86400 IN NS 02.dnsv.jp.
clarith.info. 86400 IN NS 01.dnsv.jp.
;; Received 76 bytes from 199.254.31.1#53(a0.info.afilias-nst.info) in 203 ms

bg03.clarith.info. 300 IN TXT "v=spf1 ip4:112.90.147.74 ~all"
clarith.info. 300 IN NS 01.dnsv.jp.
clarith.info. 300 IN NS 02.dnsv.jp.
;; Received 118 bytes from 61.127.54.31#53(02.dnsv.jp) in 13 ms

01.dnsv.jp. と 02.dnsv.jp. が SPF を返事していますね。
と言う事は、以下の手口で SPF Pass になる spam を送出していると推測されます。

レジストラでドメイン取って、レジストラの DNS で運用
そいつに対してサブドメインを作って、Aレコード(国外IP)を同一名で登録し、SPF を設定

ひょっとしてと思って、spam 送信している IP に対して UDP/53 で接続すると反応があり、キャッシュサーバとして機能していました。このため、上位の DNS セットしている SPF を返事しています。
ひょっとすると、レジストラが SPF を消したら、こっちに SPF 設定する気なのかもですね。

whois でドメイン情報を見ると、登録者情報が見えますが、登録情報の真偽は不明です。

それにしても、spamer はあの手この手といろいろ考えてくれますね。

この件を dnsv.jp を管理している GMO インターネット(お名前.comの運営会社)に問い合わせたら、以下の回答がありました。(引用許可済み)

> 上記ドメインに関しましては、弊社にて取得されたドメインとなり
> ますが、運用を弊社外サーバーにて行っている状況でございました。
>
> そのため、弊社対応では送信を抑止することが困難な状態でござい
> ます。お手数ではございますが、ヘッダー情報などから確認できま
> す送信者側の利用されている接続サービス会社、もしくはWhois情報
> より確認できますドメイン管理者様宛にお問い合わせくださいます
> ようお願い申しあげます。

現状ではレジストラの対処は期待できないようです。