モーグルとカバとパウダーの日記 このページをアンテナに追加 RSSフィード Twitter

モーグルやカバ(EXカービングスキー)、山スキー(BC)の山行記録などがメインの日記です。
いろんな条件のいろんなところを、その時々の条件にあった滑り方で楽しむ、フリースキーをして遊んでいます。

検索で来られた方は、上の検索窓から再度検索していただくか、右サイドバーのカテゴリーやトピックスの項目で絞り込んでみてください。
仕事柄、コンピュータ系のネタも多いので、スキー関連ネタだけ読みたい方は[ski]、コンピュータ関連ネタは[pc]、スパム関連ネタは[spam]で絞り込んでください。

2006-10-23 (Mon)

[][]Spamhausに登録される Spamhausに登録されるを含むブックマーク Spamhausに登録されるのブックマークコメント

なんかメールサーバからへんなエラーログが出てるので調べてみると、sbl.spamhaus.orgに登録されていました。

でもうちのメールサーバからスパムなんて出てないのに… と見てみると、他の近隣IPから出てて、うちも含むIPが/22というレンジで登録されてましたよ orz

ちょっと/22はねえだろ、とか思ったんですが、DNSBLってみなこんな感じなのかねえ。


で、速攻メールを送りつけてみたところ、あんたのIPさくらインターネットの管轄だからそっちに言ってね、と言われました。この返事はほんとすばやくて、そのへんSpamhausは信頼できるなと思いました。

なんでもさくらインターネットの管轄では結構多数のIPアドレス帯がSpamhausに登録されてるそうで、わざわざその確認用URLもつけて返ってきました。

http://www.spamhaus.org/sbl/listings.lasso?isp=sakura.ad.jp


うーむ… これは確かに文句も言いたくなるかも。

なので、さくらインターネットにも早速メールを書きましたが、どういう対応してくれるだろうか。


(追記)

次の日にはちゃんと対応いただいて、Spamhausからも解除されました。よかった。

しかし、他のものについては解除されてないのだけど、そこはやるつもりなしなのかしらん?

まあ、他の人(IP)のことまでしったこっちゃないので、なんともできませんが。

gmaxlabgmaxlab 2006/10/24 10:11 恐い恐い....
さくらの対応がどうなるか興味津津です。

ISPの中の人ってあれこれ対応に追われてて細かい事象まではいちいち構ってられないのかもしれないですね。
しかし、セキュリティの甘いサーバやらSPAM温床を放置するような安価なホスティングってのは社会的に存在を容認しちゃいけないとも思います....自分ちが守りをかためても一緒くたにSBLに登録されたんじゃ目も当てられない。

stealthinustealthinu 2006/10/24 10:57 どうなりますかねえ。
sakura.ne.jpの共有サーバでは、結構そのへん対応してくれないらしく、スパム送信の温床になってて、DNSBLへの登録や、TLECのSAルールに書かれてたりしてるみたいなんで。

stealthinustealthinu 2006/10/24 16:51 対応いただきました。思ってたよりは素早い対応でした。
しかし、他のIP帯はどうなのよ?と思いましたが、ユーザからの苦情がない限り動かない、というポリシーでやってるんでしょうかね。

deodeo 2006/10/24 21:11 すみません、教えてください。DNSBL使う人って、蹴る時に返すのは「4xx」なんでしょうか。

stealthinustealthinu 2006/10/24 21:48 自分とこのサーバが蹴られたときは5xxでした。
DNSBLにマッチしてたらrejectと決め打ちなら、別に再送して欲しくないでしょうから、5xxの実装なんじゃないかと。

deodeo 2006/10/24 22:22 ありがとございます。へえ、そこまで他人のデータベースを信用しちゃっているんですか。

stealthinustealthinu 2006/10/24 23:36 意外にDNSBLの誤検出の危険性は、あまり認識されてないように思います。
そこそこ大手さんところでも、DNSBLだけでrejectしてるところたまに見かけますので。
実はS25Rでも、そのあたりを良くわかってないで運用してるサーバがあって、つまり管理者がログをちゃんと確認してないため、ときどきトラブルが発生してる場合があるようです。
なんらかのフィルタ掛ける以上、必ず誤検出が発生する恐れがあるということの啓蒙が必要かと思ってます。

deodeo 2006/10/25 22:57 S25Rをちゃんと理解せずに導入するのも困りますね。そのトラブルはどこで知ったのですか?

stealthinustealthinu 2006/10/25 23:51 えーと、実は自分自身が体験した中でもありまして。
仕事の関係で、先方にメールが届かないという相談を受けて、エラーメールを見せてもらったところ、どっかで見たことのあるメッセージが (^^;
そこは、フレッツの固定IP接続で逆引き設定なしで、自社メールサーバ立ててるところでした。
自分の場合はそれで速攻わかったのですが、そういう場合に、エラーメッセージをぐぐって、それで相手がどういうフィルタ掛けてるのかわかるようです。
なので”may not be mail exchanger”で検索すると、それで悩んでる人の例を見つけることが出来ます。
ちなみにそれでU社関連ドメインのサーバが使ってることがわかります。実は自分の例もそこです。

deodeo 2006/10/26 01:03 ありがとございます。こりゃひどいや。私が示した設定をコピりながら、応答コードを「550」に改ざんしている人がいるみたい。発案者としてこれは許せないっす。ブログに書くことにします。

stealthinustealthinu 2006/10/26 01:26 あ、気がつかなかったです。ほんとだ、550にしてあるし (^^;
これだと再送もされないから、多数メールを受けてるサーバでは、ログ洗って拾い出すのもちょっと無理でしょうね。
ちなみにそこ、abuse宛とかpostmaster宛も掛かるようになってるようで、メールでは苦情も出せないという…

gmaxlabgmaxlab 2006/10/26 14:33 さくら無事対応ですか。良かったですね。

言われて自分の管理してるメールサーバのログを改めてさらい直しました。3日で1950件の純粋なspamが弾かれてただけでした。それにしてもS25Rなかったらこんだけ食らってた訳かと思うと感謝と冷汗。

しかし、それにしても”U社関連”、どこか分かりましたがひどい....(汗
せめて問い合わせ用のメールフォームでつくっとけばいいのに。

stealthinustealthinu 2006/10/26 15:52 です。普通にまっとうな対応をしていただきました。
メールサーバのログから怪しそうなログだけを抽出するスクリプト書いてあるんですが、いまいち汎用性がないのでもうちょいブラッシュアップしてから… とか思って公開してなかったんですが、公開したほうがよいのかなと思ってます。
U社関連はちょっと修正してもらったほうが良さそうに思います。結構大きなところだし。やはりここはdeoさんに連絡いただくのが最も効果的でしょう :)

deodeo 2006/10/26 21:20 ダイヤルアップ接続(当然S25Rに引っかかる)でU社のMXにSMTPかけてみたら、RCPT TOに対して220が返りましたよ。というわけで、裏を取ることができませんでした。
 苦情殺到でS25Rをはずしちゃったのかな。

stealthinustealthinu 2006/10/27 10:07 自分の例は結構最近なので、まだ設定があるとは思います。
なんらかのホワイトリストを準備してるか、他の判定基準も併用してるんでしょうかね。
後でメール差し上げます。

deodeo 2006/10/28 19:08 「RCPT TOに対して220が返りましたよ」と書いたのは間違いで、「250」でした。
 予備サーバを使って、そのIPアドレスの逆引き名をS25Rに引っかかるように変えてアクセスしてみたら、450が返りました。

telnet mx2.usen.ad.jp 25

450 <219-163-213-19.rev.reto.jp[219.163.213.19]>: Client host rejected: may not be mail exchanger

 一応、S25Rは正しく運用されていますね。ダイヤルアップ接続で引っかからなかったのは、私が使っているmopera.ne.jp(ドコモのPHS)が引っかかるルール5を採用していないからかもしれません。
 さとうさんが相談を受けられた件は、リトライ時間が短すぎたということはありませんか?

stealthinustealthinu 2006/10/28 19:46 なにも細工されてない素のqmailだと思われるので、たぶんそれはないと思います。
たぶん、qmailでリトライ時間を短くしようとすると、パッチ当ててコンパイルしないと無理ですよね。

deodeo 2006/10/28 20:18 そうすると、やっぱり何日も放置プレイを食らったということですかね。

stealthinustealthinu 2006/10/29 13:25 うーん、少なくとも自分が関わった例や、Webで検索して出てくる例ではそうなのでは。
ログから怪しいのを抽出して、自動でアラート上げるようにしておくとか、自発的にログを確認するのではなく、いやでも確認させられる、くらいの状況にしておかないと、確認しない人は確認しないのかな、と思ったり。
いや、そういうシステムになっててもチェックしないようなところすらあると思います。

deodeo 2006/10/29 14:07 S25R(特に素の方式)は、まめな人にしか導入してほしくないですね。私はリトライアクセスを見つけやすくするためのツールも提供しているのに。
 論文の上っ面だけ読んで「逆引きを検査する方式だからだめだ」と思われるのも心外だけど、リスクをちゃんと理解せずに導入するのも困るので、論文のページの先頭に「目次ページもご覧ください」という注意書きを入れましたよ。

stealthinustealthinu 2006/10/31 18:15 たまにS25Rについて批判されてるのを見ると、そこのところを誤解してる人がいるように思います。
結局、メンテナンスフリーであるという思いこみで評価したり、導入したりしてる人が問題なのですよね。
そういう人は、DNSBLもマッチしてたらそのままrejectで運用してるんだろうなあ…