17-6. メ−ルサ−バの能力について `27/05 (1) ダイレクトメ−ルによる大量メ−ル `27/05 * Mail-Relay のワ−ニングが出た時 社内から顧客ヘのメ−ルの一斉配信で、Mail-Store から Mail-Relayへどんどんメ−ルが 来て、マシンが悲鳴を上げた時の状態である。普段の状態では # vmstat コマンドでpage と disk のところは、ほとんどが 0 とか 1〜5 程度の値である。それが page の pi, po の値がすごいことになっている。メモリのスワップが頻発している。sendmailの数は普段 15から20個ぐらいが、33個もできていた。もうこうなると # ps -ef とやってもす ぐには出て来ない。3分ぐらいしてやっと全部、出てきた。まだ # ps -e とやった方が すぐに出て来る。WARNING が出て来るともうマシンは機能不全に陥っている。仕方ないの で # /etc/rc2.d/S88sendmail stop で sendmailを止め、/etc/mail/sendmail.cf のパラ メ−タを調整してから、# /etc/rc2.d/S88sendmail start させるしかない。 ダイレクト メ−ルの送信もやめてもらった。この時点で Mail-Store のメ−ルキュ−に4000個ぐ らいファイルが溜まっていた。Mail-Relay には2000個ぐらい溜まっていた。 # date Fri Apr 27 15:51:24 JST 2007 # vmstat 5 4 procs memory page disk faults cpu r b w swap free re mf pi po fr de sr f0 s1 s3 s6 in sy cs us sy id 0 0 0 1188 168 0 19 3 2 5 0 3 0 2 1 0 70 98 105 1 1 98 1 0 0 108372 1448 29 562 202 148 240 0 96 0 37 53 0 439 1338 423 12 32 56 0 0 0 108876 1320 31 659 97 141 229 0 100 0 36 26 0 323 1413 339 16 33 51 1 0 0 108260 1292 30 675 136 145 283 0 152 0 35 37 0 327 1267 329 16 32 52 # WARNING: Sorry, no swap space to grow stack for pid 12855 (sendmail) /etc/mail/sendmail.cf 大量のメ−ル発信をしている時に変更した。 ---------------------------- |O MaxDaemonChildren=20 |0 ConnectionRateThrottle=1 これで sendmail は20個までしか出ないはずだが、いっぱい出てきた。ディスプレイに 一杯、数えたら73個も sendmail ができていた。しかしスワップエラ−は出て来なかっ た。これは金曜日の夜9時までメ−ルサ−バの様子を監視していたことである。この設定 で自宅に帰り、メ−ル転送によりメ−ルサ−バの様子を休みの間みていた。月曜出勤した ら Mail-Store のメ−ルキュ−は空、 Mail-Relay は前から溜まっている500個ぐらい の数になっていた。ダイレクトメ−ルは何とか配送できたわけである。 * 社内から外への大量メ−ル配信 社内のパソコンから1個ずつ、ダイレクトメ−ルを1秒間に約2個メ−ル出す。営業部門 が Windowsのメ−ル配送ソフトで1万通ぐらい顧客にメ−ルを送っている。2000通ず つ分けて送るのである。パソコンではそのソフトがメ−ルを送る様子が出ていて、それで カウントした。安いソフトなのでメ−ルの送信間隔を変えたりはできない。 Mail-Relayはメ−ルを外に出すのに、1つ2秒から3秒で処理している。皆が帰った20 時頃。Mail-Store はパソコンからのメ−ルは全部受けて、 メ−ルキュ−に溜まっている。 Mail-Relay にも溜まっている。sendmail を全部止めて、# sendmail -q & とやった。こ れで /var/spool/mqueue/ の数を、5分間隔で何回か # ls -l | wc -l で数えてみた。 Mail-Store では1秒間に2通以下のメ−ルを Mail-Relayへ送っている。ダイレクトメ− ルを送信し始めた16時頃の1分、#grep -l "Apr 27 16:01" /var/log/syslog というよ うにやって1分間のログを表示した。ほとんどがダイレクトメ−ルのアドレスが続いてい た。ログの数は例えば 280, 481, 268, 393 で、この1/4がおよそのメ−ルの数である。 送信ソフト *** *** Windowsからは1秒に2個。 --------- *** ------------ ** ------------ * Mail-Store は1秒に2個 |Windows|--------|Mail-Store|--------|Mail-Relay|------ 以下、毎分 70〜120 個。 | | -> | ******** | -> | ******** | Mail-Relay は3秒に1個 --------- ------------ ------------ 外へ、受信は1秒に2個。 パソコンからの大量メ−ルを Mail-Store へ送ると、最初はエラ−なしでどんどん受ける。 そして Mail-Relay へそのまま送る。ある程度送ると Mail-Relay は受け付けられなくな り、timeout とか refuse のログが出るようになる。しまいにはそのログが続くことにな る。Mail-Relayは外ヘ出すのに1メ−ル数秒かかる。受けるのは1秒間に2通は受けるこ とができる、そのギャップが異常を引き起こす元になる。Mail-Relayではメ−ルを受ける 流量を絞る、sendmail の数もメモリ・オ−バ−にならないよう制限しなければならない。 * Mail-Relay の Sun のマシン SS5 なんとかしなくては。ディスクがくたってきて暗騒音が結構する。自分のすぐ後で唸 っているが、気ばかりがあせってやれない。こういう検討が一番、時間がかかる。しかし 今後5年間ぐらい、メ−ルサ−ビスをどうしていくかというマクロ的な観点で検討してい る訳だから、時間が少々かかるのは仕方ないか。mqueueに溜まっていた3000余りのフ ァイルは、いろいろやった結果400から500ぐらいに押えることができた。 unknown なファイルも消せば30ぐらいにできる。マシンの性能は現状足りているか。返り先不明 のメ−ルで再送を繰り返して sendmail の数を増やしている。しかし外からメ−ルを送っ てエラ−メ−ルで返って来るのは即、瞬時に返ってくる。パソコンのメ−ルソフトで受信 をクリックとかやっている間に戻ってくる。とりあえず今のところメ−ルリレ−は、正常 に稼働しているといえる。メ−ルが溜まらないようにすれば、多分まだ凌げる可能性はあ る。いやもう限界だと思う。パフォ−マンス不足になってきている。 * マシンの性能指針のロ−ドアベレ−ジ `27/06 懇意にしているSI業者のエンジニアさんにも教えてもらった。我々はどこを見ているか といえば、ロ−ドアベレ−ジ(平均負荷)の値。vmstat コマンドの左端から出る r b w の r 値であって、CPU の数が1個のマシンであれば、だいたい 1、それ以上の値になってい る場合は負荷がかなりかかっている状態と判断する。CPU が2個なら 2前後の値なら正常。 やっと分かってきた、何となく頭にすっと入ってきたぞ。ロ−ドアベ−レ−ジとは、実行 キュ−の長さと現在 CPUで実行されているジョブ数の合計である、「SPARC&Solaris パフ ォ−マンスチュ−ニング」P.110 より。他の所の説明では、処理待ちのプロセス数を言う。 uptime の(1)(2)(3) がこの値を示しそれぞれ1分、5分、15分間の平均値である。 # uptime Solaris 9 での表示。Solaris 2.6 でも同じ。 (1) (2) (3) 午後 1時44分 稼働 145 日間, 3:39, 2 users, 平均負荷率: 0.17, 0.12, 0.12 SNMP の MIB 情報でもロ−ドアベレ−ジの値を知ることができる。マシンに NET-SNMP ソ フトを入れる。マネ−ジャとエ−ジェント両方の機能があり、下記のように#snmpwalk コ マンドで出て来る。OID番号は 1(iso).3(org).6(dod).1(internet).4(private).1(enterp rise).2021(ucdavis).10(laTable).1(??).3(laLoad)。2021(ucdavis) は NET-SNMPが取り 決めしたものみたい。詳しくは http://net-snmp.sourceforge.net/。 # snmpwalk -v 1 -c local localhost 1.3.6.1.4.1.2021.10.1.3 UCD-SNMP-MIB::laLoad.1 = STRING: 1.15 1分間平均のロ−ドアベレ−ジ UCD-SNMP-MIB::laLoad.2 = STRING: 0.24 5分間平均のロ−ドアベレ−ジ UCD-SNMP-MIB::laLoad.3 = STRING: 0.09 15分間平均のロ−ドアベレ−ジ 「Software Design」2006/08, "SD巻末リファレンス vo.19, ネットワ−ク監視の現場で > 役立つ SNMP MIB 厳選リファレンス"。フリ−ソフトの NET-SNMP で MIBブラウズする。 「Software Design」2003/02, "Webシステムチュ−ニングパ−フェクトガイド"。 > 1章Webシステムのボトルネックを探せ、P.112〜121、vmstat, uptime, netstat。 * 2007年頃に作った sendmail.cf 2017年7月のこと。社内から外部へ送ることができないメ−ルアドレスが1つあった。 メ−ルリレ−のマシンの /var/spool/mqueue/ に溜まっていた。何らかの原因で相手のメ −ルサ−バとのやりとりで時間がかかって、失敗しまっているようである。ちょっとばか り原因は分からない。ひょっとして sendmail.cf の Timeout パラメ−タをいじれば行く ようになるのでないか。とりあえずその部分をだしてみた。しかしどれをいじればいい?。 # cd /var/spool/mqueue/ # grep xjapan.com * "qfv632xxx:MDeferred: 接続が時間切れです。with www.xjapan.con." /etc/mail/sendmail.cf ----------------------------------------------------------------------- | | |###################################################################### |###################################################################### |##### |##### SENDMAIL CONFIGURATION FILE |##### |##### built by root@hostA on Thu Nov 8 13:05:09 JST 2007 |##### in /usr/xxx/SOFTWARE/FREE_SOFT_SOURCEs/sendmail-8.14.1/cf/cf |##### using ../ as configuration include directory |##### |###################################################################### |##### |##### DO NOT EDIT THIS FILE! Only edit the source .mc file. |##### |###################################################################### |###################################################################### | | |# timeouts (many of these) |#O Timeout.initial=5m |#O Timeout.connect=5m |#O Timeout.aconnect=0s |#O Timeout.iconnect=5m |#O Timeout.helo=5m |#O Timeout.mail=10m |#O Timeout.rcpt=1h |#O Timeout.datainit=5m |O Timeout.datablock=10m |#O Timeout.datafinal=1h |#O Timeout.rset=5m |#O Timeout.quit=2m |#O Timeout.misc=2m |O Timeout.command=10m |O Timeout.ident=0s |#O Timeout.fileopen=60s |#O Timeout.control=2m |O Timeout.queuereturn=3d |#O Timeout.queuereturn.normal=5d |#O Timeout.queuereturn.urgent=2d |#O Timeout.queuereturn.non-urgent=7d |#O Timeout.queuereturn.dsn=5d |O Timeout.queuewarn=4h |#O Timeout.queuewarn.normal=4h |#O Timeout.queuewarn.urgent=1h |#O Timeout.queuewarn.non-urgent=12h |#O Timeout.queuewarn.dsn=4h |#O Timeout.hoststatus=30m |#O Timeout.resolver.retrans=5s |#O Timeout.resolver.retrans.first=5s |#O Timeout.resolver.retrans.normal=5s |#O Timeout.resolver.retry=4 |#O Timeout.resolver.retry.first=4 |#O Timeout.resolver.retry.normal=4 |#O Timeout.lhlo=2m |#O Timeout.auth=10m |#O Timeout.starttls=1h | | (2) Mail-Store で流れているメ−ルの数 `27/04 * Mail-Store でのメ−ルの流量の計測 これでおおよそのメ−ルの数が分かる。 Mail-Store ではメ−ルは sendmail を2つ通る ので、以下の find で出た数の半分がメ−ルの数になる。"User unknown"メ−ルを除くと 1日当り5800通飛び交っている。 # cat /etc/aliases | □hostA nobody: /dev/null ------- |.1 Postmaster: katou@nix.co.jj |hostG|---------- ------- □hostB # cat /etc/aliases | |.1 nobody: /dev/null ------------------ Postmaster: katou # cd /var/log # find syslog.0 -exec grep from {} \; | wc -l << 1週間分のログ。メ−ルの全数。 51551 # find syslog.0 -exec grep unknown {} \; | wc -l << unknown になったメ−ル数。 10781 # find syslog.0 -exec grep katou {} \; | wc -l << ほとんどが katou宛のメ−ル数。 6734 Mail-Relay から出る Postmaster 宛のエラ−メ−ルを katou@nix.co.jj で受けての数で ある。毎日100から200。"User unknown" のメ−ルは katou 宛のメ−ルが大半かと 思われる。ずっと Mail-Relay で "Postmaster: katou"としていた。これではメ−ルがエ ラ−になって、Mail-Relay の /var/spool/mqueue/に3000位のファイルが常時あった。 "Postmaster: katou@nix.co.jj" に修正したら、しばらくしてそれが500から600個 位になり、その分 katou@nix.co.jj へ実際に届くようになった。 * hostA で "Postmaster: nobody@nix.co.jj" にした # find syslog -exec grep nobody {} \; | wc -l 5日間分のログ、約3千。メ−ルの 2931 数はその半分で、1日当たり3百通。 Mail-Store で nobody@nix.co.jj 宛のメ−ルを /etc/aliases で捨てた様子。 このメ− ルは Mail-Relay の Postmaster からでたものである。 nobody@nix.co.jj に別名展開さ れて Mail-Store の /etc/aliases で /dev/null された。 /var/log/syslog 記述はできるだけ省略してある -------------------------------------------------------------------------------- |AAA: from=<> msgid= daemon=MTA-RX relay=hostA [202.241.128.3] |BBB: from=<> msgid= daemon=MTA relay=localhost [127.0.0.1] |AAA: to= relay=127.0.0.1, stat=Sent (BBB Message accepted ..) |BBB: to=/dev/null ctladdr= mailer=*file* stat=Sent [設定]->[ログ]->[eManagerログ]で{今日}をクリックすると、今日の午前0時からのメ− ルで検出されたのが上からリストされる。送信者なし、受信者 postmaster@nix.co.jj が、 [ポリシ−管理]->[隔離領域]で見ると、送信者なし、受信者 nobody@nix.co.jj と出て来 る。メ−ルのヘッダ−は{詳細}の[表示]をクリックすると下のように出る。メ−ルの本文 までは出て来ない。隔離されたメ−ルのペ−ジの画面で、該当メ−ルだけ〆を残し他のメ −ルは〆を外す。この状態でメニュ−の[配信]をクリックすると宛先へメ−ルが行き、リ ストから削除される。宛先は変えることはできない。eManagerのキ−ワ−ドによるフィル タ−はあまり賢くない。いやらしい単語を登録するのだが、全然違う文字列でもその前後 の文字列で、登録した単語に合致すると認識してしまう。これは気を付けたいところであ る。また文字列にワイルドカ−ド "?" や "*" は使えない。 [ポリシ−管理]->[隔離領域] のメニュ−でメッセ−ジ{表示} では、送信者なし、受信者 nobody@nix.co.jj と出てきた。[ポリシ−管理]->[クエリ] { nobody@nix.co.jj} で検索 したら 513件出てきた。しかし、これら出て来る順番はでたらめで日付順になっていない。 ---------------------------------------------------------------------- |メッセ−ジ内容の詳細 件名など日本語はちゃんと表示する |--------------------------------------------------------------------- |受信: from mail.nix.co.jj (hostA[202.241.128.3])by hostB.nix.co.jj | with ESMTP id xxxx for ; Sat,14 Apr 2007 .. |送信者: |From: Mail Delivery Subsystem |宛先: postmaster@nix.co.jj |件名: Postmaster notify: see transcript for details ---------------------------------------------------------------------- * /etc/aliases ファイルの注意 hostA □Mail-Relay hostB □Mail-Store /etc/aliases ファイルを変更 | |.1 したら # newaliases をやる。 --------------------‖---------------------- sendmail は止めなくてもいい。 /etc/aliases /etc/aliases メ−ル送信のテスト 1)..4)は --------------------- ------------------ Mail-Relay で行なった。メ− |nobody: /dev/null |nobody: /dev/null ルは Mail-Storeに行くという |root: tomo@nix.co.jj |root: kato ものである。 |#Postmaster: |Postmaster: kato 1)# mail root とやると tomo@nix.co.jj へ行く。 2)# mail root@nix.co.jj とやると kato@nix.co.jj へ行く。これも不可解。 3)# mail postmaster とやると Mail-Relay でエラ−になりメ−ルは消える。 4)# mail postmaster@nix.co.jj とやると kato@nix.co.jj へ行く。 不可解なのは3) どう解釈したらいいのか。/var/log/syslog に "Warning: program /usr /lib/mail.local unsafe: Group writable directory" とログが出ていた。postmaster宛 のメ−ルは Mail-Relay の postmaster ユ−ザ宛に送ろうとする、しかし Mail-Relay の /etc/passwd には postmaster は書かれてなかった。 この実験をやった時は Mail-Relay の sendmail.cf でドメイン名を補う設定はしてなかったのだと思う。 ドメイン名を補間 していれば # mail root は # mail root@nix.co.jj と解釈されてメ−ルは行ったはずで ある。2) でもドメイン名が補間されていれば /etc/aliases の "root: tomo@nix.co.jj" は "rootnix.co.jj: tomo@nix.co.jj" と解釈されて、tomo@nix.co.jj へメ−ルは行った のでないか。なかなか微妙なところである。できればもう一度確認したいものだ。 (3) 負荷対応 sendmail.cf パラメ−タ * 負荷対応パラメ−タのポリシ− いつメ−ル爆弾の標的になるかわからない。ダブルバウンスメ−ルで返信アドレスを自社 にされて大量のメ−ルをばらまかれたら。簡単にやられてしまう。ぼちぼち来る、ただの 迷惑メ−ルはまだ可愛らしい。そういう場合 Mail-Relay ではどう対処したらいいか。ま ずできることは、Mail-Relay でメ−ルを極力受けるのではなく、Mail-Relay マシンをダ ウンさせないようにすること。ディスクが一杯になることを避ける、メモリ使用が一杯に なることを避ける、CPU 能力が一杯になることを避けることである。嵐が去った後に、し ゅくしゅくとメ−ル作業が継続できるようにすること。マシンがダウンしてしまい、人が マシンを再起動させない限り動かないのでは困る。 sendmail のオライリ−の分厚い本に も、sendmail パラメ−タはマシンをダウンさせないように使うと書いてある。 つまりメ −ルの受ける量を調整、絞るのである。オライリ−の sendmail の本は3冊を、ここら辺 りのパラメ−タの話を図書館などで読んでみた、数ペ−ジ載っていた。 ・だから一度きに一杯メ−ルが押し寄せたら、拒否する。 ・すでに一杯きていて処理中なら、新しいのは拒否する。 ・同じ相手から一杯来たら一定以上のメ−ルは拒否する。 いろいろ設定するパラメ−タはあるが、結局のところ相手メ−ルサ−バからメ−ルの接続 要求を拒否する訳である。そうなると相手メ−ルサ−バはメ−ルを次の配送にする。つま り概ね1時間後に再度送信してくことになる。相手メ−ルサ−バと相談しながら、今一杯 だから少し待ってネという訳にはいかない。そういう機能は MTA には備わっていない。 [ /usr/local/source/sendmail-8.13.8/cf/README から抜粋 ] confQUEUE_LA QueueLA [varies] Load average at which queue-only function kicks in. Default values is (8 * numproc) where numproc is the number of processors online (if that can be determined). デフォルトの値は CPU の数かける 8。CPU は1個だからつまり 8 ということ。この 値を超えたらメ−ルキュ−に入れて配信しない。稼働中の値を知る術はないのか。 confREFUSE_LA RefuseLA [varies] Load average at which incoming SMTP connections are refused. Default values is (12 * numproc) where numproc is the number of processors online (if that can be determined). デフォルトの値は CPU の数かける 12。この値を超えたらメ−ルを受け付けずに拒否 する。どこかでこの値が分かることができないか。sendmail のオプションか何かで。 confDELAY_LA DelayLA [0] Load average at which sendmail will sleep for one second on most SMTP commands and before accepting connections. 0 means no limit. SMTP コネクションを受け付ける前に1秒間スリ−プする。0 は無制限。Greet Pause の機能とは意味が違うのか、1秒間待たせるということでは同じ機能だと思う。 [ 参考 ] オライリ−から sendmail の翻訳本が3冊でている。お値段も高い。「sendmailクックブ ック」設定と運用のためのレシピ集、2004/06 発行、ぐらい1冊買っておきたいものであ る。oreilly の本ではないが、英語本で「sendmail Performance Tuning」2002/09発行の、 Nick Christenson 著がある。sendmail のチュ−ニングずばりの本だ、見たいです。 * Mail-Relay での sendmail.cf の調整−1日目 ConnectionRateThrottle がどう影響していそうか調べてみたい。 このオプションは1秒 間に受け付けるメ−ルの数である。だから "1" は最低の値ということである。 /etc/mail/sendmail.cf 別に大量のメ−ル発信をしている時ではない。 ---------------------------- | | |#O QueueLA=8 これらが最初から sendmail.cf に書かれている値。 |#O RefuseLA=12 コメントになっている。"#O" の '0' はオ−である。 |#O DelayLA=0 | | |0 MaxDaemonChildren=12 |0 ConnectionRateThrottle=1 次の朝 Mail-Storeにメ−ルが溜まっていた。自宅から katou@nix.co.jj へメ−ルを何度 か打ってみた、2回に1回はエラ−になった。自宅契約のプロバイダは qmailを使ってい る。メ−ルが行けば会社の Mail-Store の /usr/people/katou/.forward で、送り返すよ うにしてあるので、ikken@tcp-ip.or.jjへ返ってくる。ConnectionRateThrottle=1、1秒 間に1個の受け付けではだめみたいだ。Nagiosでも頻繁に Connection refused とログが 出ていた。溜まったメ−ルは、自分が会社に来る1時間前のものからで59個だった。と りあえず吐き出すために、ConnectionRateThrottle=3 にした。 1時間ぐらいして見たら メ−ルキュ−は空になっていた。 MS# mailq /var/spool/mqueue (59 requests) -----Q-ID----- --Size-- -----Q-Time----- ------------Sender/Recipient----------- l3TNU6vw024548 201 Mon Apr 30 08:30 (Deferred: Connection refused by [192.168.9.1]) ikken@tcp-ip.or.jj l3TNSMvv024168 38 Mon Apr 30 08:28 (Deferred: Connection refused by [192.168.9.1]) | l3TNqsvx029927 5181 Mon Apr 30 08:52 <> (Deferred: Connection refused by [192.168.9.1]) | 平常時に Mail-Relay の MaxDaemonChildren の値を 10 とか 20とか変えても、メ−ルは Mail-Relay のキュ−に特に溜まらなかった。値を 3 とか 5とかにしたら変化は起きただ ろうが。 * Mail-Relay での sendmail.cf の調整−2日目 O QueueLA=4 << 負荷が大きくなったら、配送せずに溜める。 O RefuseLA=10 << 負荷が大きくなったら、メ−ル受信を拒否する。 #O DelayLA=0 << これはいじらなかった。 0 MaxDaemonChildren=12 0 ConnectionRateThrottle=5 O DoubleBounceAddress 朝、上のような設定にして夕方みてみた。16時頃に見たら sendmail は12個できてい た。10分位後に見たら7個とか6個になっていた。これより何日か前に"O RefuseLA=6" として、今回の変更をした。それまでの間は sendmail は4個か5個だった。今回の設定 までで、Mail-Store では syslog に refuse が結構出ていた。 * Mail-Relay での sendmail.cf の調整−3日目 O QueueLA=4 O RefuseLA=10 0 MaxDaemonChildren=12 0 ConnectionRateThrottle=10 << 5から10にした。 O DoubleBounceAddress 24時間で約50個の refuse 数、Mail-Store の syslogで出た数である。Mail-Relayで は syslog は取ってない。ConnectionRateThrottleを5から10にして、20時間で20 個。refuse の数は半分になった。RefuseLA=10 の影響よりも、 ConnectionRateThrottle が影響しているようである。ConnectionRateThrottle は sendmailが1秒間に受け付ける メ−ルの数のこと。それを超えるとメ−ルの受け付けを拒否する。 Mail-Relay は1秒間 に5個以上は受け付けることができるということか。 * Mail-Relay での sendmail.cf の調整−4日目 #O QueueLA=4 sendmail.cf をいったん元の設定に戻した。それ以降 #O RefuseLA=10 Mail-Store の syslog に refuse は出ていない。 #0 MaxDaemonChildren=12 #0 ConnectionRateThrottle=10 O DoubleBounceAddress << これだけは有効のままにした。 (4) メ−ルサ−バ運用管理スクリプト * 不要メ−ルのファイルを消去する `27/05 Mail-Relayのメ−ルキュ−に溜まっているメ−ルを、一つ一つ表示して消去するか指示す るスクリプト。"DIR" のところにキュ−のディレクトリを書く。"/var/spool/mqueue" と か。該当ディレクトリ内で d で始まる任意のファイルを順に出し、 ファイルの先頭から 50行を表示し、消去するなら "y" をキ−入力する。 するとその dxxx と同じファイル 名の qxxx を先ず消去し、ついで dxxx を消去する。これでキュ−に500ぐらい溜まっ ていたのを、目についたメ−ルアドレスのをとりあえず消したら50ぐらいにできた。残 りも90%以上が User Unknown なメ−ルで、 きちんと Mail-Store の /etc/passwd の アカウントと照らしあわせば、ほとんど不要なメ−ルだと思う。LDAPと連携してアカウン トを照合することが最近の MTA ではできるようになって来ている。しかし Mail-Relayか ら内部ネットにおいた LDAP サ−バにアクセスするというのは、安全上いかがなものか。 こんな拙いスクリプトを久しぶりに書いてみました。多分こんなスクリプトでも、セキュ リティ・ホ−ルがないように勉強して書かないけないのだろうな−。どうだろう、このス クリプトは安全なのかな。セキュリティ・ホ−ルが入り込む余地があるのだろうか。無い ような気がするが。あるとすればシェル・コマンド自体にバグある場合だろう。 /usr/local/bin/fuyou ------------------------------------------------------------- |#!/bin/csh |set dir = "DIR" |cd $dir |foreach i ( d* ) | head -n 50 $i << ファイルの頭から50行を表示する。 ファイルの末尾 | echo --- $i --- から50行表示するには tail -50l とする。 | echo -n "消しますか: " | set kotae = $< << これがコンソ−ルで入力待ちするコマンド。B-Shellに | if ( $kotae == "y" ) then はこの機能はない。 | echo $i | sed 's/^d/q/' | awk '{print "rm",$1}' | sh | rm $i | endif | echo "" |end |cd .. |exit 0 このスクリプトの逆のも書いて使うとよい。q で始まるファイルを表示して、同じファイ ル名の dxxx を消すのである。mqueue に500個ぐらいファイルがあっても大方が User Unknown なメ−ルで、ぱんぱんと消していって10分もかからない。だいたい数十個まで 減らすことができる。 * 既存メ−ルキュ−の押し出し [ Mail-Relay にて ] メ−ルシステムが正常に稼働している状態では、ここにメ−ルは溜まらない。Mail-Relay の性能が貧弱で、内外のメ−ルをさばき切れないと Mail-Relay にも溜まるしMail-Store にも溜まることになる。Mail-Store から Mail-Relayへメ−ルを送る際に、受取りを拒否 されて溜まる、Mail-Store の syslog には refuse のログが残る。現在 Mail-Relayには 常にバウンスメ−ルなどが溜まっている。99%が不要なメ−ルだ。unknown なファイル を消去したりして減らした上で、溜まっている必要なメ−ルを次のコマンドで吐き出す。 # /usr/lib/sendmail -q & [ Mail-Store にて ] 溜まっているメ−ルが少なければ、少ないと言うのは何個ぐらいなのかあやふやなのだが。 とりあえず数十程度としよう。Mail-Storeでは /var/spool/mqueue/ に溜まる。ここを制 御しているのは sendmail-tx.cf の方である。Mail-Relayをいじっていて、メ−ルがちょ うど溜まっていることがあった。いじっている間に Mail-Relay に Mail-Store からのメ −ルが拒否されたのだ。その時、下記のことをやったら、56個あったファイルが一瞬に して12個になった、さらに20秒ぐらいして見たら0になっていた。 # /usr/lib/sendmail -q -C/etc/mail/sendmail-tx.cf & * メ−ルを優先的に送信するには `27/09 書き直し 溜まったメ−ルのなかから緊急に、すぐに送信したいメ−ルを押し出すプログラムなりス クリプト。特定のメ−ルアドレス宛のメ−ルが滞っていないか調べ、あればそのメ−ルだ けを押し出すことができないものか。ネットを見ていたら、そうした Perl のプログラム の話がでていた。cron や sleep() でなく、時間をカウントして何分か毎にメ−ルボック スをチェックして、業務システムに該当メ−ルを渡すというもの。しかし CPUがこのプロ グラムのために 100% 取られてしまい、メ−ルサ−バが挙動不審になったとあった。しか し、どうして?。cron で普通にスクリプト書いて処理する分には問題ないのでないか。 別なメ−ルキュ−を用意して、直ちに送信したいメ−ルを持ってきて処理する。sendmail にはメ−ルキュ−を指定するオプションがある。メ−ルサ−バのメ−ルキュ−から直ぐに 送信したいメ−ルのファイル dxxx と qxxx を、例えば /var/spool/temp/ にコピ−する。 メ−ルキュ−は同じマシン内でなくてもいいし、別なマシンでもいい。Mail-Relayホスト で Solaris 2.6, sendmail-8.12.5 で以下のようにやってみた。エラ−は出なかった。す ぐに処理が始まらないので、駄目かと思った。少し待てば多分ちゃんと送信したはずであ る。どうもメ−ルキュ−の処理のタイミングはよく分からない。 # /usr/lib/sendmail -QueueDirectory=/var/spool/temp -q -v & Mail-Store の Solaris 9, sendmail-8.12.10 ではオプション自体がどうも駄目みたいな エラ−が出てしまった。# /usr/lib/sendmail -QueueDirectory=/var/spool/temp -C/etc /mail/sendmail-tx.cf -q -v &。 ひょっとするとオプションの順番がいけなかったのか。 一応 sendmail-tx.cf には "O QueueDirectory=/var/spool/mqueue" があった。それにこ んなのもあった "#O QueueSortOrder=priority"。再度確認要である。因みqmailではマシ ン固有のIDがメ−ルのファイルに付けられて、別マシンにコピ−したのは認識されない とのことだ。これはプロバイダをやっている人から聞いたことである。 大量のダイレクトメ−ル発信をやっている時に、あるメ−ルをどうしても直ぐに送りたい。 でも Mail-Relay には大量のメ−ルが溜まったままだ。/etc/rc2.d/S88sendmailで全部の sendmailを止め、キュ−のファイルをいったん他に全部コピ−したり、上の手続きをやっ てみた。でもメ−ルは出ていかない。ひょっとして、ただの cp コマンドでファイルのタ イムスタンプが違って、送信すべきメ−ルを認識しなくなったのか。もう永遠に送信され ないのか。でもそんなことが起きたらメ−ルサ−バの移行なんか、できやしない。おお− どうしよう。へたにあがくと、どうにもこうにもならなくなるぞ。 焦って、懇意にしている社外のエンジニアにアドバイスを求めた、メ−ルで。でもメ−ル は飛んで行かないし。翌朝、一番で電話をくれた。メ−ルの返事もきていた。他に移した キュ−のファイルは昨晩、元に戻して帰宅したのだが、メ−ルは全部出ていっていた。も らったメ−ルには "O QueueSortOrder=time" うんぬんと、sendmail のオプションの参考 が書かれていた。http://www.nic.ad.jp/ja/materials/iw/1997/proceedings/tutorial3/ "6. sendmail システム管理" のところで "mqueue 管理" の "指定したメッセ−ジだけ配 信"、sendmail -qIqid、sendmail -qSsender-substr、sendmail -qRrceiver-substr。 社内のパソコンから顧客などへ一斉の大量メ−ル配信中は、他のメ−ルは行かない場合が ある。いったん大量メ−ルの送信を停止してもらう。Mail-Store や Mail-Relayにメ−ル がキュ−にたくさん溜まっている状態。Mail-Relayは sendmail が多過ぎてスワップ・エ ラ−多発、sendmail を全部キルして再起動する。Mail-Relayで この時、パソコンから新 たにメ−ルを送れば先にメ−ルは出て行く。キュ−に溜まったメ−ルよりも、どうも新し く来たメ−ルの方が優先される。キュ−はメ−ルのファイルの時刻でなく中のを見るよう だ。キュ−の処理が始まる前にちゃちゃっとメ−ルを送信しないと、うまく行かない。 パソコンなんかのメ−ルソフトでメ−ルを送る際に、何らか指示することができないもの か。Outlook にはメ−ルの重要度を示すオプションがある。メ−ルの制御ファイル qxxxx を見ると "H??X-Priority: 3 (Normal)" や "H??X-MSMail-Priority: Normal"というのが ある。X-Priority は一般的なヘッダ−のオプションで 1(高)から5(低)の値をとる。もう 一つはマイクロソフト製のみ有効なオプションである。でも、これらのオプションがメ− ルサ−バで優先処理されるという記述は見たことがない。 Precedence というオプション もあるみたいだが有効性は不明、list,junk,bulk という順で優先するらしい。 * メ−ルキュ−の自動ごみ掃除 下記 find コマンドでメ−ルキュ−のディレクトリは、実際のディレクトリを書いた方が 無難である。メ−ルキュ−のディレクトリにメ−ルがどんどん溜まるようになり変更した ことがある。余裕のある別なパ−ティションに変えたのである。別なところに mqueue デ ィレクトリを作り /var/spool/ の mqueue を # ls -s でリンクした。次の日、メ−ルキ ュ−に溜まっているファイルの数を見ようとして、#cd /var/spool/mqueue やったら入れ なかった。root宛にディレクトリが消せないというメ−ルも来てたような。ともかくリン クがなくなっていた。実体のディレクトリはそのままあった。どうも mqueue_souji_1 が 悪さをしたのでないか。しかし sendmail 自体は問題なく働いていて、メ−ルの送受信は ちゃんとできていた。どこからもクレ−ムがでなかったので。ということは sendmail は 止まらない限り、メ−ルキュ−の実体ディレクトリを覚えているということか。 /var/spool/cron/crontabs/root ---------------------------------------- 分 時 日 月 週(1-7,1は月曜) | | |0 5 * * * /usr/local/bin/mqueue_souji_1 毎朝5時に実行。 |0 6 * * * /usr/local/bin/mqueue_souji_2 毎朝6時に実行。 /usr/local/bin/mqueue_souji_1 4日以上経ったファイルを強制的に消去する。 ------------------------------------------------- |#!/bin/sh +3で4日以上経っているファイ |find /var/spool/mqueue -mtime +3 -exec rm {} \; ルということになる。+0は1日 | 以上経ったファイルを意味する。 |# ファイルだけ消すように限定、この方がいいかも。 |#find /var/spool/mqueue -type f -mtime +3 -exec rm {} \; 4日以上経っているファイルを消すと言っても直感的ではない。例えば今日がある月 の24日だったとしたら、/var/spool/mqueue ディレクトリには #ls -l で表示され る日にちで21、22、23、24日の日付けのメ−ルがあるということ。 /usr/local/bin/mqueue_souji_2 中身に unknown と出ているファイルを消去する。 -------------------------------------------------------------------------------- |#!/bin/sh |grep -l "User unknown" /var/spool/mqueue/d* | sed 's/d/q/' | 続く | awk '{print "rm",$1}' | sh >/dev/null 2>&1 |grep -l "User unknown" /var/spool/mqueue/d* | awk '{print "rm",$1}' | 続く | sh >/dev/null 2>&1 上のスクリプトの最初ので q*** ファイルが消える。2番目で d*** ファイルが消え る。`2h/06/m に何年か振りにこれを使ったのだが、 これで両方共どうして消えるの か分からなかった。幾つか適当にこれらのファイルを作って動作確認してみた。 "User unknown" でも unknown でも消されるのは一緒、どちらの指定でもいい。コマンド は sh までの記述でいいが、該当ファイルが存在しない場合、その旨メッセ−ジが画面に 出てしまう。メッセ−ジを出さないようにするのが /dev/null 2>&1 のところである。し かしメ−ル本文に、こんなエラ−メ−ルがあるんだけど、どうしたらいいかというような ことを書いた場合、それも消されてしまう。でも朝の6時に処理をするわけで、それまで 送れずに溜まっていたメ−ルを消すのである。日中に送った通常のメ−ルなら、普通は直 ちに送信されている訳で、そんな朝まで残っているなんてことはない。まあできればメ− ルのヘッダ−部の "User unknown" を見て消去するのが望ましいのだが、そこまでシビア に考えることはないと思う。sendmail.cf の Timeout.queuereturn=3d で3日経ったメ− ルは送信者に送れませんでしたと返す。3日以上経っても溜まっているメ−ルはゾンビに なってしまっている訳で、それは強制的に -mtime で4日目に消すことにする。 メ−ルのファイル生成 O Timeout.queuereturn=3d ↓ ↓3日経っても送れなかったメ−ルは送信者に返す。 |-------|-------|-------|-------| 0日 1 2 3 4 ( find .. -mtime +3 ) ↑これだけ経過したメ−ルのファイルを消去する。 * メ−ルシステムの動作確認 メ−ルが基本的に即時性を持つものでない以上、リアルタイムに相手に届くことは保証で きない。しかし普段の特に問題ない状態であれば、ほとんど即届く。メ−ルサ−バの設定 をいじったような時、ちゃんと設定または稼働できているかの確認に、個人で入っている プロバイダにメ−ルを送り、向こうで送り返す設定によって、メ−ルが返ってくることを 利用している。だいたい1分もかからず返ってくる。これを逆に設定すれば、休みの日に 自宅から会社のメ−ルサ−バがちゃんと稼働しているかどうかのチェックができる。ただ し Nagios なんかで Mail-Relay の SMTP チェックをさせると、敏感に反応して警告!警 告!と、年中メ−ルをもらうことになる。MTAは sendmail でも qmail でも何でも、ある 一定以上のメ−ルがやってきたら処理し切れずに、相手 MTAを待たせたり、あるいは拒否 したりして再送を待つことになる。これは MTAの仕様、仕組みであって、メ−ルサ−バの 運用監視には気を付けたい。Nagios の本やマニュアルには書いてないことである。 [ Nagios について ] `27/05 http://nagios.x-trans.jp/naija/ が Nagios の公式ドキュメントを日本語化しているサ イト、ここの人「Software Design」2006/06 号に記事を執筆、掲載している。Nagios の 本が1冊出ている、ちらっと読んでみた。運用上の注意点といったことは特に書かれてい なかった。Nagiosは一本のでかいプログラムではなく、監視対象毎のプログラムになって いる。それぞれのコマンドをオプションをつけて叩けば、その機能を確認することができ る。プログラムはプラグインと呼ばれる http://sourceforge.net/projects/nagiosplug/ にある。プログラムの詳細は、以下に解説した記事があった。 「Software Design」2007/03, P.128〜133, "新連載ネットワ−ク監視ツ−ル Nagios のコ > −ドを読む 内部動作を徹底解説!"。check_ssh, sshd をネットワ−ク監視する。プラ グインが /usr/local/nagios/libexec にインスト−ルされる。 「Software Design」2007/04, P.156〜163, "第2回Nagiosプラグインのメ−ルサ−バチェ > ック"。Nagios は独立した個別のプログラム。P.159 に SMTP の基本的なプログラムの ソ−スが掲載されている。よくみていけば、素直なソ−スコ−ドみたいだ。 (5) 再び大量メ−ルの発信と観察 `27/05 * 先ずは500通送ってみた < Mail-Relay の sendmail.cf そのまま > パソコンのメ−ル一斉送信ソフトで、どんどん顧客にダイレクトメ−ルを送った。以下の も同じである。15分で送り終えた。送り始めて数分で MRで swapエラ−が出たが、15 分以降は出なかった。MR が最後、送り終えるまで1時間半ぐらいかかった。その間 MSの syslog に refuseは出なかった、出るとしたらどんどん送信している負荷の大きい15分 の間だったろう。と言うことは500通ぐらいの一斉メ−ルは、MRの sendmail を何も調 整しなくても送れるということである。 10分して MRのキュ−に 275個、MSのキュ−に 561個。30分して MR のキュ−に593個、 sendmail が30個以上、モニタからはみ出ていた。#ps -e | grep sendmail | wc -l で 見たら121個もあった。35分して MR に 627個、MSに21個で一斉送信のメ−ルはなか った。40分で MR に434個、順調に減っていっている。45分 MRの sendmail は7個に なっていた。54分テストメ−ルはすぐ返ってきた。ということは MS から MR へのメ− ルは転送を終えて、MR には、もう溜まっているだけになっている。 MR キュ−57分 309個、60分 245個。85分後、見たら MRのキュ−には 150個あった。 既存の動いている sendmail は止めずに # /usr/lib/sendmail -q & をやった。100分 MRに sendmail -q は無くなっていた、sendmail の数は3個。これで送信終了である。MR のキュ−に core ファイルができていた、9分後のことでサイズ 587368 で中身はバイナ リだった。他、10分テストメ−ル送った、18分 MS に溜まっていた。MRはキュ−にた くさん溜まっている時は mailq やると表示するまで数分かかった。 ※テストメ−ルは ikken@tcp-ip.or.jj に送り、転送により katou@nix.co.jj に返す。 * もう一度500通送ってみた < sendmail.cf にMaxDaemonChildren=25 > Mail-Relay の sendmail.cf とMail-Store の sendmail-tx.cf を MaxDaemonChildren=25 にした。Mail-Relay の sendmail.cf だけでもよかったが、一応両者の sendmail のプロ セスが起動できる最大数を合わせてみた。Mail-Store側は、これを設定してもしなくても 変化はなかったと思われる。一斉送信の49分前に MR の sendmail を止めて再起動した。 MS の方は一斉送信の18分前に sendmail の tx を止め再起動した。この前後 sendmail の tx プロセスは1個だけだった。# sendmail -bd -q1h -C/etc/mail/sendmail-tx.cf & をやって再起動した。sendmailの起動時刻はキュ−処理の時刻と関わるはずなので記した。 500通を7分間でパソコンソフト側は送信終了。3分後から9分後の間で MS のsyslog に 366個の refuse がでた。MR では送信開始から終わりまで swapエラ−はまるで出なか った。きちんと MaxDaemonChildren オプションが働いたことになる。MS から MR へのメ −ルをある一定量以上を拒否して、MRの負荷が高くなるのを押えたのである。テストメ− ルは26分に送信、すぐ返ってきた。57分と73分に送信 MSに溜まった。MS のsyslog の refuse はその後も出たが一斉送信のはなかった。52分後に 1個、55分に10、71 から81分に13、157分に1、190分に1個だった。 10分 MS に 731。22分 MR に61、MSに741。44分 MR に 63 sendmail 5個、MS 741 で変わらず。52分 MS 517。59分 MS 400 sendmail tx 5個、MR 335。62分 MS 295。 73分 MS 143。75分 MS sendmail tx 2個。77分 MS 73、MR の sendmail 120個。 90分 MS 89、# sendmail -q -C/etc/mail/sendmail-tx.cf & やったら、 1分でキュ− は0になった。後 MR のキュ−の様子。92分 407、103分369、110分245。124 分 200、内26は一斉メ−ルでないの。158分 sendmail が20個あったがすぐに減った、 キュ−に 33、# sendmail -q & やった。ここで終了とみなした。 * いざ8千通の一斉メ−ル送信 < sendmail.cf にMaxDaemonChildren=25 > 金曜日の19時から21時にかけて8千通のメ−ルを一斉送信。11分後 MSキュ−に660、 MR キュ− 170、sendmail 63個。15分後 MS sendmail tx 22個、MSキュ− 845、MR キュ− 225。この後は自宅に帰り、逆のテストメ−ルを送りながら様子を見ていた。23 時頃から6千通のエラ−メ−ルが発信者の営業さんに返ってきたという、このメ−ルは4 時間後にまだ送れてませんという報告メ−ルである。報告メ−ルは出ないようにしないと いかんな。全部、送り終えるのに、土曜日の昼2時までかかった。20時間かかったこと になる。この間 Mail-Relay からは swap エラ−は出なかった。 自宅に帰ってからの逆テストメ−ルは、10分位してプロバイダからエラ−メ−ルが返っ てきた。送れませんとある。メ−ルキュ−にも溜めずに配送を諦めてしまった。プロバイ ダの MTA は qmail なのだが、そういう仕様にしているのか、そんなことないと思うのだ が。ひょっとかして qmailのデフォルトの仕様?、だとすると大問題だが。一斉送信が終 わった後に、逆テストメ−ルの返事が来ることはなかった。全部のメ−ルが送り終わった と判断したのは、逆テストメ−ルの返事がすぐ、5分程度で返ってきたことを見てである。 次の日の昼2時頃のことだった。 1時間毎に MS の InterScan から katou 宛に "IMSS Purge File Status" というメ−ル が出ている。MR を通って ikken 宛に来た際の通過タイムスタンプを書き出してみた。例 えば MS 発信 20:30 のメ−ルは MRが受け付けることができず、1時間毎に送ろうと繰り 返した。4時間経って送信元にまだ送れてませんと報告メ−ルを返したのが 1:14 である。 From: MAILER-DAEMON@nix.co.jj, To: postmater@nix.co.jj, Subject: Warning: could not send message for past 4 hours"。このメ−ルは送信を諦めた訳でなく、MRには次の 日の 3:30 に届いて、プロバイダには 14:02 に届いている。 ※逆のテストメ−ルは 自宅から katou@nix.co.jj に送り、転送により自宅の方へ返す。 (プロバイダ) MSから MRへの送信で出た MS MR PB |エラ−MS MR PB syslog での refuse の数。 ------------------------|-------------------------- 19:30 19:30 17:14 | 2954 20:30 3:30 14:02 | 1:14 3:08 13:57 3902 21:30 3:08 13:57 | 2:13 3:08 13:57 7708 22:30 3:08 13:57 | 2 23:30 3:08 13:57 | 6032 0:30 3:08 13:57 | 5570 1:30 3:08 13:57 | 2 2:30 3:08 13:57 | 2 3:30 13:09 13:14 | 8:14 13:09 13:14 2 4:30 4:30 14:16 | 9:09 13:09 13:14 0 5:30 13:09 13:14 | 10:09 13:09 13:14 3400 6:30 13:09 13:14 | 11:09 13:09 13:14 2955 7:30 13:09 13:14 | 12:09 13:09 13:14 2447 8:30 13:09 13:14 | 2 9:30 13:09 13:14 | 1537 10:30 13:09 13:14 | 1153 11:30 13:08 13:14 | 742 12:30 13:08 13:14 | 367 13:30 13:30 13:33 | 0 14:30 14:30 14:33 | 5 15:30 16:08 16:11 | 4 16:30 16:29 16:48 | 1 17:30 17:29 17:32 | 2 18:30 20:08 20:09 | 1 19:30 20:08 20:09 | 3 20:30 20:29 20:31 | 0 21:30 21:29 21:31 | 0 MS の syslog から、1時間の内の refuse が出た数をカウントしたい。 始めは6月1日 の19時。egrep 'katou|satou' で katou かつ satou という文字を検索、これに日付と refuse を当てはめたらと思った。#grep "Jun 1 19" sylog2706 | grep refuse | wc -l でできた、2954というように出てきた。これでやることにした。19時00分から59分 までの間の refuse を数えた訳である。結果をどう見るか、何かムラがあるように思うが。 同じメ−ルが1時間毎に何度も送信し拒否されている。その繰り返しでだんだんメ−ルが 少なくなって行くという過程を通っているはずである。さて、そういう風に見えるかな。 * 確認:Mail-Store の sendmail と InterScan の動き ダイレクトメ−ル発信のパソコンから (内外からメ−ルが入って来る) ↓TCP/25 sendmail ( sendmail-rx.cf 使用 ) /var/spool/mqueue-rx/ {ここでのシスログ} ↓TCP/10025 ---------------------------- |InterScan ウィルスチェック| /opt/trend/imss/queue/postpone/ ---------------------------- ↓TCP/10026 sendmail ( sendmail-tx.cf 使用 ) /var/spool/mqueue/ {ここでのシスログ} ↓ 外の顧客へのメ−ルは Mail-Relay へ (社内ユ−ザは /var/mail/xxx) InterScan の停止と起動は # /etc/rc2.d/S99ISIMSS stop or start sendmail の停止と起動は # /etc/rc2.d/S88sendmail stop or start /etc/rc2.d/S88sendmail で起動される2つの sendmail デ−モン。 ------------------------------------------------------- |/usr/lib/sendmail -bd -q1h -C/etc/mail/sendmail-rx.cf 処理の心臓 |/usr/lib/sendmail -bd -q1h -C/etc/mail/sendmail-tx.cf 部だけ抜粋。 Mail-Store ではやってきた内外のメ−ルは、ポ−ト25番で待ち受ける sendmail-rx.cfの sendmail で /var/spool/mqueue-rx/ キュ−ディレクトリに入る。ここはどんどん受け付 ける。Nagiosで Mail-Store のメ−ルサ−バを監視しているのは、ここになる。すぐにポ −ト 10025番にメ−ルを送り、/opt/trend/imss/queue/postpone/ キュ−に溜まる。多分 InterScan が 10025番で待ち受け、ウィルスチェックした後にキュ−に入れるのだと思う。 そして直ぐにポ−ト 10026番で待ち受ける sendmail-tx.cf の sendmail にメ−ルを送り、 /var/spool/mqueue/ に入る。ここから外ヘのメ−ルは Mail-Relayへ、内部ユ−ザのメ− ルは /var/mail/xxx へと行く。つまり InterScan の前後に2つの sendmail があり、そ れぞれ from と to のシステムログが出て、 同じ /var/log/syslog ファイルに書き込む。 sendmail.cf は別々なので、違うファイル名でログを出すことはできる。InterScan での ウィルスチェックは、内外へメ−ルを送信する際にチェックしている。ユ−ザがメ−ルを 受ける際にチェックするのは POP3 アクセス時になる、これはやっていない。 * 上記大量メ−ル発信の考察 多分 Mail-Relay の SMTP 監視で Socket timeout が頻発するのは、やはりメ−ルの量が 多いのだと思う。Nagiosでの監視で1時間に1回か2回ぐらい Socket timeout が起こり すぐに正常に戻るようなことになっている。拒否まではいかないが、その寸前のところで Socket timeout になっているのでないか。ちょっと一杯メ−ルがやって来ると、 すぐに 相手MTA を待たせる、すぐに反応を返せないのである。これは、ひょっとかするときりぎ りのチュ−ニングがされた状態になっているのでないか。多分 Mail-Relay は定常的に相 手 MTA を結構待たせているのでないか。 全部のメ−ルでないが、例えば10通に1通と かの割合で何秒か待たせている。ちょうど Greet Pauseをかけた状態に既になっているの でないか。Mail-Relayの能力が高いとスパムメ−ルを呼び込むことになり、増えて行くと 言われている。ならば Mail-Relay は、メ−ルをやりとりするのに支障が出ないぎりぎり の能力で運用するのがいいのでないか。大量のメ−ルを一斉送信する場合は、上記のよう に時間がかかり占有してしまうので、一時的に能力を高目に設定すればいいのでないか。 * Mail-Relay ホストの能力 `27/08 InterScan の eManager のログを見ていて。ブロックされた迷惑メ−ルを、この数ヶ月一 応、毎日チェックしている。一日20ペ−ジぐらい。それに Mail-Relay のメ−ルキュ− に溜まった自社宛先不明のメ−ルもチェックして消去している。こちらは一日に110前 後、自分で書いたスクリプトでパンパンと消していって、6つとか8つ残るぐらいである。 ある日のこと、出勤して昨日の宛先不明メ−ルをいつものように消去していた。特に数も メ−ルアドレスも変わったような感じはなかった。でも昨晩、毎日定期的に送っているメ −ルが相手に届くのに1時間遅れたといってきた。その時間帯の eManager のログを見た ら、どうも最近よく来る xxx America xxx という件名のメ−ル。 これが集中的にログに 残っていた。ある時刻、1秒の間に16通とか10とか8通とか来ていた。ひょっとする とこの時間帯にメ−ルを送ろうとして、できなかったのでないか。この現象を考えてみる と、Mail-Relayホストの能力は1秒間に16通のメ−ルは送受信できるといえるのでない か。しかし、上記大量メ−ルの発信ではそこまでの能力はあるように思えないのだが。 * Mail-Relay の sendmail のチュ−ニング `27/09 /etc/mail/sendmail.cf ----------------------------- |0 MaxDaemonChildren=40 << これに変更してすぐに、ps コマンドで監視してい |#0 ConnectionRateThrottle=10 たら、40個ぐらいの sendmailデ−モンができた。 | でも特に問題は何も起きなかった。変更前は 20。 |0 Timeout.queuewarn=24hr << 変更前は queuewarn は4hr、command とdatablock |0 Timeout.command=10m はコメント。それがデフォルトである。 |0 Timeout.datablock=10m 注.以下のログは Mail-Store の syslog である。 # cd /var/log # grep greet syslog.x | wc -l # ls -al syslog* | # grep collect syslog.x | wc -l .. 9955312 9月 7日 15:35 syslog ↓ ↓ .. 23014396 9月 5日 03:09 syslog.0 256 208 最新のログから50行表示。 .. 23812326 8月 29日 03:09 syslog.1 312 316 # tail -50l syslog .. 21761982 8月 22日 03:09 syslog.2 193 354 .. 21312740 8月 15日 03:09 syslog.3 151 322 .. 24623931 8月 8日 03:08 syslog.4 193 438 .. 22160932 8月 1日 03:09 syslog.5 122 428 .. 22491214 7月 25日 03:09 syslog.6 99 544 .. 22087719 7月 18日 03:09 syslog.7 65 292 Mail-Store の sendmail-tx.cf は "O MaxDaemonChildren=25"、rx.cf の方はコメントで。 ConnectionRateThrottle は両方ともコメント。 "O ConnectionCacheTimeout=5m" は両方 とも、これは一体何。rx.cf に "O Timeout.datafinal=20m"?、tx.cf の方はコメント。 [ 相手先にアクセスする際に待たされて諦めたログ] Mail-Store でのログ mail.info .. from= .. daemon=MTA, relay=localhost [127.0.0.1] mail.info .. to= relay=127.0.0.1 .. Message accepted for delivery) mail.notice .. timeout waiting for input from [192.168.2.1] during client greeting mail.info .. to= .. relay=[192.168.2.1] .. with [192.168.2.1] 今の Mail-Relayホストは、処理能力が低い故に自然に Greet Pause が働いていたの でないか。どうも、そうじゃないかと思っていたのだが、上の Mail-Store でのログ がその証拠とみてよさそうである。 Mail-Store から Mail-Relay へメ−ルを送る際 に Mail-Relay の sendmail が、最初の SMTP の応答を待たせた。 [ Timeout.datablock が関係する timeout のログ ] mail.notice .. timeout waiting for input from dnsp during message collect mail.info .. to= .. stat=timeout waiting for input during message collect このログは、一応メ−ルのやりとりの SMTP は開始できたのだけれども、デ−タを送 っている最中に Mail-Relay からの反応がなくなってしまった。Mail-Relay側のメ− ルサ−バの負荷が大きく成り過ぎて、処理を続けられなくなったということだと思う。 これなんかは、もう Mail-Relay ホストの能力が足りない証だとみてよい。 メ−ルキュ−にあるファイルの数の半分がメ−ル数。# ps -ef で出て来る sendmailの数。 メ−ル数が4で sendmail 数が15だと、少なくとも11が外から来ようとしているメ− ルの数ということになる。MaxDaemonChildren=25 の時、どうも sendmailの数は25止ま りだったような。sendmail の数が25ぐらいあった際に、ikken@tcp-ip.or.jj へとメ− ルを送ってみた。すぐには外にメ−ルは行かなかった、Mail-Relayに溜まった。sendmail の起動した時刻を見ると、何時間も前のもちらほらあった。一見多くの sendmail ができ ているようにみえるが、# vmstat 5 4 では CPU はほとんど使われていない。Swapはだい ぶ使われている、page の piが 300 とかになっていた。このように sendmailができても、 実際は何も働いていない。こんなのは早々に消去しなければならない。どうもそれを制御 する時間が sendmail.cf の Timeout.command と Timeout.datablock ではないか。 別な日に ikken@tcp-ip.or.jj へメ−ルを送ったら、今度は Mail-Store で足止めをくっ た。Mail-Store の syslog には、"09:59:41 .. mail.info .. to= .. Deferred: Connection refused by [192.168.2.1]" と出ていた。 "timeout waiting" のログは出ていなかった。行って返ってきたメ−ルのヘッダ−を見ると、Mail-Storeから Mail-Store が 09:59:40 で、Mail-Store から Mail-Relay が 10:11:14、Mail-Relay か ら tcp-ip.or.jj へのメ−ルサ−バが 10:12:25 だった。そして向こうでメ−ル転送して Mail-Store に返ってきたのが 10:13:28 だった。Mail-Store から Mail-Relay へメ−ル を渡す際に、拒否はされたのだけども、11分後には送ることができている。次の再送に は回されていない。ということは、いったんは拒否されたものの、すぐに接続できて送信 が終わるまで11分かかったということのようである。 * Mail-Relay マシンを SS5 から新しいのに変えた 社内から外への大量メ−ル配信。営業さんのパソコンからソフトで、ダイレクトメ−ルを 1秒間に約2個、1万通のメ−ル出す。当初は2千通ぐらいを500通ぐらいに分けて出 してもらっていた。それぐらいの時は問題にならなかったのだが、5千通、ちょっと前は 8千通まで膨れ上がり、Mail-Relay の SS5 マシンがアップアップしていた。2007年 秋に Sun の新しいマシンに置き換えた。 多分1秒に2通程度の処理能力は十分あるはず である。大量メ−ルを送る際には連絡してくれと言っておいた。負荷状況を見るためであ る。大量メ−ル発信している間に、個人のプロバイダにメ−ルを送り返ってくる様子も見 たが、すぐにメ−ルは来た。全然問題なさそうである。何回か目もう連絡はいらない、い つでも1万通、一挙に送って構いませんよと言っておいた。さて処理能力はあることは分 かった。spam排除のため Greet Pause を仕掛けるかどうかである。`28/02 ------------------------------------------------------------------------------------ [ 付録 ] 参考 * 参考資料から http://www.nic.ad.jp/ja/materials/iw/1998/proceedings/C01.pdf ConnectionCacheSize 接続にしたままにする SMTP コネクションの数。 << どういうこと?。 QueueSortOrder mqueue にたくさん溜まったメ−ルの再送順序。 << いろんな指定があるみたい。 time 指定にするとうれしいかも(届いた順で)。 よう分からんバイ。 MinQueueAge mqueue に溜まったメ−ルの最短再送間隔。 << デフォルトは10分?。 * MinQueueAge の sendmail での説明 confMIN_QUEUE_AGE [0] The minimum amount of time a job must sit in the queue between queue runs. This allows you to set the queue run interval low for better responsiveness without trying all jobs in each run. 手動で再送する場合は # sendmail -qIxxx などとやって処理。実際、今度 Mail-Relayで sendmail がたくさん稼働している最中にメ−ルを送り、Mail-Relay のメ−ルキュ−にメ −ルを溜め、このコマンドを叩いてみよう。その前に #/etc/rc2.d/S88sendmail stop で sendmail デ−モンを全部なくしてからだが。 * sendmail のバ−ジョンによる sendmail.cf [ sendmail-8.12.5 ] O ConnectionCacheSize=2 << open connection cache size。 O ConnectionCacheTimeout=5m << open connection cache timeout。 #O QueueSortOrder=priority << shall we sort the queue by hostname first?。 #O MinQueueAge=30m << minimum time in queue before retry。 O QueueDirectory=/var/spool/mqueue #O QueueLA=8 #O RefuseLA=12 #O DelayLA=0 #O MaxDaemonChildren=0 #O ConnectionRateThrottle=0 ########################### # Message precedences # ########################### Pfirst-class=0 Pspecial-delivery=100 Plist=-30 Pbulk=-60 Pjunk=-100 [ sendmail 8.9.1 ] 8.12.5 の Message precedences のとこは一緒だった。 O RefuseLA=12 # load average at which we just queue messages O QueueLA=8 O ConnectionCacheTimeout=5m O ConnectionCacheSize=1 #O ConnectionRateThrottle=3 #O MaxDaemonChildren=12 #O MaxRecipientsPerMessage=100 [ 万能 sendmail.cf ] Message precedences のとこがこれだけあった。 Pfirst-class=0 Pspecial-delivery=100 Pjunk=-100