17-4. Greet Pause でしばらく逃げる `27/01〜 (1) Greet Pause で待ったをかける * Greet Pause あれこれ いろいろ評判を拾ってきたいが、あまり情報がない。あるサイトの話で、２００６年の６ 月、１２秒の設定で２５％弾くが、Greet Pause でもだんだん諦めなくなってきていると か。紀州のとある大学は２００６年４月に利用を開始とだけ。 ２チャンネル 2006/11/22 から、デフォルト５秒、怪しいのは５０秒で３００件登録、安全なところ０秒で千件登録 して１日４千通で３００通弾く。２０秒で１／３で弾いているところも見た。 まともそうなところ、あらかじめ分かっている相手は、できるだけそのまま通すようにし た方がいい。ホワイトリストへ登録して、待たせないようにする。Greet Pause で待たせ るということは、相手も自分とこのメ−ルサ−バもその間、プロセスが稼働した状態にな る。相手のメ−ルサ−バもその間、自分とこのために稼働し続けるわけである。マシンの 性能が低ければ、多数のプロセスをさばき切れなくなる。 Greet Pause は論理的に誤検知はない。しかし副作用はプロセスの増加、最悪の場合メ− ルサ−バの機能不全ということになる。そうならないようにするため、おかしなメ−ルを 極力減らして sendmail デ−モンの数を減らすようにしなければならない。これはまた同 時に外ヘの迷惑メ−ルを出さない、減らすようにすることでもある。結局、対策としては 自社 Mail-Relay サ−バの負荷軽減、内外への迷惑メ−ルを減らすことである。 Greet Pause と併用して access ファイルでブラックリストにどんどんおかしな所を入れ るのはどうか。ボットのゾンビＰＣからのメ−ルだと、ＩＰアドレスや FQDN によるフィ ルタリングは有効な気もするが。基本的に相手は変幻自在だから、必要なメ−ルまではじ く可能性はどうしてもある。あまりお勧めできないか。フリ−のRBL と一緒のことになる。 待たせている間にｓｐａｍ屋さんは構わず SMTP コマンドを送ってくる。するとこちらで は拒否して syslog に"rejecting command from xxx ... due to pre-greeting traffic" とログを残す。相手がまともなメ−ルサ−バならお行義よく待つ。しかしあまり待たせる と、今度は相手のメ−ルサ−バがタイムアウトを起こして諦める、これも syslog に残る。 とりあえずデフォルトで全部、待たせるよう設定する。やってみて問題があれば待ち時間 を無しにして、ブラックリスト的に設定する。必要なメ−ルが受けられなく可能性がある ので syslog はよく見ておかないといけない。sendmail, qmail, Postfix の MTA は大丈 夫だろうが、Windows 用の MTA は、どんな振る舞いをするか分からない。 Greet Pause は Mail-Relay に設定する。できるだけ滞留するメ−ルで sendmail の負荷 が増えないようにしなければいけない。そのためには /var/spool/mqueue/ のファイルを できるだけ減らすこと。 2007/01、# ls -l | wc -l でカウントしたら２６８０個あった。 半分は本文、制御ファイルだからメ−ル数は約１３４０。mailq やったら１２２個あった。 ここんとこ何ヶ月か Mail-Relay の /var/spool/mqueue/ を自分が書いたコマンドで不要 メ−ルの消去を行なっている。Greet Pause などを実施している、九州の有名なとある大 学宛のメ−ルがキュ−に溜まっていた。 "MDeferred: 451 4.7.1 Greylisting in action, please com back later"。数時間して見たら無くなっていた、配送された。`27/09 * Greet Pause の位置付け ------------ ----------- ---------------- |DefensePro|----|InterScan|-----|PC Virus Check| ------------ ----------- ---------------- DefensePro はウィルスチェックをする。下記左の図で◆の所にDefensePro がかんでいる。 ネットワ−クケ−ブルを真ん中でちょん切って DefensePro のポ−トにつなぐ。外から内 へのメ−ルは a で検査され、ウィルスが入っていれば dropされる。これでほとんどのウ ィルス入りメ−ルを弾いている、InterScan で検出されるのは週に１つぐらいのものであ る。hostA から内外へのウィルス入りメ−ルは d で drop される。 これも結構多いのだ。 ウィルスでない、またはただの迷惑メ−ルの場合は、そのまま行ってしまう。外へ行くの はバウンスメ−ルという。内へ行くのは外へ行こうとして該当ユ−ザがいないとかして管 理者へ行くエラ−メ−ル、ダブルバウンスメ−ルというらしい。このダブルバウンスメ− ルを見ると、添付ファイルも全部１つのメ−ル本文になっている。d で drop されるのは a をすり抜けたウィルス入りメ−ルなのか。 どうもおかしい。以前、聞いた話では DefensePro は添付ファイルのウィルスはチェック しないとか。しているんじゃないのか。ウィルス入りメ−ルはほとんどが添付ファイルの 形で来るのでないのか。添付ファイルをチェックしないのであれば a では、 ほとんど検 知できないはずである。しかし検知して dropしているのならば、なぜ d でも検知するの か。最初、hostA にワ−ムなんかが入り込みそれがウィルス入りメ−ルを巻散らしている のでないかと疑った。どうもそれはなさそうなのだが。b,c ではほとんど DefensePro の ログは出てない。a で見つけられなかったウィルスメ−ルが、バウンスメ−ルやダブルバ ウンス−ルになることにより、見つけられる形になったということか。もう一つの疑問は DefensePro がそもそも InterScan が必要ない程、ウィルスを見つけているとは思えない のだ。メ−ルの理解は DefensePro の動作の理解も求められる。 ： ： 仮想ＩＰ 仮想or実ＩＰ設置 Router□ ● □ □hostA' ■ ｜ ｜ ｜.1 ｜.3 ｜ --------- -------------------------- 202.241.128.0 | HUB-A | ｜ □hostA ○ --------- hostA ｜.2 ｜Mail-Relay ｜ ｜a □ ○ □-------------------- ◆ ｜ ｜ ｜ □hostB InterScan ｜b --------- ｜ ｜Mail-Store hostG□--◆---| HUB-B | ----------------- hostB□ ｜ c d --------- ｜ ｜ ○●■は Mail-Rela予備機である。 ----------- --------- PC ○はDMZに設置し仮想ＩＰで外に出す。 --◆--| HUB-C |----| HUB-D |---△ ●はバリアセグメントにそのまま設置。 ----------- --------- DefensePro のログを数えてみた。[Security Reports]->[Attack Logs]で１日分を１００ ずつ表示していった。ポ−ト a では外から内へのメ−ルが約６００コ drop、ほとんどが SMTP-IE-IFRAME で Worm-NetSky.Q-1 と Worm-Klez.H が２割程度。 内から外へのメ−ル で止められていたのはなかった、そのメ−ルは d で止められることになる。 それでポ− ト d では何と２５００コも drop されていた。すごい数だ。Mail-Store へのメ−ルと外 へのメ−ルが半々、SMTP-IE-IFRAME と Worm-NetSky.Q-1が半々だった。DefensePro が止 めてなかったら大量のウィルス入りメ−ルを外へ発信しているところだった。いや安心は できない。ウィルスでない、ただの迷惑メ−ルは発信しているはずだ。`27/04初めのこと。 そうそう Mail-Relay の状態も記しておかないと。メ−ルキュ−には約６００個のファイ ル。sendmail.cf は queuereturn=5d、queuewarn=4h。sendmail -bd -q1h。メ−ルキュ− のファイル消去は find の -mtime +5 で、一応 queuereturn=5dで処理してからのつもり。 * 参考 「オ−プンソ−スマガジン」2006/02 月号、"第２特集：メ−ル配送技術の最新事情"、 > Part 3 Sendmail/qmail/Postfix での迷惑メ−ル対策。 http://www.hart.co.jp/spam/greetpause.html Google で[ greet pause ]と検索すると、 > 真っ先に出て来る。長崎のコンピュ−タ会社で、以前からスパム対策を取り組んでいる。 「メ−ルゲ−トウェイにおけるｓｐａｍ対策について」大分大学総合情報処理センタ−の > 吉田先生による論文。Greet Pause は SMTP レベル、Graylisting は TCP レベル。 「NETWORK MAGAZINE」2006/10, P.80〜83, "かんたん sendmail 運用術 第３回プロトコル > ベ−スのスパム対策", GREET PAUSE を用いたスパム対策の６０秒での例。 (2) スプ−ルの整理を先ずしないと * メ−ルリレ−のホストでトラブル発生 早い話 Mail-Relay ホストにおかしなメ−ルが溜まりすぎて、 sendmail のプロセスが一 杯できていたのが原因である。常時２０個前後できている。/var/spool/mqueue/には３千 ファイルぐらい常にあった。これが元でメ−ルサ−バがちょいちょい機能不全に陥ること があった。マシンの様子、状態はこれまでもネットワ−ク管理ソフトの Nagios で見てい た。Nagios のワ−ニングは２００６年５月頃から時たま出ていたが、 １分ぐらいですぐ に直っていた。Nagios のログを見るといつの間にやら警告、そしてＯＫが出ていた。 そ れはそれでとりあえず問題はなかった。次の "Socket timeout" うんぬんのログである。 Nagios は監視するホストのＩＰアドレスを指定して、メ−ルサ−バなら SMTPアクセスし てその反応をみるようになっている。一度は Mail-Relay ホストからswap何たらとメッセ −ジが出て。機能停止していた。マシンのキ−入力も反応しなかった。Nagiosでの警告は {Service Status Details For All Hosts}で Mail-Relay ホストの監視のとこが赤くなっ た。モニタ画面には"SMTP CRITICAL 時刻うんぬん CRITICAL - Socket timeout after 10 seconds" と繰り返す出ていた。Mail-Relay の sendmail を停止して再起動すると、１分 ぐらい経って赤が消え、次のメッセ−ジが出た "SMTP ok -0.136 sec. response time"。 そして完全にメ−ルサ−バの機能が止まってしまうことが起こった。社内から顧客に向け て数千通のメ−ルを一斉配信した時だった。メ−ルがおかしいことに気付き、いろいろ調 べていった。Mail-Relayホストのログやキュ−をみて、営業部門からの一斉配信だと分か った。とりあえず一斉配信は中断してもらった。モニタからは"WARNING: Sorry, no swap space to grow stack for pid 8710 (sendmail)"このメッセ−ジが３０秒毎ぐらいに、同 じのがどんどんでてきた。sendmail を止めて mqueue に溜まった "User unknown"のファ イルを一挙に消した。それから一斉配信を再開してもらった。その後は異常なかった。 負荷がかかっている時のマシンがどういう状態だったか。メモリはどうか、プロセスはど うだったか。いかん、慌てていて見ることができなかった。何と CTRL+d を押していたら ロッグイン画面まで戻ってしまった。文字が化けていて、コンソ−ルロッグインするメニ ュ−が分からなくなった。予備のマシンを起動して、上から３番目のメニュ−がそうであ ることを確認した。しかしメ−ルリレ−でメニュ−をクリックしても、反応がなくなって いた。STOP+a キ−を押し、ok プロンプトで sync と入れた。[13] [13] という文字が画 面に１分ぐらい続いて出て、最後なんとかマシンは起動してきた。 * 溜まったメ−ルを減らすためのコマンド [ ＵＮＩＸのコマンドの基本の確認 ] # ls 1 2 3 1 2 3 -------- ------- --------- |katou |yasuko |katou ※Apollo では/usr/bin/findに。 | katou xargs なし。wcも見当たらない。 # find . -type f -exec grep katou \{\} /dev/null \; ./1:katou ./3:katou ./3: katou # find . -type f -exec grep katou {} \; << 検索対象がファイルで、カレントデ katou ィレクトリにあるファイルで中身が katou katou という文字列を行単位で探す。 katou # find 3 -exec grep katou {} \; | wc -l << ファイル名"3"の中身で、katouとい 2 う文字列を行単位で数える。 # find . -type f -name 1 -print << 検索対象がファイルで、名前が "1" ./1 のファイルを探す。 # find . -type f -name '*' -print << 検索対象がファイルで、名前が任意 ./1 のファイルを探す。 ./2 ./3 # find . -type f -name 1 -print | xargs cat << ファイル名 "1"を検索して、内容を katou 表示する。 # find . -type f -name 1 -print | xargs rm << ファイル名 "1" が消えた。 # ls 2 3 # grep -l katou * << ファイルの内容で katou という文字列があるファ 3 イル名のみを表示する。ファイル名 "3" のみ。 # grep -l katou * | wc -l << ファイルの内容で katou という文字列があるファ 1 イルが幾つあるか数える。ファイル名 "3" だけで # grep katou * | wc -l １個。-l なしだとファイル中の文字列を数える。 2 # grep -l yasuko * | xargs cat << yasuko という文字列があるファイル名を探し cat yasuko コマンドで内容を表示する。 # grep -l yasuko * | xargs rm << これでファイル名 "2" が消える。 [ 最後にファイルをアクセスした時間 ] # ls -lu send* -r--r--r-- 1 ... 1月 31日 09:43 sendmail.cf -r--r--r-- 1 ... 3月 17日 2006年 sendmail.cf.250920 * 溜まっているメ−ルを減らす１ # cd /var/spool/mqueue # ls -l | wc -l ディレクトリ内のファイル数を知る。縦にリストして、その行 3433 数をカウントする。だから溜まっているメ−ルの数ではない。 # grep -l 'User unk' * | xargs rm 一挙に User unknown が出ているファイルを消し # ls -l | wc -l た。９４０個まで減った。しかし、消されるのは 940 本文ファイル dxxx だけである。 # ls -l | wc -l メ−ルの本文ファイルと制御ファイルの数が一致しない。 950 おかしくなった。制御ファイルが一杯残っている。 # ls -l Q* | wc -l 661 本文ファイルに User unknown がでていた。 # ls -l q* | wc -l 制御ファイルにはなかったので、数がおかしくなったか。 186 # ls -l d* | wc -l 多分ほかっておいても問題ないのでないか。問題なかったです。 98 本文ファイルの数は９８個。内ファイルサイズが０のを除いて結局、有効なメ−ルは５０ 個になったということか。dfxxx がメ−ル本文、qfxxx はメ−ル制御のファイルである。 * 溜まっているメ−ルを減らす２ こんなスクリプトで実際にメ−ルキュ−に溜まったファイルを消すことができるのでない か。最初の grep で qxxx ファイルを消去している。２番目の grep は dxxx ファイルを 消去している。検索する文字列は "User unknown" など好きなのを入れればいい。これは めんどくさいスクリプトだなと、やらないかんやらないかんと思いつつ何ヶ月もほかって いた。それが１時間で書けた。１９８９年に買った「ＵＮＩＸプログラミング環境」アス キ−出版を見て、grep sed awk コマンドを基本から確かめながらやった。 確認したマシ ンはもちろん Apollo で $/bin/sh とやって Bourne-Shell でやった。後は Sun Solaris でも動作を確認し、cronで定期的に実行させればいいだけのこと。参考書はちょっと古い が１９８３年初版の共立出版「ＵＮＩＸ」石田先生の著書も、なかなかよい。 # cd /var/spool/mqueue # grep -l "User unknown" d* | sed 's/d/q/' | awk '{print "rm",$1}' | sh # grep -l "User unknown" d* | awk '{print "rm",$1}' | sh 上記のままだと d123 というファイルがあって q123 というのがない場合、最初のコマン ドでそんなファイルはありませんと画面にメッセ−ジがでてくる。| sh >/dev/null 2>&1 とコマンドの後をすれば出なくなる。sed 's/d/q/' は最初に検討した際、sed 's/^d/q/' とした。ファイル名の先頭の文字だけ変えるという意味で ^ を付けたのだが、Apollo で は変わったけど Solaris 9 の実際の稼働マシンでやったら変わらなかった、変なの。 (3) マシンと sendmail の処理能力 * メ−ル配送の負荷に関わるパラメ−タ メ−ルサ−バの負荷に関係する sendmail.cf で設定できるパラメ−タである。以前`23/6 に sendmail-8.12.x で調べた。今回 sendmail-8.13.8 で調べ直した。 sendmail-8.13.8 をインスト−ルした /usr/local/source/sendmail-8.13.8/cf/README がその資料である。 以下、抜粋してみた。8.13.8 では confCONNECTION_RATE_WINDOW_SIZE が追加になってい た。他の３つは同じ記述のままだった。デフォルトは [] 内の値である。 confMAX_DAEMON_CHILDREN MaxDaemonChildren [undefined] The maximum number of children the daemon will permit. After this number, connections will be rejected. If not set or <= 0, there is no limit. sendmail デ−モンの子プロセスの最大の数。この数を超えると SMTPコネクションを 拒否する。この数を超えると SMTP コネクションを拒否する。設定値は 12 とか。オ −バ−したのは遅延される。 confCONNECTION_RATE_THROTTLE ConnectionRateThrottle [undefined] The maximum number of connections permitted per second per daemon. After this many connections are accepted, further connections will be delayed. If not set or <= 0, there is no limit. sendmailデ−モンが１秒間に許すコネクションの最大数。多くのコネクションを受け 付けた後は、処理を遅らせる。設定値は 3とか。外からは悪意のメ−ル爆弾。内から は顧客ヘのメ−ル一斉配信、５千とか１万通。オ−バ−したのは遅延される。 confMAX_RCPTS_PER_MESSAGE MaxRecipientsPerMessage [infinite] If set, allow no more than the specified number of recipients in an SMTP envelope. Further recipients receive a 452 error code (i.e., they are deferred for the next delivery attempt). １つの SMTP エンベロ−プにおいて、指定した数以上の受信者を許さない。それ以上 の受信者は 452 エラ−コ−ドを受ける。設定値は100とか。次回の配送に延期される。 confDOUBLE_BOUNCE_ADDRESS DoubleBounceAddress [postmaster] If an error occurs when sending an error message, send that "double bounce" error message to this address. If it expands to an empty string, double bounces are dropped. ダブルバウンスメ−ルを postmaster 以外に送るオプション。 define(`confDOUBLE_BOUNCE_ADDRESS', `suteru')dnl とすれば suteru@nix.co.jjへ。 define(`confDOUBLE_BOUNCE_ADDRESS', `')dnl とすればドロップさせる。 他にも sendmail.cf で制御できるパラメ−タがある。以下「iij.news」2005/3-4,vol.69, "ｓｐａｍからメ−ルを守れ(管理者編) 第２回:sendmail におけるタイムアウト値とリソ −スの設定"。同様の記事が IIJの 2005/11 のシンポジウムでの発表資料にもある。内容 はちょっと難しい。以下要約してみた。Timeout.command デフォルトは１時間、IIJ では ５分以上を推奨。Timeout.datablock も値同じく。 ratecontrol は sendmail-8.13.x で で使えるようになった機能である。ConnectionRateThrottleに似ているが相手ＩＰアドレ ス毎の接続を受け付ける単位時間当たりの回数である、ConnectionRateWindowSizeで時間 を指定できる。conncontrolも sendmail-8.13.x で使えるようになった、これは同じＩＰ アドレスからの並列接続を制限する。ratecontrol とconncontrol は access ファイルで ＩＰアドレスを指定する。使い方は sendmail.cf の READE 英文を読まれたい。 [ 他メ−ル配送の負荷に関わるかも知れないところ ] confQUEUE_LA 負荷が高い時に配送せずキュ−に溜める。デフォルトは 8*CPUの数。 confREFUSE_LA 負荷が高い時に受信せずに拒否する。デフォルトは 12*CPUの数。 confMAX_HOP メ−ルの無限ル−プ、ピンポンを防止する。デフォルト25。メ−ルのヘ ッダの Received の数を見る。554 エラ−を出して受け取るのを止める。 [ ＣＴＣ「テクインフォ」2005/07,VOL.56,P.62 の注意 ] /etc/mail/sendmail.cf 大量のメ−ルが来ると sendmail が幾つも生成され、 ------------------------------- しまいにはメモリ不足が起きてくる。しかしネット |#O ConnectionRateThrottle=3 を見てたら sendmail デ−モンはスリ−プ状態にな |#O MaxDaemonChildren=12 りCPUはあまり使ってないとか。sendmail-12.5から |#O MaxRecipientsPerMessage=100 抜粋したのが左で、設定はコメントになっていた。 * sendmail のデ−モンについて 相手を待たせている間、デ−モンは稼働している。 sendmail はメ−ルを１つ処理するた めに sendmail デ−モンを１つ起動して、処理して閉じる動作をする。それが瞬時に終わ るので、どんどんメ−ルがきても普通は問題ない。デ−モンが何十秒か稼働したままにな ると、ちょっと問題が起きて来るのでないか。一度きに１０通のメ−ルが来たら１０個の sendmail デ−モンが稼働する。sendmail はプロセスを１０個まで起動できるよう制限を していたら、これ以上は sendmail デ−モンはできない。メ−ルが更にすぐに１つ着たら、 これを処理するデ−モンはできない。相手メ−ルはサ−バにアクセスできなかったという ことで相手メ−ルサ−バのスプ−ルに溜まる、そして再送によりまた１５分とか１時間後 にトライする。ということになるのでないか。対策としては、デ−モンの起動する数を十 分に増やす。先ずメモリが必要になる。次にCPU のパフォ−マンスが必要になる。 * マシンの性能を計るには プロセスの実行状態を出力するフリ−ソフトのコマンド top。Solaris 9 には同等なコマ ンドの # /usr/dt/bin/sdtprocess というのがある、Solaris 2.6 にはない。ＵＮＩＸマ シンには通常 iostat、vmstat、swap というコマンドがある。メモリが足りているかどう かは vmstat コマンドなどでスワップの様子を見る。vmstat での pageのところ、ペ−ジ イン／ペ−ジアウトの値をチェック、通常は値は 0 である。 数値が出て来るとスワップ が頻発している。こういう状況だと cpu の us, sy 値も出て来る、通常は id が 100 で、 何もしてないアイドル状態が 100% である。ともかく日頃のマシンのこうした状態をワッ チしておくことが先ず必要である。それで、突発的に何か異常が起きているかどうか判断 がつくことになる。参考に何も負荷がかかってないマシンの状態を次に書いておく。 * vmstat コマンドで様子をみる Mail-Relay予備機でのマシン性能の様子である。メ−ルは受け取る環境にしてない。つま りネットワ−クから切り離して１台だけ置いている状態。何も負荷がかかっていない状態 である。本当は Apollo だけとはハブでつないで、Apollo から telnet している。 # vmstat 5 4 procs memory page disk faults cpu r b w swap free re mf pi po fr de sr f0 s3 s6 -- in sy cs us sy id 0 0 0 35052 89336 0 0 0 0 0 0 0 0 0 0 0 9 20 26 0 0 100 0 0 0 221504 88004 0 1 0 0 0 0 0 0 0 0 0 8 24 27 0 0 100 0 0 0 221504 88004 0 0 0 0 0 0 0 0 2 0 0 20 25 28 0 0 100 0 0 0 221504 88004 0 0 0 0 0 0 0 0 0 0 0 10 20 27 0 0 100 # ps -ef UID PID PPID C STIME TTY TIME CMD /bin/csh とかはのけた。 root 0 0 0 3月 15 ? 0:00 sched root 1 0 0 3月 15 ? 0:00 /etc/init - root 2 0 0 3月 15 ? 0:00 pageout root 3 0 0 3月 15 ? 0:26 fsflush root 274 1 0 3月 15 ? 0:00 inetd -s root 235 1 0 3月 15 ? 0:00 /usr/lib/saf/sac -t 300 root 100 1 0 3月 15 ? 0:00 /usr/sbin/rpcbind root 102 1 0 3月 15 ? 0:00 /usr/sbin/keyserv root 119 1 0 3月 15 ? 0:00 /usr/local/sbin/named root 140 1 0 3月 15 ? 0:00 /usr/sbin/cron root 131 1 0 3月 15 ? 0:00 /usr/sbin/syslogd root 146 1 0 3月 15 ? 0:00 /usr/sbin/nscd root 174 1 0 3月 15 ? 0:01 /usr/sbin/vold root 162 1 0 3月 15 ? 0:00 /usr/lib/power/powerd root 172 1 0 3月 15 ? 0:00 /usr/lib/utmpd root 638 1 0 17:49:02 ? 0:00 /usr/lib/sendmail -bd -q1h root 238 235 0 3月 15 ? 0:00 /usr/lib/saf/ttymon root 240 1 0 3月 15 ? 0:01 /usr/dt/bin/dtlogin -daemon root 201 1 0 3月 15 ? 0:00 ./_upsd メモ：powerd はマシンに最初からあった電源管理用。./_upsd は UPS のPowerChute。 * これまで知らなかった mailstats `28/09 [ sendmail にあった mailstats コマンド ] 記述が後先になるが、この Greet Pauseを検討をしている時に気付くことができればよか った。mailstats コマンドは sendmail が処理したメ−ルの数をカウントしていてくれる。 他のネットワ−ク管理している人らはどうやって、流れているメ−ルの数をかぞえている のかずっと不思議だった。各自、自前でスクリプトを書いているのか。それともフリ−ソ フトで何かプログラムがあって使っているのか。これまでいろいろ雑誌をみてきたが、こ の mailstats コマンドは。お目にかかったことがなかった。ようやく分かったぞ。 [ sendmail のソ−スプログラム ] # cd /usr/local/source # uncompress sendmail.8.13.8.tar.Z 例えばこのバ−ジョンので # tar xvf sendmail.8.13.8.tar # cd sendmail-8.13.8; ls -F Build* Makefile devtools/ libsmdb/ rmail/ CACerts PGPKEYS doc/ libsmutil/ sendmail/ FAQ README editmap/ mail.local/ smrsh/ INSTALL RELEASE_NOTES include/ mailstats/ test/ KNOWNBUGS cf/ libmilter/ makemap/ vacation/ LICENSE contrib/ libsm/ praliases/ mailstats は sendmail に付属するプログラムでだいぶ前からある。他にもいろいろある。 vacation は分かるが praliases というのは何。rmail も mail.local も smrsh とか？。 /etc/mail/sendmail.cf で関係するところを抜粋 ------------------------------------------------------------ |# persistent host status directory |#O HostStatusDirectory=.hoststat |# single thread deliveries (requires HostStatusDirectory)? |#O SingleThreadDelivery=False |# status file |StatusFile=/etc/mail/statistics [ mailstats コマンド ] # mailstats デフォルトで /etc/mail/statistics ファイルを見て 統計情報を表示する。sendmail とは独立している。 # mailstats -p 統計情報は簡略して表示される。statisticsファイル は０になる。カウントがクリアされるということ。 # cd /etc/mail 以下 /etc/mail ディレクトに入ってでの操作。 # mailstats -f statistics カレントディレクトリにファイルがあって指定した。 # mailstats -f sss この名前でコピ−しておいた。同じように表示される。 運用的には # mailstats -p を cron で実行する。sendmail.cf は/etc/mail/statistics を見るように設定すること。確認するには # grep statistics /etc/mail/sendmail.cfで StatusFile=/etc/mail/statistics が出て来ればＯＫ。 statistics ファイルがなければ その場で手作業で作ればいい、モ−ドはそのままでも 640 位でも。sendmail は再起動し なくとも直ちに統計情報を書き込む。 # mailstats -p の -p はカウントをクリアするの で、クリアする前に別なファイルにコピ−する。 cron で定期的にこのコマンドを実行す れば１週間とか１ヶ月単位で、メ−ルの流れている数を調べることができる。 [ メ−ルの数を数える ] hostB( Mail-Store ) の statistics ファイル ※統計情報という言い方は抵抗を感じる。ただ単純にカウントしているだけのこと。 sendmail-tx.mc では define(`STATUS_FILE',`/etc/mail/statistics')の指定はしてない、 しかしできた sendmail-tx.cf ファイルには、StatusFile=/etc/mail/statistics の記述 がされる。sendmail-8.12.10 の /usr/lib/mail/cf/Makefile で xxx.mc から xxx.cf を 作成すると、デフォルトで cf ファイルには /etc/mail/statistics を見るように記述さ れる。sendmail-rx.mc では別な名前の統計用ファイル statistics-rx を用意することに し、その旨定義した。でなければ同じ statistics ファイルを使って２重にメ−ル数を書 いてしまうことになる。しかし特に２ヶ所でメ−ル数をとる必要はないのでないか。多分 これらの差分を見れば InterScanが止めたウィルス入りメ−ルと eManager が止めたメ− ルの合わせた数は分かるはずである。もし /etc/mail/statistics,statistics-rx のファ イルがなければ手で作成すること。sendmail は再起動しなくても statisticsファイルを 作成した時点でメ−ルのカウントを始める。 # grep statis /etc/mail/*.cf sendmail-rx.cf:O StatusFile=/etc/mail/statistics-rx sendmail-tx.cf:O StatusFile=/etc/mail/statistics # /usr/bin/mailstats << デフォルトで /etc/mail/statistics を見る。 # /usr/bin/mailstats -f /etc/mail/statistics-rx << -f でファイル名を指定。 [ hostA でのこと ] sendmail-8.14.x では xxx.mc ファイルに define(`STATUS_FILE',`/etc/mail/statistic s') を記述しないと、xxx.cf ファイルに StatusFile=/etc/mail/statistics が出てこな い。それ以前のバ−ジョンではデフォルトで出ていた。どうも仕様が変わったらしい。本 当は hostB の Mail-Relay でメ−ルの数を取りたくて mailstats コマンドの検討を始め たのだが。Greet Pause で拒否したとか捨てたとかの数が分かるとうれしい訳で。 hostB の sendmail-8.14.1 で /etc/mail/sendmail.cf に statistics の記述がないので変だな と思った。調べたらどうもそのようだった、下記のリリ−スノ−トの説明がそう。 /usr/local/source/sendmail-8.14.1/RELEASE_NOTES の記述 ----------------------------------------------------------------------- |CONFIG: Make it possible to unset the StatusFile option by undefining | STATUS_FILE. By not setting StatusFile, the MTA will not | attempt to open a statistics file on each delivery. /etc/mail/sendmail.cf ----------------------------------- | | 先の xxx.mc で define で定義してないファイルとはここだけ異 |#0 StatusFile なる。cfファイルを作り直すまでもなく、直接に記述すればいい。 |0 StatusFile=/etc/mail/statistics | | (4) 予備機での Greet Pause 動作確認 * Mail-Relay 予備機のダミ−稼働 一度 Mail-Relay ホストに Greet Pause を設定したら、 本番で稼働中のマシンとすぐに 置き換えせずにおく。DMZ に仮り配置して様子をみてみる。多分、迷惑メ−ルはMXレコ− ド関係なしに送ってくるのもあるはずである。ポ−トスキャンで SMTP ポ−トが空いてい るホストを探したり、適当なＩＰアドレスにもどんどんメ−ルを送りつけているはずであ る。それをキャッチしてログを見てみる。/usr/sbin/syslogd デ−モンでシステムログを を取ってメ−ルがやって来るのを確認する。この "おとり" マシンに来るのはまともでな いメ−ルばかりな訳で、ログの /var/log/syslog ファイル中の discard の数と他の数と で、どれだけ変なメ−ルを Greet Pause で捨てているか計ることができる。 ： 仮想ＩＰ ダミ− Mail-Relay予備機のホスト名は □Router □hostA' ● 本番機のホスト名と同じである ｜.1 ｜.3 ｜.4 つまり hostname は hostAであ -------------------------------- 202.241.128.0 る。予備機だからＩＰアドレス |.2 □hostA ■ Mail-Relay予備機 以外 xxx.4で、他は本番機と同 FireWall-1-------.2 ｜.1 ｜.4 じ設定にしてある。 |hostG|------------------- 192.168.2.0 ------- □hostB Mail-Relay 本番と予備機はSun |.2 ｜.1 SPARCstation 5 (通称SS5)であ -------------------------------- 192.168.1.0 る。hostB,G は Sun V210。 << FireWall-1 の設定 >> FireWall-1 でのオブジェクトは、hostB は BB1、hostA の予備は AA2 にとりあえず する。AA2 は 192.168.2.4, External Host, Static 202.241.128.4 と定義する。 [Check Point SmartDashboard - Standard] -> [Security] NO.| SOURCE | DESTINATION | SERVICE ---|--------|-------------|---------- 1 | BB1 | AA2 | smtp 2 | AA2 | BB1 | smtp 3 | Any | AA2 | smtp 4 | AA2 | Any | smtp NO.3までのル−ルで、内部からも外部からのメ−ルも受けることができる。外には出 せない。予備機をこうして置くだけで外からのおかしげなメ−ルが一杯来るのでない か。NO.4のル−ルは予備機からメ−ルを外に出す場合に必要である。 * Mail-Relay 予備機の設定−その１ /etc/resolv.conf /etc/rc2.d/S72inetsvc ------------------------- ------------------------ |domain nix.co.jj |#/usr/local/sbin/named |nameserver 192.168.2.1 |#nameserver 192.168.2.4 DNS は hostA の named を見るようにする。 /etc/hosts # ping -s mail.nix.co.jj -------------------------------------------- PING hostA: 56 data bytes |127.0.0.1 localhost localhost.nix.co.jj 64 bytes from hostA (192.168.2.4): |192.168.2.4 hostA mail.nix.co.jj loghost |192.168.1.1 hostB # /usr/ucb/mail -v katou@nix.co.jj 内部にメ−ルを出してみる、ＯＫ。 # /usr/ucb/mail -v ikken@tcp-ip.or.jj 外部にメ−ルを出してみる、ＮＧ。 うまく行けば tcp-ip.or.jj のメ−ルサ−バにメ−ルは行って、そこで katou@nix.co.jj に転送されて戻って来るはずである。因に hostAからやったら、ちゃんとメ−ルは戻って 来た。しかし予備機からはメ−ルは行かずに、予備機の /var/spool/mqueueに溜まってし まった。"Deferred: Name server: tcp-ip.or.jj.: host name lookup failer"。 このホ ストから # ping www.tcp-ip.or.jj やると反応は返ってくる。#ping mail.nix.co.jj は この自分の /etc/hosts を見ても、sendmail は /etc/hosts を見ずに DNS を見る可能性 がある。するとＩＰアドレスが違っているわけで、そこら辺りで何か食い違いが起こるの かも知れない。次のその２で DNS の辺りをいじってみる。 * Mail-Relay 予備機の設定−その２ 上の予備機からメ−ルを出してみるで、メ−ルが行かなかった。この予備機のマシンでも named がいるような気配である。それで次のような DNS 制御ファイルで named デ−モン を動かしてみた。多分 sendmail デ−モンが sendmail.cf の中の mail.nix.co.jjホスト 名を検索するのに DNS を見ている。上記では見ることは見ているのだが、 本番機の DNS であり、mail.nix.co.jj のＩＰアドレスは 202.241.128.3 である。予備機での検索では 202.241.128.4 が期待されている訳で、その食い違いが何か悪さをしているのだろう。し かし素人さんは、このような一時的なロ−カルな namedデ−モンは、立ち上げたりしない こと。ちゃんと DNS の動きを理解したシステム・エンジニアが行なうこと。 このホストでも仮の named を動かす、# /usr/local/sbin/named &。飽くまでもこのマシ ンだけが参照するためのもの。/usr/local/etc/named.conf, named.local, named.caは本 番機のものと一緒である。/etc/hosts はその１に同じ。 /etc/resolv.conf ----------------------- |domain nix.co.jj |nameserver 127.0.0.1 /usr/local/etc/named.hosts /usr/local/etc/named.rev ------------------------------------------ ------------------------------------ |$TTL 300 |$TTL 300 |@ IN SOA ns.nix.co.jj. katou.nix.co.jj. ( |@ IN SOA ns.nix.co.jj. katou.ni.. ( | 10 300 100 3600000 300 ) ; | 10 300 100 3600000 300 ) ; | IN NS ns.nix.co.jj. | IN NS ns.nix.co.jj. | IN MX 10 mail.nix.co.jj. |3 IN PTR ns.nix.co.jj. |localhost. IN A 127.0.0.1 |2 IN PTR hostG.nix.co.jj. |ns IN A 202.241.128.3 |4 IN PTR mail.nix.co.jj. |hostG IN A 202.241.128.2 |;3 IN PTR mail.nix.co.jj. |mail IN A 202.241.128.4 |;mail IN A 202.241.128.3 # /usr/ucb/mail -v ikken@tcp-ip.or.jj もう一度メ−ルを出してみる、ＯＫ。 これで /etc/mail/access ファイルのアクセス制御の確認ができる。 * 予備機に Greet Pause を設定する /etc/mail/access --------------------------------- |Connect:192.168.1.1 RELAY |To:nix.co.jj RELAY |To:baka@nix.co.jj DISCARD |GreetPause:127.0.0.1 0 # cat VVV.mc Dwmail Dmnix.co.jj | FEATURE(`blacklist_recipients')dnl FEATURE(`greet_pause',`5000')dnl ５秒待つ。 # cd /etc/mail # makemap hash access < access # tail /var/log/syslog これで適宜メ−ルがやってきたか確認する。 何とこのマシンを設置してすぐに、１通のメ−ルがおとりに引っかかった。おかしいな−。 ３日間ぐらいログを見ていたつもりだったのだが、一体どこを見ていたのかな。ともかく ４日目ぐらい /var/log/syslogを見たらあった。でもそれ以降、１週間ぐらい経つが自分 がテストで出したメ−ルのログ以外でてこなかった。もうしばらく様子をみてみる。その 後１週間に１個ぐらい引っかかってきた、その一つは named がない時だった。 外からの メ−ルを受けるのには自分とこの DNS はなくても、今のところ概ね大丈夫ということ。 * 予備機を仮想ＩＰでなく実ＩＰで設置する どうもおとりにメ−ルが来ないのは、DefenseProがポ−トスキャンなどのアクセスをブロ ックしてしまっているので、ダミ−のメ−ルサ−バをｓｐａｍ屋さんが検索できないから でないか。重曝攻撃でたまたまおとりメ−ルサ−バにヒットしたのが、上の１通だったの でないか。ならば DefensePro に引っかからない所におとりを置いてみるか。それでバリ アセグメントにマシンを 202.241.128.5 として設置する。FireWall-1 でのオブジェクト の登録はしない。メ−ルを内部に中継する必要はない。バウンスメ−ルが外へそのまま出 ていくのはいやらしいが一時的なことなので、大義のため許せ。このマシンで namedを動 かさなければ、まともなメ−ルアドレスでなければ、メ−ル送信がエラ−で外には出て行 かないはずだ。おとりマシンでは外からのメ−ルを受けるだけにしよう。 * いろいろ動作確認 本番機から溜まっているキュ−のファイルをコピ−して、mc制御ファイルやスクリプトで いらんファイルを消してみたりする。confDOUBLE_BOUNCE_ADDRESS でヤフ−のバウンスメ −ルがどうなるか。confMAX_DAEMON_CHILDREN で sendmail デ−モンの数がどうなるかを 見る。ファイルのコピ−は、Mail-Relay 予備機の sendmailを停止させて行なった。ちな みにコピ−した後、直ぐにマシンをネットから切り離して単独で稼働させてみた。 named と sendmail は稼働。なんと全然 sendmail デ−モンが出て来ない。親プロセスと子プロ セス１個ずつのままだった。../crontabs/root で 0,5,10,.. * * * /usr/lib/newsyslog として５分毎にログを回転させるようにした。ログには "savemail panic" か "savemail : can not save rejected email anywhere" どちらかが出た。数はだいたい３０だった。 # mailq /var/spool/mqueue (213 requests) -----Q-ID----- --Size-- -----Q-Time----- ------------Sender/Recipient----------- l1L5BtLx002536 4394 Wed Feb 21 14:11 <> (Deferred: Connection timed out with mxtrix.matrix.com.bar.) l1L4r0Lx002398 2487 Wed Feb 21 13:53 <> (Deferred: 421 VS14-RT5 Mailbox bounce arrival rate exceeds s) 予備機にコピ−してきてメ−ルキュ−の様子を表示した。本番機と同じである。yahoo の Mailbox bounce arrival エラ−が、confDOUBLE_BOUNCE_ADDRESS の設定でどうなるか調 べてみた。yahoo.co.jp へのメ−ルがダブルバウンスメ−ルらしきエラ−メ−ルになって、 一杯 Mail-Relay でうろうろしいている。この設定で消えるか。# cd /var/spool/mqueue, # grep -l bounce * で見る。３０分に１０個ずつぐらい消えていった。一体 sendmailは どれぐらいのスピ−ドでメ−ルを処理しているのだ。sendmail -bd -q1h なら１時間ごと に /var/spool/mqueue のファイルを全部、なめるのでないのか。 (5) 本 Mail-Relay 制御ファイルの設定 * Mail-Relay 機で Greet Pause を設定する手順 予備機に sendmail-8.13.x をインスト−ルする。 スプ−ルに溜めておく日数を５日から３日にする。 マシンの状態を把握すること。メモリと CPU 負荷。 負荷軽減のため sendmail のプロセス数を制限する。 "User unknown" のファイルを消す。スクリプト用意。 システムログをとるようにする。メ−ルを計測すること。 sendmail が扱うメ−ルの最大の大きさを設定する。 Greet Pause の時間とホワイトリスト／ブラックリスト。 予備機と稼働しているマシンを置き換える。 * 自動的に整理するプログラム or スクリプト 1) スプ−ルに溜めておく日数を３日にする /usr/local/source/sendmail-8.13.8/cf/cf/VVV.mc /etc/mail/sendmail.cf ---------------------------------------------- ------------------------- |define(`confTO_QUEUERETURN',`3d')dnl |O Timeout.queuereturn=3d |define(`confTO_QUEUEWARN',`4h')dnl |O Timeout.queuewarn=4h 他にも Timeout.xxx というのは一杯あるがコメントになっていた。 デフォルトで有効に なっているのは queuereturn=5d と queuewarn=4h だけである。queuereturn は５日間再 送を繰り返しそれでも送れなかった時、駄目でしたと発信者にメ−ルを出し、キュ−のメ −ルを消す。queuewarn は再送を繰り返している間に、４時間経ったらまだ再送を試みて ますと発信者にメ−ルを出す。その後、また４時間経ったらこのメ−ルが出るのかは不明、 多分また出るのでないか。いろいろ話を聞くに queuereturn=5d は長過ぎ、 ３日間の 3d にしているとか。queuewarn の方は自分の見解だが、発信者にいちいち報告しなくてもい いのではないか。0 にすると通知しないことになるらしいが、今一度確認したい。 2) "User unknown" などが出ているファイルを消去する "User unknown"のファイルで、１時間以上滞留しているのは消去する。直ちに消去すると、 たった今処理しようとしているのまで消してしまうかも。自社側にユ−ザがいなくて、相 手に送りかえすのに相手はユ−ザがちゃんといれば、即送り返すはずである。cronで１時 間毎に処理するようにしようか。他にも mailq で溜まっているメ−ルがある。2007/04の ある時点で全体 521、"User unknown" 198、"bounce" 88、"yahoo" 179、"katou" 102 だ った。重複しているのもある、mailq で見ると "bounce" のほとんどは "yahoo"のである。 "katou" は Postmaster 宛のメ−ルを aliase して内へ送っているのだが、DefenseProで 止められているメ−ルである。いっそ Postmaster 宛は Mail-Relay で消してしまうか。 いらんファイルを手作業で消去する # cd /var/spool/mqueue; grep -l yahoo * | xargs rm Mail-Relay の /etc/mail/access /etc/aliases ダメ Postmaster宛をMail-Relay -------------------------------- ------------------ で捨てる。aliases の設定 | | |nobody: /dev/null でできそうだがだめだった |To:postmaster@nix.co.jj DISCARD |Postmaster:nobody access のDISCARDで捨てる。 3) ユ−ザのいないアドレスへのメ−ルは受け取らない 毎度やってくる退職した人ヘの迷惑メ−ルは、もう全部捨ててしまえ。Mail-Storeでアカ ウントを消去した数人へのメ−ルが一杯来る。内容は全部が迷惑メ−ル。そういうメ−ル は Mail-Relay に戻され、行き場を失って溜まる。# mailq で見ると分かる。mcファイル でブラックリストを使うことを定義し、該当メ−ルアドレスを /etc/mail/access に書く。 これで Mail-Store に行くことなく、Mail-Relayで直ちに破棄される。もう一つ破棄する やり方がある、Mail-Sotre の /etc/aliases に "katou:/dev/null" などとする。しかし Mail-Sotre の /etc/passwd にアカウントを記載しておく必要があり、いやらしい。 VVV.mc /etc/mail/access ------------------------------------ ---------------------------- |FEATURE(`blacklist_recipients')dnl |To:baka@nix.co.jj DISCARD 4) システムログについて Mail-Relay のホストはディスク容量がそんなに大きくない。 /var/log/syslog ファイル サイズを決めることにする、いやそれはできんか。Mail-Storeが１週間単位のログになっ ていて、だいたい 20MB である。Mail-Relayでは日毎のログを取ることにする。またその 方がメ−ルの数をカウントしやすい。ディスク容量を見ながら先ずは１週間分をとる、大 丈夫なようであれば１ヶ月にする。ログは手短に取ることにする。discard, reject など が分かればいいレベルでログを出すようにする。ログのレベルはデフォルトは 9 である。 /etc/mail/sendmail.cf --------------------- |O LogLevel=4 にする。 上の設定で Greet Pause で弾いたメ−ルの数がおよそ分かる。 # cd /var/log # find syslog.0 -exec grep "from" {} \; | wc -l 5) 大量メ−ルの負荷を軽減する VVV.mc で定義しなくても sendmail.cf の次のところを直接いじってもいい。シャ−プの コメントを外せばいい。MaxDaemonChildren は 12、ConnectionRateThrottleは 3 という 値を本などで見た。本番 Mail-Relay の # ps -ef を見ると sendmail のプロセスは１８ 個前後である。メ−ルの一斉の時に見たのが２４個ぐらい。２０個ぐらいまではいけそう である。メ−ルの一斉の様子、パソコンからそういうソフトで送るのだが、担当者によれ ばひとつふたつというぐらいで送っている。１秒間に２回ぐらいみたいである。パソコン から Mail-Store に行き、すぐに Mail-Relay に渡す。そこで処理が追い付かずにマシン がエラ−を起こす。 ConnectionRateThrottle でメ−ルをどれだけ受け付けるかを制限で きるのだが、とりあえず設定しないでおく。MAX_DAEMON_CHILDREN で先ずは様子をみる。 /etc/mail/sendmail.cf デフォルトの状態 ---------------------------- |#O MaxDaemonChildren=0 英語直訳、一度期に許す子プロセスの最大数。 |#O ConnectionRateThrottle=0 １秒間当たりの新しいコネクションの最大数。 VVV.mc で定義してもいいし、sendmail.cf を直接いじってもいいだろう。 ------------------------------------------------- |define(`confMAX_DAEMON_CHILDREN',`20')dnl これらは sendmail-8.12.5 に |dnl define(`confConnectionRateThrottle',`3')dnl すでにあった。 6) sendmail が扱うメ−ルのサイズを設定する これまではメ−ルのサイズに制限は設けていなかった。ウィルスチェックの InterScanで 制限をかけていた。５メガとかしている。外からのメ−ル爆弾、メ−ルがたくさん送られ るのでなく、サイズがでかいのが来た場合の対処を考えなければならない。これまで幸い 迷惑メ−ルといってもサイズは比較的小さかった。しかし、本当に迷惑をかけるのが目的 のメ−ルなら、超でかいサイズのメ−ルを送り付けてもおかしくない。 VVV.mc ----------------------------------------------- |define(`confMAX_MESSAGE_SIZE', `10485760')dnl １０ＭＢのメ−ルの本文と添付。 7) Greet Pause の時間とホワイトリスト／ブラックリスト フリ−ソフトの MAD Suffer メ−ルアドレス収集ツ−ル。こんなのでメ−ルアドレスを収 集するか。ホワイトリスト／ブラックリストどちらでいくか。Greet Pause を０以上にす るか、０にするか。完全に分かっているところは０にすべきだろう。取り引き先であると か、ｓｐａｍ発信源でないところを列挙し０にする。しかし全く問題がないということで はない。エンベロ−プを取り引き先のドメイン名にして、偽造してくることは有り得る。 * sendmail 用 mc ファイル # cd /usr/local/source/sendmail-8.13.8/cf/cf # cat VVV.mc Dwmail Dmnix.co.jj VERSIONID(`Mr. Ikken Katou: 2007/03/15') OSTYPE(solaris2)dnl dnl DOMAIN(generic)dnl undefine(`UUCP_RELAY')dnl undefine(`BITNET_RELAY')dnl FEATURE(`nouucp',`reject')dnl define(`confPRIVACY_FLAGS',`goaway')dnl define(`confDOMAIN_NAME',`$w.$m')dnl define(`always_add_domain')dnl MASQUERADE_AS(`nix.co.jj')dnl MASQUERADE_DOMAIN(`nix.co.jj')dnl FEATURE(`masquerade_entire_domain')dnl FEATURE(`nocanonify',`canonify_hosts')dnl FEATURE(`accept_unresolvable_domains')dnl FEATURE(`accept_unqualified_senders')dnl define(`confMAX_HEADERS_LENGHT',`32768')dnl define(`confMIME_FORMAT_ERRORS',`False')dnl define(`confTO_COMMAND',`5m')dnl define(`confTO_DATABLOCK',`5m')dnl define(`confDOUBLE_BOUNCE_ADDRESS', `')dnl ダブルバウンスメ−ルを捨てる。 define(`confMAX_DAEMON_CHILDREN',`20')dnl sendmail デ−モンの最大数を２０に。 define(`DATABASE_MAP_TYPE',`hash')dnl hash がデフォルト。 一応明示してみた。 define(`confMAX_MESSAGE_SIZE', `10485760')dnl 本文と添付合わせて最大１０ＭＢ。 define(`confTO_IDENT',`0s')dnl IDENT 認証は使わない。ポ−トは 113番。 FEATURE(`no_deafult_msa')dnl Message Submission Agentを使用しない。 FEATURE(`blacklist_recipients')dnl FEATURE(`greet_pause',`5000')dnl これが今回の肝心な設定。 FEATURE(`mailertable')dnl FEATURE(`access_db')dnl MAILER(local)dnl # sh Build VVV.cf # cp VVV.cf /etc/mail/sendmail.cf sendmail.cf を作って修正する。 --------------------------- | | |O Timeout.queuereturn=3d |O Timeout.queuewarn=4h |O LogLevel=4 | | 一つ注意。つい下のように conf 何がしと書いてしまうとこである。hashがデフォルトで、 正 define(`DATABASE_MAP_TYPE',`hash')dnl は 誤りの方の記述でも Build してで 誤 define(`confDATABASE_MAP_TYPE',`hash')dnl きる xxx.cfファイルは同じである。 * /etc/mail/access ファイルの基本の記述 /etc/mail/access --------------------------------- |Connect:192.168.1.1 RELAY 1) Mail-Store からのメ−ルは中継する。 |To:nix.co.jj RELAY 2) 普通は外部から自社へのメ−ルになる。 |nix.co.jj RELAY 3) Connect:nix.co.jj ということ。 | |To:baka@nix.co.jj DISCARD 社内メ−ルユ−ザのブラックリスト。 |To:kaba@xyz.co.jj DISCARD 社外メ−ルユ−ザのブラックリスト。 | |GreetPause:127.0.0.1 0 自社のメ−ル環境でのホワイトリスト。 注、2) はメ−ルのエンベロ−プの宛先が nix.co.jj のは中継する。しかし偽造されてい る可能性はある。3) はSMTPアクセスして来たＩＰアドレスから DNS でドメイン名を検索 する、または Mail-Relay ホストの /etc/hosts ファイルでホスト名を検索しドメイン名 を調べる、そして nix.co.jj なら中継する。3) は気なしにこれまで入れているル−ルな のだが、よくよく見れば 1) のル−ルでカバ−されるので無くてもいいと思う。 * /etc/mail/access のアクセス制限のまとめ このファイルで制限できるのは、Connect: と From: ではどこからのメ−ルかということ。 メ−ルアドレス、ドメイン、ＩＰアドレス、ユ−ザ名で制限ができる。To: では宛先を制 限する。もうおかしなメ−ルは REJECT で相手に拒否しましたと知らせるのでなく、黙っ て捨てる DISCARD で十分である。 ・access の From: と To: はエンベロ−プを見る。メ−ル本文のではない。 ・access の Connect: は送信元のＩＰアドレスかホスト名を見る。 ・タグなしは Connect 指定になる。ＩＰアドレスかホスト名を見る。 /etc/mail/access 送信元のＩＰアドレス/ホスト名を見る。 接続してき ---------------------------- たホストがちゃんと 192.168.1.1かチェックする。次 |Connect:192.168.1.1 RELAY の nix.co.jj は、 接続してきたＩＰアドレスを元に |Connect:nix.co.jj RELAY DNSでホスト名/ドメイン名を検索する。 ---------------------------- 送信元のドメイン名が ac.jjからのメ−ルは拒否する |Connect:ac.jj REJECT が、zzz.ac.jj のメ−ルは受ける。REJECT,OK の順番 |Connect:zzz.ac.jj OK は関係ないみたい。Connect: は相手は偽造できない。 ---------------------------- これら Connect: 指定になる。送信元のＩＰアドレス |192.168.1.1 OK を見る。 送信元が 192.168.1.0 - 255 までは廃棄す |192.168.1.0 DISCARD るが 192.168.1.1 のメ−ルは受ける。 ---------------------------- これらエンベロ−プを見る。メ−ルアドレスで廃棄。 |From:spam@spam.con DISCARD 完全に一致したメ−ルアドレスで廃棄。 |From:spam@ DISCARD ユ−ザ名で廃棄。ドメインは何でもいい。 |From:@spam.con DISCARD ドメインで廃棄。ユ−ザ名は何でもいい。 |From:spam.con DISCARD ドメインで廃棄。サブドメイン sub.spam.con も廃棄。 | |To:kaba@nix.co.jj DISCARD こちらは宛先メ−ルアドレスで廃棄。指定はFrom同様。 当初 access ファイルの制御では "To:kaba@nix.co.jj" という指定は RELAY と OK の指 定が有効だった。中継または受け付けるエンベロ−プの宛先メ−ルアドレスを access の To: に記述した。中継は受け付けも含んでいる。mcファイルに blacklist_recipients を 定義すると、To: の記述に DISCARD と REJECT それに ERROR の指定もできるようになる。 access の From: については、当初から全部の指定ができる。 ------------------------------------------------------------------------------------ [ 付録 ] これまで知らなかった mailstats `28/09 * hostB でメ−ル数を取ってみた 実稼働の Mail-Store でメ−ル数をカウントしているところである。２つの sendmail の の統計情報なわけだが、どうやって見たらいいか正直いってよく分からない。ともかくメ −ル数を取り始める時刻を同じにしないといけないなと思う。 # cd /etc/mail # mailstats -f statistics-rx Statistics from Thu Sep 18 12:34:21 2008 M msgsfr bytes_from msgsto bytes_to msgsrej msgsdis Mailer 4 979 80650K 1015 81282K 0 0 smtp 8 357 1688K 0 0K 0 0 relay ============================================================= T 1336 82338K 1015 81282K 0 0 C 1015 988 0 # mailstats Statistics from Thu Sep 18 12:30:13 2008 M msgsfr bytes_from msgsto bytes_to msgsrej msgsdis Mailer 3 652 37215K 448 38151K 0 0 local 4 283 5368K 488 4618K 0 0 smtp ============================================================= T 935 42583K 936 42769K 0 0 C 1072 488 0 mailstats コマンドを叩いたのは９月１８日の15時26分。statistics-rx の 12:34:21 は statistics-rx ファイルを作成または -p オプションで初期化した時刻である。12:34:21 は現在の時刻ではない。同じく 12:30:13 は statistics ファイルの方である。 msgsfr : メ−ラからのメ−ル数、bytes_from: メ−ラからの KBytes 数 msgsto : メ−ラへのメ−ル数、 bytes_to : メ−ラへの KBytes 数 msgsrej: 拒否されたメ−ル数、 msgsdis : 捨てられたメ−ル数 * hostG でもやってみた こちらは hostG に入って、メ−ルコマンドで自分宛に３回メ−ルしたところである。 メ −ルは hostGの submit.cf が受け、hostB Mail-Store に hostG の sendmail.cf で中継 する。mailstats の statistics と sm-client.st の表示で、３通のメ−ルを扱ったこと が出ているのが見える。 # mail katou@nix.co.jj ３回やった。 # mailstats Statistics from ... 略 M msgsfr bytes_from msgsto bytes_to msgsrej msgsdis Mailer 3 3 3K 0 0K 0 0 local 8 0 0K 3 3K 0 0 relay ============================================================= T 3 3K 3 3K 0 0 C 4 3 0 /etc/mail/submit.cf で関係するところを抜粋 ----------------------------------------------------------- |# persistent host status directory |#O HostStatusDirectory=.hoststat |# single thread deliveries (requires HostStatusDirectory)? |#O SingleThreadDelivery=False |# status file |O StatusFile=/var/spool/clientmqueue/sm-client.st /var/spool/clientmqueue/ には sm-client.pid ファイルがあった。 sm-client.st はな かったので作成した。作成したままではメ−ルを出しても sm-client.st に変化はなかっ た、カウントをしなかった。それで # chmod 600 sm-client.st それにオ−ナ−とグル− プも smmsp に変えた。#/etc/rc2.d/S88sendmail restart やった。S88sendmail restart は一瞬で終わった。sendmail のプロセスＩＤにハップを送っただけなのか。 ともかくこ れでこのマシンでメ−ルを出したら sm-client.st にもカウントが取られ始めた。 # cd /var/spool/clientmqueue # mailstats -f sm-client.st Statistics from ... 略 M msgsfr bytes_from msgsto bytes_to msgsrej msgsdis Mailer 3 3 3K 0 0K 0 0 local 8 0 0K 3 3K 0 0 relay ============================================================= T 3 3K 3 3K 0 0 C 4 3 0