【 カマダ (11.13/06) 】 疑問はいくつか残っていますがとりあえずGLSTの運用を始めました、実際に運用してみると疑問も少しずつですが解消してきています、 使い始めてみるとGreetPauseもGreylistingも投げ捨てタイプのspamメールには同様の効果がある事を実感しています、 しかもGreylistingならローカルユーザーのメール送信には影響がありません、 GreetPauseもGreylistingもホワイトリストの設定が重要で、 とりあえず迅速性が必須と思われる携帯電話各社のIP |
【 カマダ (11.13/06) 】 疑問はいくつか残っていますがとりあえずGLSTの運用を始めました、実際に運用してみると疑問も少しずつですが解消してきています、 使い始めてみるとGreetPauseもGreylistingも投げ捨てタイプのspamメールには同様の効果がある事を実感しています、 しかもGreylistingならローカルユーザーのメール送信には影響がありません、 GreetPauseもGreylistingもホワイトリストの設定が重要で、 とりあえず迅速性が必須と思われる携帯電話各社のIP |
【 カマダ (11.13/06) 】 続き・・・とりあえず迅速性が必須と思われる携帯電話各社のIPアドレスは全てホワイトリストに入れました、 ホワイトリストを作るときに今回は送信ドメイン認証がかなり役に立ちました、各社のDNSのTXTレコードを見るとそこにはメールの送信に使われるIPアドレスが確実にわかります。 しかし、docomoはひとつのサブネットマスクに全部収まるので一行ですむのですが、 auやソフトバンクは何行にもなってめんどくさいです・・・ と、ここまでやってて思ったのですが、 XMailも受信の際にドメイン認証が出来ればこんな面倒なことしなくてすむのになぁ・・・と。 |
【 カマダ (11.17/06) 】 ここ数日GLSTのホワイトリスト作成にかかりっきりでしたが、ホワイトリストの追加が進んだことに加え IPアドレスと送信相手のメールアドレスと受信者のメールアドレスの三点セット（これをトリプレットと呼ぶらしい）の学習も進んだおかげで正当なメールはほぼ待たせることなく普通に受信できるようになりました。 GreetPauseで長時間の遅延を全てのIPアドレスにかけることは通常のメールの送受信にも影響するため避ける必要があり、 短時間の遅延ではすり抜けてくるspamメールがあったのですが、 GLSTでは遅延どころかいったん切断しているのでスパマー対策にはいまのところかなり効果を発揮しています。 ホワイトリスト作成が一段落ついたので、 こんどはGLSTの説明書を自分なりに訳して 自分がどこまで理解できて何を理解していないのかはっきりさせようと思います、 ある程度説明書の和訳がすんだら皆さんにも見ていただきたいと思っていますので そのときは間違っている箇所をぜひご指摘いただければと思います。 |
【 カマダ (11.17/06) 】 ところでこの「トリプレット」の仕組みをspamメール対策に使うというのは良く考えたなと思います。spamメールはメールアドレスで受信拒否されないように常に送信者のメールアドレスを変えてきます、 また、不正中継データベース対策として使用するIPアドレスもころころ変えてきます。 そうやってころころ変えている限りは絶対メールを受け取ることがありません、 もしIPアドレスをある程度固定してしまうとそのときは不正中継データベースの利用で防ぐことが出来ます。 そしてきちんと再送してくれる相手であれば、ホワイトリスト漏れの相手でも受信してくれます。 ただし固定IPではないメールサーバからのメールは受信しづらくなりますね。 |
【 カマダ (11.17/06) 】 GLSTの使い方の中から非梅雨尾奈部分を訳してみたのでよろしければごらんください、長文ですのでもしここに書くのがふさわしくない場合はご指導ください。 GLST GLSTはXMailにSMTP Grey Listingを追加します、SMTP Grey Listingはspamメール対策のひとつです GLSTはXMailの作者Davide Libenzi 氏が作成しました SMTP Grey Listingについての詳細はこちらのURLをご覧ください、http://projects.puremagic.com/greylisting SMTP Grey Listing SMTP Grey Listingはspamメールの多くがメールを投げ捨てしている点を利用しています。 具体的には、一度送られてきたメールの受け取りを一時的に拒否しその後再送してきたメールだけ受け取ります。 メールが再送されたものか否かの判断は、「IPアドレス」「差出人のメールアドレス」「受取人のメールアドレス」の三点をセット（tripletと呼ぶ）をキーとし、同じキーのメールが送られてきたら再送とみなします。 これは、spamメールの多くが投げタイプで再送を行わず、メールアドレスで受信拒否されないように同じ差出人を使わず、IPアドレスで拒否されないように同じIPアドレスを使わない点に着目したものです、 なお、spamメールの中には同じIPアドレスを使い続けるタイプも存在し、その場合差出人が同じであればGrey Listingを通過するケースもあります。この場合IPアドレスでspamメールを判断する不正中継データベースが効果的です。 もちろんXMailはGLSTと不正中継データベースの併用が可能です。 ダウンロード GLSTは以下のサイトからダウンロードできます、現在のバージョンは0.24です。 http://www.xmailserver.org/glst-mod.html GLSTはC言語で書かれていて自分でコンパイルして使うことが出来ますが、Windowsユーザー向けにすぐに使えるバイナリファイルも入っています。 XMail+XmailCFGでGLSTを使うときに必要なファイルはダウンロードしたパッケージの中のwbinフォルダのglst.exeとcfgフォルダのglst.confの二つです、glst.exeが実行ファイルでglst.confは設定内容を書き込んでおくテキストファイルです。 使用方法 この二つのファイルは同じフォルダに置いておきます、今回の置き場所はGLSTの説明書にしたがってxmailがインストールされたc:\usr\xmail\MailRoot\bin\にします。 filters.pre-data.tabに以下のように記述します "!aex" "c:\usr\xmail\MailRoot\bin\glst" "--mfile" "@@FILE" ※これはxmailフォルダがc:\usr\フォルダにある場合ですので、この部分は自分のサーバに合わせて必ず変更してください XMailCFGをお使いの方はfilters.pre-data.tabを開くとすでに一行記述されているので二行目に記述します XMailＣＦＧをお使いの場合は「フィルタの管理」-「SMTP DATA前処理」から「カスタム定義の追加」でfilters.pre-data.tabへの記述が出来ます 起動コマンド：!aex 最初の引数：c:\usr\xmail\MailRoot\bin\glst （※必ず自分のサーバのフォルダにあわせて変更してください） その他の引数：--mfile @@FILE ここまでの設定でGLSTは動き出します、最初は全てのメールをいったん受信拒否しその後再送されてきたメールだけ受け取りを始めますので気長にお待ちください。 ホワイトリストの設定 さて、glst.confには最低限必要な設定が書かれているので最初はそのまま使用してもかまわないのですが、受け取るメールの量が多い相手のIPアドレスをホワイトリストとして登録することをお勧めします、glst.confへのホワイトリストの記述の一例を書くと以下のようになります # au xnet=202.239.211.192,255.255.255.192 xnet=210.131.250.150,255.255.255.255 以下続く ・ ・ ・ 行の一番最初に#を入れることによりコメントを書いておくことが出来ます 「xnet=」これがホワイトリストを示し、その後にGLSTをスルーするIPアドレスとMASKを記述します、IPアドレスとMASKの間は「,」で区切ります これはauの携帯電話から送られてくるメールをホワイトリストに登録した例ですが、auの場合DNSのｔｘｔレコードにメール送信サーバのIPアドレスが記述されているので今回はそれを参考にしました、なお、もちろんこのIPアドレスは相手次第でいつでも変更されてしまうので逐次チェックが必要なのはいうまでもありません。 glst.confの内容と設定 ここで、ホワイトリスト以外のglst.confの内容についても触れておきます、ダウンロードしたばかりのglst.confの中は以下のようになっています、これらは絶対に必要なので削除してはいけません rejmsg=451 4.7.1 Please try again later generr=0 rejerr=3 timeo=1200 exptimeo=3110400 lametimeo=28800 rejmsg smtpセッション中に相手のメールサーバに送るメッセージです、451は一時的にメールの受信が出来ない旨のsmtpコマンドでそれにコメントが続きます generr rejerr この二つはXmailにGLSTの動作結果を伝えるために使う数字を記述しています timeo 一度受信を拒否したメールがこの時間の経過後に再送されてきた場合に受信します 単位は秒です この時間を短く設定すると同じ相手から同じspamメールが立て続けに送られてきたときに受信してしまう可能性があります この時間を長くすると、たとえば正しい相手からのメールがそれより短い間隔で再送されてくると二度三度と受信拒否することもあり、そのばあい相手のメールサーバが送信を断念してしまうことも考えられます 個人的には1200秒（20分）は長すぎると思い私の場合もっと短い時間を設定しています。 exptimeo 再送が通ったメールのtripletを記憶している時間です 単位は秒です（3110400秒は36日です） ここに設定された時間の間はそのtripletで送られてきたメールは受信拒否を行いません さらにこのtripletのメールが送られてくるたびにこの時間の分だけ延長されます この時間を越えて送られてこないメールのtripletは削除されます lametimeo 再送されなかったメールのtripletを記憶している時間です 単位は秒です（28800秒は8時間です） この時間を越えて再送がないメールのtripletは削除されます |
【 通りすがり (11.17/06) 】 私はSPAM防止策として、IpSwitch社のIMail Server 8.2をXMAILの手前にリレーサーバーとして設置してます。Imail ServerのSPAM防止機能は優秀で、DNSBL機能はもちろん、FROM正当性確認、heloドメインの正当性確認、SPFチェックなどが可能で、その結果をヘッダに追加します。 これをルールで判定させ、例えばDNSBLだけに引っ掛かった場合は、XMAIL側にあらかじめ作成しておいた、SPAMかどうかグレー用のアカウントへ転送させたり、FROM確認ができない＋DNSBLにも該当した場合は、リレーせずに叩き落としたりなど、IMail側にルールを作って運用したところ、90%はSPAMが届かなくなりました。 ほとんどのスパマーが、FROM偽装、heloの名乗りがおかしい、SPFに反しているなどです。 少し、お値段は高いかもしれませんが、会社などで業務的にXmailをご利用されるなら、IMailをMTAにしてみるのも良いかと思います。 http://www.kgt.co.jp/feature/imail/ |
【 matsu (11.17/06) 】 カマダさん、有益な情報ありがどうございます。おそらくですが、XMail 1.23から "!aex,wlex" "c:\usr\xmail\MailRoot\bin\glst" "--mfile" "@@FILE" というフラグ指定が可能になります。 wlexというのはXMailのホワイトリストにあるホストからのアクセスの場合はそのコマンドを実行しないというオプションで、つまりGLSTでホワイトリストを設定する必要がなくなるかも。(また勘違いか。。) |
【 カマダ (11.18/06) 】 matsuさん貴重な情報ありがとうございます、確かに同じようなホワイトリストがあちこちにあるよりひとつの方が分かりやすいのでいわれるような機能がつくことは考えられますね。 もっとも私の場合ホワイトリストは適材適所で少しずつ違った物になっています、 たとえばGreylistingに設定するホワイトリストは結構ゆるい物になっていて、 メールを送ってくる相手がプロバイダでなく普通の会社などであれば私はその会社のもっているIPアドレスまるごとスルーさせてしまっています、 XMailのホワイトリストがこれだと不正中継する恐れがあってまずいですよね。 |
【 カマダ (11.19/06) 】 XMail1.23でホワイトリストに入っているIPアドレスにはフィルターを使用しないコマンドが入っている件ですが、よく考えると必要な機能のようですね。 せっかくXMailのホワイトリストを設定してもフィルターに引っかかってしまってはホワイトリストの意味がありませんから。 私の設定するGreylistingのホワイトリストはXMailで言うところのSMTPアクセス許可レベルですね。 |
【 nakamura (11.25/06) 】 カマダさん、GLSTの運用順調みたいですね。GreylistingとGreetPouse(Xailではtarpittingという方が適切なようですね。)のどちらを採用するか迷ったりもしていますが、私のところではこの時期、一見さんからのメールでの問い合わせなどが増えてもくるので、なんとなくGreylistingの採用に躊躇しています。実際に運用してみての両者の比較など教えていただけるとうれしいです。 この辺のページの比較なども参考に考えているのですが・・。 http://d.hatena.ne.jp/stealthinu/20060728/p3 もっとも、xmailserver.orgのMLを見ていると、tarpitting関連の話題はあまり見ないです。GLSTの話は多いですね。 Davide Libenziさん自身がメンテナンスされてもいますし、XmailserverではGreylistingの方が一般的なのでしょうかね |
【 カマダ (11.26/06) 】 なるほど、これからはGreetPouseとは呼ばすにtarpittingと呼ぶことにします。まず、私のところでのspamメールへの効果ではGreylistingの方がかなり高いです、 ただ、Greylisting導入とともにtarpittingはすべて解除していますが、そうすると今度はSMTPのログにも大量のエラーログが残るようになります、それだけtarpittingも効果があったことがわかります。（tarpittingの効果はログに残らないので） そしてGreylistingで一番大変なのはそのホワイトリストの設定でしょう、まさにすべてを許すホワイトリストと接続を許さないブラックリストの狭間の、接続は許すけどリレーは許さないグレーリストといった感じでしょうか？ 私の場合GreylistingにおけるホワイトリストはXMailにおけるSMTPアクセス許可とほぼ同意です。 nakamuraさんの危惧する初めて送られてくるメールや一ヶ月に一回も送られてこないメールをいったんリジェクトしてしまうのがやはりGreylistingの最大の問題でしょう、 これは運用しているメールサーバの使われ方次第で評価が大きく分かれるでしょうね。 とにかくspamメールでも何でも確実に受信したいというユーザーにとってみると余計な仕様ですし、 私の運用しているメールサーバで言えば、そこまで求めている人は今のところいなくてある程度spam対策をしっかりしている方が良いようです、ただ、日々Greylistingをチェックしてきちんとした相手が引っかかっているのを見つけると随時Greylistingのホワイトリストに登録しています。 ただ、これが割と手間なのでデータベースソフトでログから必要なデータだけを抜き出すようにして、Greylistingのホワイトリストもそっちで管理するようにしました。 |
【 田中 (11.27/06) 】 カマダさん、いつも貴重な情報ありがとうございます。私もGLST導入開始しました。 スパムが非常に多く、ホワイトリスト作成まで待てなかったので、とにかく投げ捨てスパムだけでも排除しようと再送許可時間を timeo=120 と2分に設定しました。 効果は驚くべきものでスパムは1/10以下に減りました。 ただ、データベースglst.dbmが10Mbを超えたあたりから何度かglst.exeがエラーで強制終了してしまったため、glst.dbmを一度削除して運用再開しています。 glstのコマンドラインオプションに --cleanup というオプションがあり、データベースを最適化し、ファイルサイズが小さくなるものと思い実行するとデータベースのサイズは大きくなってしまい、別のデータベース glst-lame.dbm というデータベースが作成されました。 --cleanup はデータベースを最適化し、サイズを小さくするのではないのでしょうか？ |
【 nakamura (11.27/06) 】 Win32版で運用していてglst.dbmが大きくなった際に問題が起きるのはglst の以前のバージョンからの問題ですかね。xmailserver.orgのMLなどでも取り上げられていたようでした。解決方法になるかどうかわかりませんが、exptimeoとlametimeoを短めに調整するか、特にspamの多いエリアにはspammers.tabの設定で拒絶や遅延を入れるなどしてglstの処理を軽減してみてはいかがでしょうか。 Xmailの処理の順番からすると、glstなどを実行するSMTP DATA 前処理(オンライン処理)よりも前にIPベースのチェックであるspammers.tabなどの処理が行われるようです。また、不正中継データベースの参照 (CustMapsList)によるチェックで、データベースにあればペナルティとして長めの遅延をかけてみるとかするのも有効かもしれません。 いずれにしてもGreylistingを含むIPベースの処理ですべてのspamを排除するのは無理ですので、SpamAssassinなどのコンテンツ内容を見るような二次側処理フィルターと組み合わせることを前提に、IPベースの一次側の制限はあまりきつすぎない範囲でチューニングしていくのがよいのではないでしょうか。 |
【 カマダ (11.27/06) 】 田中さんこんにちは、ところで、本家のmlでもVer0.22の時ですが似たような話が出ていました http://www.mail-archive.com/xmail@xmailserver.org/msg13047.html GLSTのCPU使用率99%になってしまうという点、glst.dbmが10MBを超えているという点、 これから考えるとユーザーサイドではglst.dbmが10MBにならないように出来るだけ小さく収まるような手段を考えた方がよいのではないでしょうか？ たとえばそれはGLSTのホワイトリストを作成しスルーさせて良いサーバはglst.dbmへ登録されないようにするとか、 tarpittingを併用するとか、 私にはこれくらいしか思い浮かびませんので他にもっと詳しい方の登場を待ちたいところです。 あと、 --cleanup これはデータベースの最適化だと私も思います、ファイルサイズが大きくなるのは謎ですが、高負荷の人は日に何度か行った方がいいみたいなことも説明文には書いていましたね。私はまだ一回しかしていないのですけど・・・ |
【 nakamura (11.27/06) 】 忘れてました。最初の内はGreylistingのホワイトリストを整備するのも有効だと思います。私の管理しているユーザーで、Yahoo!グループをやってる人がいます。で、送られてくるメールを見ていると、発信ホストのIPはあまり変わらないのですが、発信者アドレスが毎回ぐらいかわっているようです。こういったサービスがあるとすぐにtripletのデータも増えてしまうと思います。 特に運用開始の当初はログなど見ながら、こまめにメンテナンスしてあげると良いのではと思います。 |
【 カマダ (11.27/06) 】 コメントを書いている間にnakamuraさんのコメントが挾まってしまい同じようなこと書いてますね、一応参考までに私のGLSTのホワイトリストの設定をどうやったか書いておきます。 1、携帯電話会社三社のIPアドレスを登録/DoCoMo、au、softbank 2、大手メールサービス会社のIPアドレスを登録/Yahoo!、Google（Gmail）、aol(aol.comとaim.com)、Microsoft(hotmail) 3、ログを見ながら大量にフィルタに引っかかるメーリングリストやメールマガジンのIPアドレスを登録、 ここまでは最低限必要だと思います、また上記のうち1と2ですが、こちらは携帯各社と大手メールサービス会社は送信ドメイン認証を始めているのでDNSのtxtレコードを見るとホワイトリストに入れるべきIPアドレスも簡単にわかります。 メーリングリストやメールマガジンの配信会社は多くのIPアドレスを持っているところもありますし、そうでなくてもnakamuraさんの言われるように送られてくるたびにメールアドレスが違うのでいちいちGLSTに引っかかります。 私のところではYahoo、まぐまぐ！、combzmail.jpからのメールが多いですね、もちろんこれらはすべて登録しました。 ここまでやったら後は一週間程度は毎日ログを見てGLSTに引っかかったものでしょっちゅうメールが来そうなところを随時追加していきました。 楽天などのネットショップや銀行、クレジットカード会社、証券会社、プロバイダなどなど。 今日現在でGLSTのホワイトリストは323行になっていますが、これを見て思ったのは意外にプロバイダからのメールって少ないんですね(^_^;) |
【 nakamura (11.27/06) 】 323行ですか、すごいですね。でもそれくらい登録してもパフォーマンスには影響しないと言うことでしょうか。「glstは高速に動く」みたいに書いてあったのを思い出しました。いずれにしてもGreylistingは副作用も大きいのでホワイトリストのメンテナンスは必須ですね。むしろGreetPauseのほうがメンテナンスが少なくてすみます。Xmailの場合はSMTPセッションの全段で遅延が聞いてくるので、GreetPauseとはいいにくい観もありますが、あまり管理に手間をかけられない場合にはtarpittingを基本にコンテンツフィルターを併用するのがいいのかもしれません。 S25Rのような手法を併用して相手サーバーの状態に併せて選択的に対応できるようになるとメンテナンスの手間が減るのかなとも思うのですが・・。 |
【 田中 (11.27/06) 】 nakamuraさん、カマダ さんレスありがとうございます。こんなに早くレスがつくとは！ 実はホワイトリストも300行を超えているのでデータベースのサイズ肥大の原因はスパムが多すぎるということなんでしょうね。 --cleanup を行って生成された glst-lame.dbm をダンプしてみたところ、リジェクト後再送してこなかったIPの一覧とそのカウント数が記録されているような感じでした。 カウント数の多い順にソートすると多いものは1IPあたり500件以上もリジェクトしていたので、これらがスパムホストに登録する候補になるんでしょうね。 GreetPauseも魅力的なんですが、ユーザさんから苦情がくるといちいち説明したりしないと大変なのでいまのところは見送っています。 GLSTは現在までユーザさんには気づかれていない様子です。 とりあえずスパムホストを充実させて様子を見ようと思います。 ありがとうございました。 |
【 カマダ (11.28/06) 】 そのようにspamが多いのであれば、ユーザーの使用していない特定のIPアドレスにごっそりtarpittingをかけた方がよいかもしれません。私も以前は韓国、中国そしてverizon.net、rr.comには90秒から120秒のtarpittingをかけ http://www.ysd.bne.jp/toku/apnic/ ここを見てAfriNIC、ARIN、LACNIC、RIPEの管理しているIPアドレスには30秒から60秒のtarpittingをかけていました、 GLSTを導入したのは日本国内からのウイルス性のspamが増えたためで 日本国内のIPアドレスにtarpittingをかけると通常のメールの送信にも遅延がかかって使い勝手が悪かったからです。 「スパムホストの管理」の方がGLSTより前に働くので、「スパムホストの管理」で上記のアドレスにtarpittingをかけると田中さんの場合もっと効果的なのではないかと思います。 |
【 nakamura (11.28/06) 】 カマダさん、田中さん おはようございます。私のところも11/25の夜から試験的にglstを導入してみました。従来のspammers.tabでのデフォルトでの遅延はやめ、また、全体に遅延を緩和しながら併用しています。流量はサーバーへの着信ベースでIncoming Mail、Outgoing Mailともに500通/日程度ですが、glst.dbmのサイズは2MB程度です。（glst.confへはホワイトリストを随時追加しています。） これまで、私の管理しているサーバーへは、日に200〜300通のspam送信の試みがあり、そのうち3〜5通程度がすり抜けてくるという状況でした。それがこの2日半ほどはまったくspamが着信しなくなってしまいました。確かに効果は高いですね。もっとも、tarpittingとの関係ではやや向き不向きがあるようですが・・。 届かなければならないメールの抜け落ちがないのか、もう少し様子を見ながら運用して、改めて採用の可否を考えてみようと思っています。 |
【 カマダ (11.28/06) 】 私の管理しているメールサーバの先月のIncoming Mailは12898通でした、日平均430通ですね、tarpittingひっかかるとログに残らないのでspamの総量は不明です、 不正中継データベースなどのブラックリストにかかったのは1355通でした、 そしてGLSTを使い始めてからはtarpittingをやめたのでspamも含めたIncoming Mailの総量がわかるようになりました、 以下は左側がメールの総数で右側が実際にローカルユーザーに配達された数です。 11/21 2076通 555通 11/22 2411通 480通 11/23 2135通 314通 11/24 1909通 443通 11/25 1212通 352通 11/26 1060通 262通 11/27 1668通 488通 GLSTのために実際配達されたメールのほぼ2倍の数がspmaではなくなるので、単純計算で日に500〜1500通のspamメールが来ている計算になります。 もちろん私のところにも毎日のように5〜6通のspamメールが届いてのですが、11/13にGLSTを使い始めてからは総計で4通しか届いていません。 そして今現在のglst.dbmのサイズは851KBで、昨日cleanupをして出来たglst-lame.dbmのサイズは397KBとなっています。 |
【 カマダ (11.28/06) 】 実は今考えていることがあります、それはGLSTを新しく使う人のために私のGLSTのホワイトリストを公開しても良いのでは？と言うことです。 ただ、そうすると私のメールサーバのローカルユーザーのメール受信傾向がわかってしまってまずいかな？という考えや、このホワイトリストが他に悪用されるおそれがないのか？そしてホワイトリストがいつまでも正しいとは限らない、という心配が残ります。 |
【 田中 (12.04/06) 】 カマダさん、グレイトです！ホワイトリストが用意されていればGLST導入の敷居は低くなるので導入される方も増えるのではないかと思います。 使ってる人が多いと情報もあつまりますからトラブルや疑問点の解決に繋がるのではないでしょうか。 |
【 かいじん２０面相＠宇宙空間 (12.04/06) 】 >カマダさん、グレイトです！よきかな善男子！！ |
【 カマダ (12.18/06) 】 GLST用のホワイトリストの公開はupするところがないので未定です(^_^;)さて、ホワイトリストの追加もほとんどなくなってようやくGLSTのメンテの必要が少なくなってきました、 GLSTを使った場合の最大のウイークポイントはそのホワイトリストのメンテナンスが必要な点でしょう。ノーメンテナンスが一番ですがそうはいきません、 しかし、以前は毎日何通ものspamメールをspamcopに報告し、さらには自分でブラックリストを設定していたことを考えるとGLSTのホワイトリストのメンテの方がずっと簡単です、 現在ではspamメールも一日一通来るか来ないかといった感じで平穏な日々になりました。 |
【 nakamura (12.22/06) 】 > GLST用のホワイトリストの公開はupするところがないので未定ですそうですよね。どこでもアップしていいわけでもないですし。 管理人さんの許可があればですが、この掲示板に掲載させていただくというのはどうなんでしょう。私のところも（そのままというわけにはいきませんが）紹介させていただいても大丈夫だと思いますし・・。 どうせなら、こんな対策を組み合わせていて、効果はこんなとか、簡単な紹介もあると、参考にしやすいのではないでしょうか。「コレが絶対」なんて設定はないので、自分ところのポリシーにあった例を参考にするとかできるといいように思いました。 効果のほどですが、私のところもほとんどspamが届かなくなっています。へんなもので、なんだか物足りない感じがしするこの頃です。 |
【 SL管理人 (12.25/06) 】 カマダさん、nakamuraさん、 ホワイトリストについては、ここではそのうち埋もれてしまうので、xmailserver.jpの適当な場所で公開し、ご両人が内容をメンテナンスできるようにしたいと思いますが、それでどうでしょうか。 その場合のログイン情報などを送りますので、連絡先メールアドレスをsladmin@hunet.jpまで知らせてください。 そのさい、メッセージ内に個人情報を書く必要はありません。 |
【 nakamura (12.26/06) 】 管理人さん、ご配慮ありがとうございます。そちらへ連絡させていただきます。よろしくお願いします。ところで、GLSTの動作についてですが、少し気になった点がありました。 HELOコマンドでクライアントのドメインを詐称された場合ですが、GLSTのホワイトリストに登録されたIPアドレスを名乗られるとGLSTは拒絶することなく通してしまうようですね。 たとえば、クライアントIPが"YYY.YYY.YYY.YYY"でfromドメインを"XXX.XXX.XXX.XXX"と名乗った場合、Receivedフィールには以下のような記録が残ります。 Received: from XXX.XXX.XXX.XXX (YYY.YYY.YYY.YYY) ここで、"XXX.XXX.XXX.XXX"がGLSTのホワイトリストにあると、そのまま通過してしまいます。 まあ、コンテンツベースのフィルタで"Received: from XXX.XXX.XXX.XXX ("をはじくなどしてしまえばいいわけですが、クライアントのIPをきちんと見ているわけではなさそうなので注意が必要かなと思いました。 |
【 nakamura (01.08/07) 】 SL管理人さん、いつもお世話になっていますす。GLSTのホワイトリストについて、ご案内いただいたアップ手順に従い、先ほど公開するようにしました。色々とありがとうございました。 それと、上のコメントで書いたGLSTの動作についてですが、本家のMLでも少し話題が出ていたようです。Xmail1.24で対応されたようなので、少し様子を見てみようと思います。 |