- 追加された行はこの色です。
- 削除された行はこの色です。
[[FrontPage]]
#contents
Feb 23 19:04:32 hotshot postfix/smtpd[51818]: connect from softbank220019170142.bbtec.net[220.19.170.142]
Feb 23 19:04:32 hotshot postfix/smtpd[51818]: NOQUEUE: reject: RCPT from softbank220019170142.bbtec.net[220.19.170.142]: 450 4.7.1 <softbank220019170142.bbtec.net[220.19.170.142]>: Client host rejected: S25R check, be patient; from=<sugimoto@soundstep.co.jp> to=<sugiharagakki@gmail.com> proto=ESMTP helo=<[192.168.3.4]>
Feb 23 19:04:32 hotshot postfix/smtpd[51818]: disconnect from softbank220019170142.bbtec.net[220.19.170.142]
Feb 23 19:07:48 hotshot postfix/smtpd[51827]: connect from softbank220019170142.bbtec.net[220.19.170.142]
Feb 23 19:07:48 hotshot postfix/smtpd[51827]: NOQUEUE: reject: RCPT from softbank220019170142.bbtec.net[220.19.170.142]: 450 4.7.1 <softbank220019170142.bbtec.net[220.19.170.142]>: Client host rejected: S25R check, be patient; from=<sugimoto@soundstep.co.jp> to=<sugiharagakki@gmail.com> proto=ESMTP helo=<[192.168.3.4]>
Feb 23 19:07:48 hotshot postfix/smtpd[51827]: disconnect from softbank220019170142.bbtec.net[220.19.170.142]
http://www.gabacho-net.jp/anti-spam/anti-spam-system.html
あらまし
オープンリレー（第三者中継）を行うメールサーバが少なくなり、最近では多くのスパマーが、ADSLやケーブルネットワークなどのエンドユーザー用高速回線につながってボットに感染したたくさんのエンドユーザーコンピュータからスパムを直接ばらまいている。オープンリレーブラックリストはもはや役に立っていない。有効なスパム対策は、メール中継サーバからのSMTPアクセスを受け入れる一方で、エンドユーザー用回線からのSMTPアクセスを拒絶することである。それらは、IPアドレスの逆引き名の特徴に基づいて識別できる。私はこの方式を使って、Postfix以外に何らの付加ソフトウェアも使うことなく、スパムとウィルスメールを合わせた不正メールの約99%を阻止することに成功している。
*warning: do not list domain [FQDN] in BOTH virtual_alias_domains and relay_domains [#de89866e]
+従来のスパム対策
従来、次のようなスパム対策が工夫されてきたが、いずれもスパマーによって破られている。
送信者ドメインの検査
スパマーは、苦情の返信を避けるために、偽の送信者アドレスをかたることが多い。そこで、メッセージの送信者ドメインが実在しなければ拒否するという対策をとっているメールシステムがある。しかしスパマーは、罪のない他人の実在ドメインを悪用するという方法でこの防御を破っている。もちろん、罪のないドメインにスパムの差し戻しが殺到する。大迷惑である。
http://blog.livedoor.jp/itc_tommy/archives/474617.html
~特定のサブドメイン宛のメールを全て一つのエイリアスで受信してスクリプトを起動するって処理がやりたくて、POSTFIXの設定を色々いじっていました。バーチャルドメインの設定をして、virtual_alias_domainsにサブドメインを登録して、virtual_alias_mapsでドメインと転送先アドレスを指定してあげればいい、ここまでは簡単。
~実際にテストしてみるとちゃんと目的のエイリアスにメールが転送されています。が、ログに表題のワーニングが。virtual_alias_domainsにドメインを書くな？ここに書かなきゃ受信できないんじゃないの？
~ぐぐってみると、parent_domain_matches_subdomainsってパラメータが関係しているらしい。これは、$mydomainのサブドメインの受信をする/しないを決定するパラメータだそうだ。デフォルト値では、$mydomainのサブドメインは全て受信する設定がされているらしい。この結果、virtual_alias_domainsと設定が重複してしまって、このワーニングが出るって事じゃないのかな。
~virtual_alias_domainsの設定を外してみると、ワーニングが出なくなりました。これにて解決。
内容の検査
特定の語（たとえば「make money」）を含むメッセージを拒否するという対策がある。しかしスパマーは、語を変形させたり（「m-a-k-e m-o-n-e-y」のように）、無効なHTMLタグを語の中に挿入したり、本文全体をBASE64に符号化したりすることによって、この防御を破っている。
hotshot# whois soundstep.comp
whois: comp.whois-servers.net: hostname nor servname provided, or not known
hotshot# whois soundstep.co.jp
[ JPRS database provides information on network administration. Its use is ]
[ restricted to network administration purposes. For further information, ]
[ use 'whois -h whois.jprs.jp help'. To suppress Japanese output, add'/e' ]
[ at the end of command, e.g. 'whois -h whois.jprs.jp xxx/e'. ]
Domain Information: [ドメイン情報]
a. [ドメイン名] SOUNDSTEP.CO.JP
e. [そしきめい] ゆうげんがいしゃ さうんどすてっぷ
f. [組織名] 有限会社サウンドステップ
g. [Organization] Soundstep Co.,Ltd.
k. [組織種別] 有限会社
l. [Organization Type] Corporation
m. [登録担当者] SS3491JP
n. [技術連絡担当者] KS5785JP
p. [ネームサーバ] ns1.soundstep.co.jp
p. [ネームサーバ] ns2.soundstep.co.jp
s. [署名鍵]
[状態] Connected (2012/07/31)
[登録年月日] 2000/07/05
[接続年月日] 2000/10/04
[最終更新] 2011/08/01 01:04:54 (JST)
hotshot# dig mx SOUNDSTEP.CO.JP
; <<>> DiG 9.8.1-P1 <<>> mx SOUNDSTEP.CO.JP
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54646
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
;; QUESTION SECTION:
;SOUNDSTEP.CO.JP. IN MX
;; ANSWER SECTION:
SOUNDSTEP.CO.JP. 86400 IN MX 10 mail.smb.net.
;; AUTHORITY SECTION:
SOUNDSTEP.CO.JP. 86400 IN NS ns2.SOUNDSTEP.CO.JP.
SOUNDSTEP.CO.JP. 86400 IN NS ns1.SOUNDSTEP.CO.JP.
;; Query time: 1 msec
;; SERVER: 219.117.246.198#53(219.117.246.198)
;; WHEN: Fri Feb 24 14:59:19 2012
;; MSG SIZE rcvd: 97
オープンリレーの禁止
スパマーは、多量のスパムをばらまくために、インターネット上のメールサーバによるオープンリレーを悪用した。そこで、メールサーバでオープンリレーを禁止する対策が普及した。また、いくつかの組織がオープンリレーブラックリスト（ORBL）を提供して、そのデータベースに登録されたメール中継サーバからの受信を拒否するよう勧めている。しかし、ADSLやケーブルネットワークなどのエンドユーザー用高速回線が普及してからは、スパマーは、ボットに感染させたたくさんのエンドユーザーコンピュータを操ることによって、オープンリレーに頼ることなく多量のスパムを受信者のドメインへ直接ばらまいている。
このようなエンドユーザー用回線からスパムを受けて、そのIPアドレスをORBLサイトに入力すると、「それはオープンリレーサーバではない」という答えが返る。悪質なスパム送信コンピュータはSMTPアクセスを発するだけで受けようとはしないので、オープンリレーを行わないのは当然である。セキュリティの知識も悪意もないメールシステム管理者を摘発するORBLは、真の悪人には寛容と見える。やれやれ…。
hotshot#
クライアントのIPアドレスまたはドメイン名の検査
SMTPアクセスをかけてくるクライアントのIPアドレスを検査するという方法もある。しかし、一つのIPアドレスをブラックリストに登録しても、スパマーはすぐに別のIPアドレスからスパムを送り込んでくる。かくしてブラックリストは際限なく肥大化する。
IPアドレスブロック（「223.45.67.*」のような）、または逆引きで得られたドメイン名（「*.example.com」のような）をブラックリストに登録することもできる。しかし、正当なメールが巻き添えを食らって阻止されてしまうかもしれない。
結局、メールシステム管理者は、メール爆弾を受けた時以外にはこの方法を使いたいとは思わないだろう。私のアイデアまであと一歩なのだが…。
+ S25Rスパム対策方式のコンセプト
私が考案したSelective SMTP Rejection (S25R)スパム対策方式のコンセプトは、メールサーバがメール中継サーバからのSMTPアクセスは受け入れるがエンドユーザーコンピュータからの直接のSMTPアクセスは拒絶するという単純なものである。
正当なメールのほとんどは、ISP（インターネットサービスプロバイダ）や組織のメール中継サーバを経由して送られてくる。一方、昨今のスパムのほとんどは、ADSLやケーブルネットワークなどのエンドユーザー用回線につながってボットに感染したエンドユーザーコンピュータから直接送られてくる。メール中継サーバを経由して送られてくるスパムは、比較的少なく抑えられる。サーバの処理能力がボトルネックになるからである。
また、昨今のウィルスには、自前のSMTPエンジンを持って、エンドユーザーコンピュータから自分の分身を宛先ドメインへ直接ばらまくものが多い。メール中継サーバを経由して送られるウィルスは、もしメール中継サーバがウィルス対策ゲートウェイを持てばそこで阻止される。
これらのことから、メール中継サーバからのメールだけを受け取るというポリシーによって、スパムやウィルスメールの受信を減らすことができる。
SMTPアクセスをかけてきたクライアントがメール中継サーバかエンドユーザーコンピュータかを判別することは非常に難しいと思えるかもしれない。しかし私は、意外なほど簡単な方法を思い付いた。次節に述べるように、IPアドレスの逆引きで得られるFQDN（Fully Qualified Domain Name：完全修飾ドメイン名）の特徴を見るのである。それは、Postfixを使って容易に実現できる。
この判別は、外からのメールの入り口であるMX（Mail eXchanger）の役割を担うメールサーバが行うのがよい。すなわち、MXは、メッセージを検査する前に受け取ってしまうのでなく、スパムの疑いのあるメッセージを拒絶するのがよい。スパマーのコンピュータは、メッセージ内容を伝送する前に、失敗の意味の応答コードを突き返される。したがって、インターネット上の無駄なトラフィックが減る。また、ドメイン名を偽の送信者アドレスに悪用された被害者に殺到する不正な差し戻しも少なくなる。一方で、拒絶の際に「後で再試行せよ」の意味の応答コードを返すことにより、誤って阻止される正当なメール中継サーバを見つけてそれを救済することができる。もしこのスパム対策方式がインターネットに普及したら、スパマーは、スパムの配信が片っ端から失敗することを思い知るだろう。
+ クライアント制限の規則
SMTPアクセスをかけてきたクライアントのFQDNの特徴に基づいて、クライアントがメール中継サーバか、エンドユーザー回線につながったコンピュータかを推定することができる。この方法でクライアントを制限するための規則は、一般規則、ブラックリスト、およびホワイトリスト（許可リスト）から成る。一般規則は、大多数のエンドユーザー用回線を引っかける。ブラックリストは、一般規則に引っかからないエンドユーザー用回線を引っかける。また、悪質なメール送信サーバも引っかける。ホワイトリストは、一般規則またはブラックリストによる誤った拒絶から正当なメール中継サーバを救済する。これは完璧な方法ではありえないが、きわめて有効な方法である。
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
