17-3. 迷惑＆エラ−メ−ルの解析 `27/01〜 -------------------------------------------------------------------------------- エラ−メ−ルがどういうように出るのか極めて分かりにくい。でも、ここはぜひとも押え ておきたい。しぶとく見て行くことにする。まだまだ今のメ−ルの仕組みは使われ続ける。 -------------------------------------------------------------------------------- (1) 管理者宛のエラ−メ−ル * Mail-Store からの管理者宛のエラ−メ−ル ずっと管理者である自分に、毎日数十通のエラ−メ−ルが来ていた。社内にそんなユ−ザ 名の人はいませんという奴である。下記は henmohe@nix.co.jj と言うメ−ルアドレスの 場合である。ｓｐａｍ屋さんは、ユ−ザ名部をコンピュ−タで適当に生成してメ−ルを送 ってくるようである。規規則性はない、全くランダムに文字列を入れている。辞書も使っ てないと思われる。"Mail Delivery Subsystem ..." という管理者宛のメ−ルで `27/01 に数えたら一日に３０通ぐらい来ていた。これまで１０か２０通だったのに、この１ヶ月 ぐらいで倍ぐらいになった感がする。迷惑メ−ルは急激に増えてきている。 --------------------------------------------------------------------------- |Postmaster notify: see transcript for details - メッセ−ジ (テキスト形式) |------------------------------------------------------------ |差出人 Mail Delivery Subsystem[MAILER-DAEMON@nix.co.jj] Outlook で表示。 |宛先 postmaster@mail.nix.co.jj |件名 Postmaster notify: see transcript for details |------------------------------------------------------------ |The original message was received at Fri,5 Jan 2007 ...(JST) |from hostA [202.241.128.3] with id XXXXXXX | | ---- The following address had permanent fatal errors ---- | | (reason: 550 5.1.1 ... User unknown) | | ---- Transcript of session follows ----- |... while talking to 127.0.0.1: |>>> DATA |<<< 550 5.1.1 ... User unknown |550 5.1.1 ... User unknown |??? 503 5.0.0 Need RCPT (recipient) |-------------------------------------- □はMicrosoftの絵、■は封筒の絵。 | □ ■ | ATxxx.dat Tekitou ■の中にまたメ−ルがあるのもある。 --------------------------------------- 開いて行くと画像スパムだったりする。 注．すぐ上の 503 5.0.0 Need のところ、ハテナは左括弧＜の小文字が３つ入る。しかし それだと Windows XP の IE8 で表示すると、文字化けしてしまうのである。 他にも dns_next.txt や dns_uiro.txt でも別の文字で化けてしまう。 IE8 のバグなのかは 不明。当初は Apollo のエディタで変な文字コードが入るのかと思ったのだが、パソ コンのエディタでそこの文字列を書き直してもおかしいのは変わらなかった。まった く不可解な文字化けである。2012/06/09 □と■、Outlook ではエラ−メ−ルには必ずこんなのが付いている。□は xxx.datなんて いうファイル名なので、ひょっとしてウィルスかと思ってしまう。このメ−ルをNetscape Messenger で見ると、下記のような表記で少し分かり易いかもしれない。 □部は "Part 1.2 Content-Type: message/delivery-status" ■部は "Part 1.3 Content-Type: message/rfc822" ■部はマウスでクリックすると表示する、最初に送ったメ−ルそのもの。本文と誰が誰に メ−ルを送ったか記載されている。 □部はマウスでクリックしても表示できない。とりあえずファイルとしてセ−ブする。拡 張子は .txt にしておく。それでエディタで表示する。エラ−になった理由などがテキス トで記載されている。 * Mail-Relay からの管理者宛のエラ−メ−ル Mail-Relay からも出ていたが、これまで /etc/aliasesの設定ミスで届いてなかった。修 正したら postmaster@mail.nix.co.jj へ毎日１００から２００位くるようになった。 こ れまでずっと Mail-Relay の /var/spool/mqueue ディレクトリには、 ３０００個ぐらい のファイルがあった。それが５００から６００個ぐらいになった。その分、管理者である 自分に一杯、下記のようなエラ−メ−ルが来るようになった。`27/01 /etc/aliases で "Postmaster: katou"ではこれもエラ−になって ---------------------------- いた。"Postmaster: katou@nix.co.jj" にした |#Postmaster: katou らどんどん自分にメ−ルが来るようになった。 |Postmaster: katou@nix.co.jj --------------------------------------------------------------------------- |Postmaster notify: see transcript for details - メッセ−ジ (テキスト形式) |-------------------------------------------------------------------------- |差出人: Mail Delivery Subsystem [MAILER-DAEMON@nix.co.jj] Outlook で表示。 |宛先: postmaster@mail.nix.co.jj |件名: Postmaster notify: see transcript for details |------------------------------------------------------------ |The original message ... |from hostG.nix.co.jj [202.241.128.2] with id XXXXXXX | | | | ウィルスが入っていたらそれも本文として展開されていた。 半年ぐらい前から自分が普段使っているメ−ルソフトは Outlook。postmaster宛のメ−ル を振り分けることにした `27/03早々。[ツ−ル]->[自動仕訳ウィザ−ド] でこのメ−ルは "メッセ−ジを受信したとき" に適用されます。受信者のアドレスに'postmaster' が含ま れる場合、Mail Delivery フォルダへ移動する。〆受信者のアドレスに特定の文字が含ま れる場合。設定はオプションがたくさんあって、極めて分かりにくかったです。 (2) エラ−メ−ルの出方の確認 * どうもメ−ルのヘッダ−部の見方がわからん 1) 社内から社内のでたらめなユ−ザにメ−ルを送ってみる。 2) 社外から社内のでたらめなユ−ザにメ−ルを送ってみる。 3) まともなメ−ルを telnet アクセスで送ってみる。 4) メ−ルを telnet アクセスで偽造して送ってみる。 * 1) 社内から社内のでたらめなユ−ザにメ−ルを送ってみる 送信者はまとも katou@nix.co.jj 宛先はでたらめ henmohe@nix.co.jj 送信者である katou@nix.co.jj にエラ−メ−ルが来たところ。 ------------------------------------------------------------- Outlook 2000 SR-1 |差出人 Mail Delivery Subsystem[MAILER-DAEMON@nix.co.jj] |宛先 katou@nix.co.jj |件名 Postmaster notify: see transcript for details |------------------------------------------------------------ |The original message was received at Sat,6 Jan 2007 ...(JST) |from [192.168.1.9 ] 自分のパソコンのＩＰ | | ---- The following address had permanent fatal errors ---- | | (reason: 550 5.1.1 ... User unknown) | | ---- Transcript of session follows ----- |... while talking to 127.0.0.1: |>>> DATA |<<< 550 5.1.1 ... User unknown |550 5.1.1 ... User unknown |<<< 503 5.0.0 Need RCPT (recipient) |-------------------------------------- | □ ■ □はMicrosoftの絵 | ATT02563.dat ATT02566.eml ■は封筒の絵 --------------------------------------- ATT02563.dat -------------------------------------------------------- |Reporting-MTA: dns; mail.nix.co.jj Mail-Store |Received-From-MTA; DNS; [192.168.1.9] 自分のパソコンのＩＰ |Arrival-Date: Sat, 6 Jan 2007 15:34:40 +0900 (JST) | |Final-Recipient: RFC822; henomohe@nix.co.jj |Action: failed |Status: 5.1.1 |Remote-MTA: DNS; 127.0.0.1 |Diagnostic-Code: SMTP; 550 5.1.1 ... User unknown |Last-Attempt-Date: Sat, 6 Jan 2007 15:34:40 +0900 (JST) ATT02566.eml --------------------------------- |差出人 katou[katou@nix.co.jj] |宛先 henmohe@nix.co.jj |-------------------------------- |test desu | --------------------------------- ATT02566.eml を[表示]->[オプション] ------------------------------------- |Return-Path: |Received: from katou([192.168.1.9]) | by mail.nix.co.jj .. with SMTP .. | for () ... |From: "katou" |To: * 2) 社外から社内のでたらめなユ−ザにメ−ルを送ってみる 送信者はまとも。自宅から会社のでたらめなユ−ザへ送った。 ikken@tcp-ip.or.jj から kero@nix.co.jj へ。ダイアルアップ接続です。メ−ルソフトの送信ボタンを押して、 数 １０秒でエラ−メ−ルが返ってきた。Mail-Store にはメ−ルは残らない。 管理者宛にも エラ−メ−ルは行かない。 自宅にきたエラ−メ−ルを katou@nix.co.jj に転送して受けたところ ------------------------------------------------------------- Outlook 2000 にて |差出人 Mail Delivery Subsystem[MAILER-DAEMON@nix.co.jj] |宛先 ikken@tcp-ip.or.jj |件名 Returned mail: see transcript for details |------------------------------------------------------------ |The original message was received at Tue, 12 Apr 2007 ...(JST) |from hostA [202.241.128.3] | | ---- The following address had permanent fatal errors ---- | | (reason: 550 5.1.1 ... User unknown) | | 以下 1) の表示と同じよう << Mail-Store に残ったログ >> tcp-ip.or.jj を tcp.jj、記述はできる限り省略した。 relay=hostA は "relay=hostA [202.241.128.3]" relay=localhost は "relay=localhost [127.0.0.1]" Message は "Message accepted for delivery" と見る。 19:46 [262] A: from=, msgid=<.@tcp.jj>, daemon=MTA-RX, relay=hostA 19:46 [264] A: D: DSN: User unknown 19:46 [264] A: to=, relay=127.0.0.1, stat=User unknown 19:46 [265] B: ... User unknown 19:46 [265] B: from=, daemon=MTA, relay=localhost 19:46 [265] C: from=<>, msgid=<.D@hostB.nix.co.jj>, daemon=MTA, relay=localhost 19:46 [264] D: to=, relay=127.0.0.1, stat=Sent (C Message) 19:47 [269] C: to=, relay=[192.168.2.1], stat=Sent (. Message) ikken@tcp.jj から転送されてきたログ 19:49 [274] E: from=<>, msgid=<.D@hostB.nix.co.jj>, daemon=MTA-RX, relay=hostA 19:49 [276] E: to=, relay=127.0.0.1, stat=Sent (F Message) 19:49 [277] F: from=<>, msgid=<.D@hostB.nix.co.jj>, daemon=MTA, relay=localhost 19:49 [280] F: to=, mailer=local, relay=local, stat=Sent * 3) まともなメ−ルを telnet アクセスで送ってみる ホスト名 abcd mail.nix.co.jj PC まとまなメ−ルを先ず Apollo □ □ Mail-Store □ Outlook Apolloから送ってみる。 ｜.8 ｜.1 ｜.9 -------------------------------------- 192.168.1.0 $ telnet 192.168.1.1 25 220 mail.nix.co.jj ESMTP Sendmail 8.12.10 ... (JST) helo 192.168.1.8 << このマシンのＩＰアドレス。 250 mail.nix.co.jj Hello abcd [192.168.1.8], pleased to meet you mail from: kero@nix.co.jj << 自分のメ−ルアドレス。 250 2.1.0 kero@nix.co.jj... Sender ok rcpt to: katou@nix.co.jj << 宛先のメ−ルアドレス。 250 2.1.5 katou@nix.co.jj... Recipient ok data << ここから本文。 354 Enter mail, end with "." on a line by itself From: k1@nix.co.jj To: k2@nix.co.jj kekkou . << 本文の終わりの印し。 250 2.0.0 l095XOCN017908 Message accepted for delivery << リタ−ンキ−を入れた。 quit Connection closed by foreign host. $ katou@nix.co.jj 宛メ−ル ------------------------ |差出人 k1@nix.co.jj |宛先 k2@nix.co.jj |----------------------- |test [表示]->[オプション] でヘッダ−部表示 ----------------------------------------------------- |Return-Path: |Received: from mail.nix.co.jj (localhost[127.0.0.1]) | by mail.nix.co.jj .. with ESMTP .. | for ... |Received from: 192.168.1.8 (abcd [192.168.1.8]) | by mail.nix.co.jj .. with SMTP .. | for ... |From: k1@nix.co.jj |To: k2@nix.co.jj * 4) メ−ルを telnet アクセスで偽造してみる メ−ルの配送処理を時間を短縮して確認してみる。sendmail.cf をこんなようにしてみる。 メ−ルが一定時間配送されないでキュ−に溜まっていると、未配送であると発信元にメ− ルがいく。デフォルト４時間のところを１分にする。sendmail -bd -q1m & で未配送のメ −ルを１分毎に再送することにする。そして５分後、配送できませんでしたと送信者にエ ラ−メ−ルを返すようにする。ここでは Mail-Relay から telent で発信元と宛先を適当 なメ−ルアドレスにしてメ−ルを出す。宛先は社内の適当な嘘のアドレス。メ−ルは直ぐ に Mail-Relay に戻って /var/spool/mqueue に溜まった。 その後、実際にどうなるかは /var/log/syslog を各自観察のこと。 /etc/mail/sendmail.cf ------------------------- |O Timeout.queuereturn=5m |O Timeout.queuewarn=1m # /etc/rc2.d/S88sendmail stop # sendmail -bd -q1m & # telnet localhost 25 << Mail-Relay の予備機にて。 helo localhost << このマシンのＩＰアドレスまたはホスト名。 mail from: kero1@tcp.or.jj << 自分のメ−ルアドレス。 rcpt to: kero2@nix.co.jj << 宛先のメ−ルアドレス。 data << ここから本文。ピリオドで抜ける。 << ヘッダ−部と本文の区切りのブランク。 emidesu << 京都で会いました。もう終わったかも。 . quit (3) メ−ルの解析はマルチパ−トから * メ−ルのヘッダ−情報などを見る メ−ルの解析は、マルチパ−トつまり MIME というものの理解から始めなければならない。 メ−ルソフトが表示したメ−ルの内容だけ見ても、何も分からない。やってきたメ−ルの 生デ−タそのものを見ないことにはいけない。Microsoft 標準のメ−ルソフト Outlookで はメ−ルの内容が全部表示できない。添付ファイルなんかはアイコンみたいになり、それ をクリックするとまたその中にアイコンみたいなのがあったり。あるいはクリックしても 表示そのものができなかったり。ヘッダ−含む全文を表示するオプションがあって、以前 調べたけどややこしげなとこにあって忘れてしまった。その点 Netscape Messenger はオ プションが分かりやすくてよろしい。メ−ルソフトで受けるのでなく Mail-Store にきた メ−ルを直接見るか。例えば #cat /var/mail/katou とやれば、そのまま生のメ−ルを見 ることができる。ファイルの最後に新しいメ−ルが追加されていく、来たメ−ルは一つの ファイルに連結されていく。# tail -100l /var/mail/katou こうして最新メ−ルを見る。 * サンプルその１ *** 自分宛にメ−ルした *** パソコンの Netscape Messenger から katou 自身にメ−ルした。添付ファイル名123.txt で内容は "123" である。発信ユ−ザは katou。 [ Netscape で受けて普通に表示 ] --------------------------------------------- |Subject: tenpu | Date: Fri, 16 Feb 2007 12:54:30 +0900 | From: かとう | To: katou@nix.co.jj | |katou desu |----------------------------------------- ||□123.txt Name: 123.txt | || Type: Plain Text(text plain)| || Encoding: 7bit | |----------------------------------------- --------------------------------------------- [ Netscape で受けて全部表示 ] [表示]->[ペ−ジのソ−ス] で全部表示した Return-Path: Received: from hostB.nix.co.jj (localhost [127.0.0.1]) by hostB.nix.co.jj (8.12.10) with ESMTP id l1G4Dovv000662 for ; Fri, 16 Feb 2007 13:13:50 +0900 (JST) Received: from nix.co.jj ([192.168.1.9]) by hostB.nix.co.jj (8.12.10) with ESMTP id l1G4DopI000659 for ; Fri, 16 Feb 2007 13:13:50 +0900 (JST) Message-ID: <45D52AF5.3972C851@nix.co.jj> Date: Fri, 16 Feb 2007 12:54:30 +0900 From: =?iso-2022-jp?B?GyRCJCskSCQmGyhC?= X-Mailer: Mozilla 4.78 [ja] (Win98; U) X-Accept-Language: ja MIME-Version: 1.0 To: katou@nix.co.jj Subject: tenpu Content-Type: multipart/mixed; << マルチパ−トですという意味。 boundary="------------36F7A7C8DCB59171BEC376ED" << 境界はこれですという意味。 Status: RO ＼ X-Mozilla-Status: 8001 ｜ X-Mozilla-Status2: 00000000 ｜ この間は関係なし。 X-UIDL: To: The original message was received at Fri, 16 Feb 2007 ... from [192.168.1.9] ----- The following addresses had permanent fatal errors ----- (reason: 550 5.1.1 ... User unknown) ----- Transcript of session follows ----- ... while talking to 127.0.0.1: >>> DATA <<< 550 5.1.1 ... User unknown 550 5.1.1 ... User unknown <<< 503 5.0.0 Need RCPT (recipient) ---------------------------------------------------------- □Part 1.2 Type: message/delivery-status □Part 1.3 Type: Outlook Express メ−ルメッセ−ジ (message/rfc822) [ 返って来たメ−ルを Outlook で受けたところ ] 差出人: Mail Delivery Subsystem 宛先: katou@nix.co.jj 件名: Returned mail: see transcript for details The original message was received at Fri, 16 Feb 2007 ... from [192.168.1.9] ----- The following addresses had permanent fatal errors ----- (reason: 550 5.1.1 ... User unknown) ----- Transcript of session follows ----- ... while talking to 127.0.0.1: >>> DATA <<< 550 5.1.1 ... User unknown 550 5.1.1 ... User unknown <<< 503 5.0.0 Need RCPT (recipient) ---------------------------------------------------------- □ATT00195.dat(457B) □ddd(459バイト).msg(1KB) [ Netscape で受けて全部表示 ] [表示]->[ペ−ジのソ−ス] で全部表示した。 Return-Path: <> Received: from hostB.nix.co.jj (localhost [127.0.0.1]) by hostB.nix.co.jj for Received: from localhost (localhost) by hostB.nix.co.jj From: Mail Delivery Subsystem To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="l1G3dNpI022466.1171597163/hostB.nix.co.jj" << 境界の識別子。 Subject: Returned mail: see transcript for details Auto-Submitted: auto-generated (failure) This is a MIME-encapsulated message --l1G3dNpI022466.1171597163/hostB.nix.co.jj ＼ The original message was received at Fri, 16 Feb 2007 ... from [192.168.1.9] ｜ ｜ ----- The following addresses had permanent fatal errors ----- ｜ (reason: 550 5.1.1 ... User unknown) ｜ ----- Transcript of session follows ----- ｜ ここが本文 Mail-Store からの ... while talking to 127.0.0.1: ｜ メッセ−ジ。 >>> DATA ｜ <<< 550 5.1.1 ... User unknown ｜ 550 5.1.1 ... User unknown ｜ <<< 503 5.0.0 Need RCPT (recipient) ｜ ｜ --l1G3dNpI022466.1171597163/hostB.nix.co.jj ／ Content-Type: message/delivery-status ＼ ｜ Reporting-MTA: dns; hostB.nix.co.jj ｜ Received-From-MTA: DNS; [192.168.1.9] ｜ Mail-Store からのメッセ−ジ。 ｜ Final-Recipient: RFC822; kero@nix.co.jj ｜ Outlook では Action: failed ｜ □ATT00195.dat Status: 5.1.1 ｜ Remote-MTA: DNS; 127.0.0.1 ｜ Diagnostic-Code: SMTP; 550 5.1.1 ... User unknown ／ --l1G3dNpI022466.1171597163/hostB.nix.co.jj Content-Type: message/rfc822 ＼ ｜ Return-Path: ｜ Received: from nix.co.jj ([192.168.1.9]) ｜ by hostB.nix.co.jj for ｜ From: katou ｜ 送ったメ−ルの内容。 MIME-Version: 1.0 ｜ To: kero@nix.co.jj ｜ Outlook では Subject: ddd ｜ □ddd(459バイト) Content-Type: text/plain; charset=iso-2022-jp ｜ Content-Transfer-Encoding: 7bit ｜ ｜ sss ｜ ／ --l1G3dNpI022466.1171597163/hostB.nix.co.jj-- (4) エラ−メ−ルが返って行くところ * メ−ルの返信アドレス メ−ルソフトではヘッダ−部の From: や To: が表示される。メニュ−の返信をクリック すると通常は From: のメ−ルアドレスにメ−ルは行く。Replay-To: にメ−ルアドレスが 書かれていると、From: でなくそちらに行く。またメ−ルソフトでは通常 MAIL From: は From: と同じ、RCPT To: は To: と同じになっている。エンベロ−プは受信したメ−ルの 生デ−タの Received: と Return-Path: に書かれている。 メ−ルソフトでの返信のメ− ルアドレスと SMTP プロトコルでのやりとり時のエラ−メ−ルを返すメ−ルアドレスは別 ものである。SMTPレベルでは MAIL From: コマンドで差出人のメ−ルアドレスを書く。つ まりこれがエンベロ−プのメ−ル差出人であり、エラ−が起きた時ここにメ−ルが返える。 Mail-Relay で katou@nix.co.jj 宛へ /usr/ucb/mail コマンドでメ−ル。 MS /var/mail/katou ------------------------------------------------------------------ |From root@mail.nix.co.jj Tue Apr 10 16:11:40 2007 |Return-Path: |Received: from hostB.nix.co.jj (localhost [127.0.0.1]) | by hostB.nix.co.jj (8.12.10) with ESMTP id l3A7Bevv019551 | for ; Tue, 10 Apr 2007 16:11:40 +0900 (JST) |Received: が幾つか続く | | |Date: Tue, 10 Apr 2007 16:09:58 +0900 (JST) |From: Super-User |Message-Id: <200704100709.l3A79wU6014750@mail.nix.co.jj> |To: katou@nix.co.jj |Subject: 111 << ここら辺りに Replay-To: ikken@xxx.co.jj と書いてあ |Content-Length: 4 ると、メ−ルソフトで返信をクリックして表示されるの | は root@nix.co.jj ではなく、ikken@xxx.co.jj となる。 |222 MS /var/log/syslog システムログに出て来るエンベロ−プ部 ↓ --------------------------------------------------------------------------------- |Apr 10 16:11:40 hostB sendmail[551]: l3A7Bevv019551: from=, |Apr 10 16:11:40 hostB sendmail[553]: l3A7Bevv019551: to=, * バウンスメ−ルとダブルバウンスメ−ル 以下、エンベロ−プの宛先は嘘。社内にそんなメ−ルアドレスの人はいない。Mail-Store の /etc/passwd ファイルには imasen というユ−ザ名は載っていないということ。 差出人は本当。 -------------------------- メ−ルが自社の imasen@nix.co.jj へ来る。そんなユ−ザ | TO:imasen@nix.co.jj | はいない。メ−ルは honnto@tcp.co.jj へ返っていくのみ。 | FR:honnto@tcp.co.jj | これがまず正常な場合。不達メ−ルであるバウンスメ−ル。 -------------------------- 差出人は嘘。 -------------------------- | TO:imasen@nix.co.jj | メ−ルは imasen@tcp.co.jj へ返って行くが、そんなユ− | FR:imasen@tcp.co.jj | ザはいない。バウンスエラ−メ−ルと呼ぶことにする。 -------------------------- 差出人は嘘。Return-Path 別 -------------------------- メ−ルは imasen@tcp.co.jj でなくて、 baka@nnn.con へ | TO:imasen@nix.co.jj | 返って行く。ユ−ザがいる場合はダブルバウンスメ−ルと | FR:imasen@tcp.co.jj | 呼ぶ。そんなユ−ザはいないという場合は、ダブルバウン |------------------------| スエラ−メ−ルと呼ぶことにする。 |Return-Path:baka@nnn.con| -------------------------- 1) メ−ルが来てエンベロ−プ TO の相手がいないと、エンベロ−プFR にエラ−の通知メ −ルがいく。FR が偽造されているとバウンスエラ−メ−ルということになる。 エンベロ−プFR のアドレスがないと 2) へ。 Return-Path: に違うアドレスが書かれていると 3) へ。 2) 何度もその人に再送を繰り返す。 最後に自社のメ−ルサ−バの管理者に通知メ−ルが いく。これで来たメ−ルはキュ−から削除される。これがダブルバウンスメ−ル。 Postmaster 宛に MAILER-DAEMON@nix.co.jj からメ−ル。 3) 全然知らない人へのメ−ルになる。そのアドレスも存在してないと、 また管理者に通 知メ−ルが行く。特にダブルバウンスエラ−メ−ルと呼ぶことにする。 yahoo.co.jp に接続した際のログ Mailbox bounce arrival rate exceeds s) 4) バウンスメ−ル、ダブルバウンスメ−ルが Mail-Relay から出る際、DefensePro でウ ィルス入りメ−ルだと drop される。ちょっとこのロジックは理解できない。 ※エンベロ−プ部については "14-2.電子メ−ル設定の注意 (5)メ−ルの動作原理から"。 ※バウンスメ−ルは送信者アドレスは空だとか MAIL FROM:<>。各自確認されたい。 * Mail-Relay からの管理者宛のメ−ル /etc/aliases -------------------------------- Mail-Relay でnobodyにメ−ルする、/dev/null |nobody: /dev/null はされてないが消える、キュ−にも溜まらない。 |Postmaster: katou@nix.co.jj nobody@nix.co.jj へメ−ルすると Mail-Store |MAILER-DAEMON: katou@nix.co.jj へ行って破棄される。下のログ参照。 偽造されたメ−ルのエラ−メ−ルが、Postmaster 宛に MAILER-DAEMON@nix.co.jj から一 杯来る。ここで Postmaster 宛のメ−ルをちゃんと受けるようにしてないと、そのまたエ ラ−がでる。/etc/aliases で "Postmaster: katou" としていたら、そのまたエラ−にな っていたみたいである。"Postmaster: katou@nix.co.jj" にしたら、どんどん管理者であ る自分に来るようになった。１日に百通ぐらいか。MAILER-DAEMON 宛にはどうもメ−ルは 出てないみたいである。katou@nix.co.jj へは一杯来るので見分けがつかない。確認しや すくするため "MAILER-DAEMON: tomo@nix.co.jj" にして、Mail-Store に来るメ−ルを時 たま # cat /var/mail/tomo とやってみた。丸１日見たがこんかった。 << Mail-Store での syslog >> Mail-Relay で nobody@nix.co.jj へメ−ル。 A: from=, msgid=<.@mail.nix.co.jj>, daemon=MTA-RX, relay=hostA B: from=, msgid=<.@mail.nix.co.jj>, daemon=MTA, relay=localhost A: to=, mailer=esmtp, relay=127.0.0.1, stat=Sent (. Message) B: to=/dev/null, ctladdr= (1/0), mailer=*file*, stat=Sent * 溜まったメ−ルは最後どうなる `25/08 よい子のメ−ルサ−バの構成で、Mail-Store にはメ−ルは溜まらない。Mail-Relay には /var/spool/mqueue に３００ぐらいのファイルが２００５年の８月に見たら溜まっていた。 これらは９９％がゴミ・メ−ルである、全部 more コマンドで内容を確認してみた。溜ま る理由は、先ずは自社宛のメ−ルで Mail-Store にアカウントのないユ−ザへのメ−ルが、 Mail-Store から Mail-Relay に戻ってきて、発信元に返えそうとする。 しかし発信元の メ−ルアドレスが偽造されていて帰える場所がなく、留まってしまう。 以下はメ−ルの溜まる様子と最後である。8月24日 23:51 に外からメ−ルが来て、メ−ル キュ−に入った。sendmail が１時間おきに再送を繰り返し 8月25日 09:13 にも再送を試 みた。送れずにメ−ルキュ−に溜まったままの様子が # mailq で見える。 ５日間再送を 繰り返し、結局だめで異常なメッセ−ジが出る。これはディスプレイにも出ていた。メ− ル本文の dfj7OEp3RZ014885 ファイルは消去されて、 メ−ル封筒情報 qfj7OEp3RZ014885 が Qfj7OEp3RZ014885 に変わって日付は８月２９日になっている。 /etc/mail/sendmail.cf sendmail-8.12.5、cf 作成ツ−ル使用で。 --------------------------- | | デ−モンは /usr/lib/sendmail -bd -q1h が幾つか稼 |O Timeout.queuereturn=5d 働している。Timeout.xxx オプションは、他にも一杯 |O Timeout.queuewarn=4h あった。デフォルトではこの２つだけコメントが外れ | | ていた。sendmail-8.13.8 でも同じだった。 ８月２５日朝 # ls -l /var/spool/mqueue -rw------- 1 root smmsp 1751 8月 24日 23:51 dfj7OEp3RZ014885 -rw------- 1 root smmsp 802 8月 25日 09:13 qfj7OEp3RZ014885 # mailq /var/spool/mqueue (3 requests) -----Q-ID----- --Size-- -----Q-Time----- ------------Sender/Recipient----------- j7OEp3RZ014885 1751 Wed Aug 24 23:51 MAILER-DAEMON (Deferred: Connection timed out with henomohe.com.) ８月２９日夜 # more /var/adm/messages Aug 29 23:57:22 hostA ... j7OEp3RZ014885: Losing ./qfj7OEp3RZ014885: savemail panic Aug 29 23:57:22 hostA ... j7OEp3RZ014885: SYSERR(root): savemail: cannot save rejected email anywhere ８月３０日過 # mailq メ−ルキュ−には j7OEp3RZ014885 はもうない。これでまた５日間過ぎると # ls -l /var/spool/mqueue 下のファイルも消える。 -rw------- 1 root smmsp 805 Aug 29 22:54 Qfj7OEp3RZ014885 mqueueディレクトリを #ls Q*, #ls q*, #ls d* とやって出てくるファイルの数がおかし い。デ−タ部の数( dxxx )、キュ−部の数( qxxx と Qxxx )は一致しないといけないので ないか。上記の例は dxxx がなくなり、qxxx が Qxxx に変化している。 見ていくとまた 最初から dxxx しかない、qxxx しかないのもあったりする。qxxx しかないのはそもそも メ−ルにデ−タ部(本文)がないのだろう。 dxxx しかないのは理解に苦しむ。messagesに 出る他のエラ−、"collect: I/O error on connection from mohe.ne.jj" とか "timeout writing message to ns.baka.jj.: Connection timed out with ns.baka.jj."とか、エラ −の種類によって挙動が多分変わるのだろう。mqueueをずっと見て行ったら６日分のメ− ルが日付として溜まる、例えば９月１日から９月６日とか。ファイル名が qxxx からQxxx に変わろうと６日以上経ったファイルは消えて行いった。よく見たら Mail-Relay ホスト の cron で、find の mtime +4 によりファイルを消すように設定していたのだった。 (5) メ−ルの流れている数を計測する * syslog からメ−ルの数をカウント ともかく今のメ−ルの状況を見てみないことには。一体どれだけのメ−ルが外から来てい るのか、社内からは外へ出しているか。おかしなメ−ルはどれだけあるか。InterScan で はどれだけ弾いているのか。DefenseProも弾いているがどうなのか。現状、これまでずっ とこれらのことは計測してなかった。また計る必要もなかった。しかし、内部ネット内で 飛び交っているメ−ルの数でさえどうやらかなりのものになっているみたいである。メ− ルサ−バがどこまで耐えることができるのか。何もせずほかっていたら、いかな高性能の サ−バマシンを持って来てもダウンの恐れはある。今後３年から５年程度メ−ルサ−バを 自前運用する覚悟ならば、ぜひともメ−ルの流量はこれからは把握して行った方がいい。 Solaris のメ−ルの最新のログは /var/log/syslog にできる。 どんなメ−ルのログが出 るのか。正常な場合のメ−ル、/etc/mail/access で DISCARD した場合のログ、その他い ろんなケ−スを調べてみる。それが分かればシェルのスクリプトで、かなりの集計ができ ると思う。特にログ解析のフリ−ソフトの AWStat とかで、メ−ルの計測をするまでもな いかも知れない。ともかくここでは一番知りたいのは、Greet Pause の対策を取って、迷 惑メ−ルの数がどの程度減るのか、それを定量的に計りたいのである。だいたいでは困る。 おとりの Mail-Relay で Greet Pause の時間を変えて計測すれば、 一番効果的な時間を 見つけることができるはずである。おとりにうまく掛かってくれればいいのだが。 ・Mail-Relay で Greet Pause で捨てた迷惑メ−ルの数。 ・Mail-Relay での外からと内からのそれぞれの数。 ・Mail-Relay での内向きブラックリストに掛かった数。 ・InterScan eManager で弾いた内外の数。(飲み込んで終わり) ・DefensePro で弾いた内外の数。(止めるだけなのでまた来る) * Mail-Relay 予備機での確認 Mail-Relay の /etc/mail/access 同 /etc/aliases --------------------------------- ----------------------------- |Connect:192.168.1.1 RELAY |nobody: /dev/null |To:nix.co.jj RELAY |#root: katou@nix.co.jj |To:katou@nix.co.jj DISCARD [1] |#Postmaster: katou@nix.co.jj |To:postmaster@nix.co.jj DISCARD [2] |#Postmaster: /dev/null [3] |GreetPause:127.0.0.1 0 Mail-Store の /etc/aliases [2] Mail-Relay から postmaster宛のメ−ルはこれで -------------------------- 捨てる。[3] では捨てられずに Mail-Store へメ−ル |nobody: /dev/null は来てしまった。Mail-Relay で aliaseファイルでア |Postmaster: katou カウントがあるユ−ザへの /dev/nullで捨てられると |MAILER-DAEMON: katou 思ったのだができないみたい。nobody@nix.co.jjへメ |root: katou −ルを送ったら Mail-Store で /dev/null された。 [ /var/log/syslog でのログの出方 ] /etc/mail/sedmail.cf の LogLevel=4 a) /usr/ucb/mail satou@nix.co.jj とやった 正常なメ−ル配信のログ Apr 4 14:47:37 hostA sendmail[1714]: ..A001714: from=root, relay=root@localhost Apr 4 14:47:38 hostA sendmail[1714]: ..A001714: to=katou@nix.co.jj, Message) b) /usr/ucb/mail katou@nix.co.jj とやった 正常なログの間に discard が出ている Apr 4 14:28:14 hostA sendmail[1683]: ..V001683: from=root ... Apr 4 14:28:14 hostA sendmail[1684]: ..P001684: ruleset=check_rcpt ... discard Apr 4 14:28:15 hostA sendmail[1683]: ..V001683: to=katou@nix.co.jj ... Message) ※/usr/ucb/mail postmaster@nix.co.jj とやっても同じく discard が出て捨てられた。 c) Greet Pause で捨てた Apr 4 05:42:07 hostA sendmail[1532]: ..e001532: rejecting commands from ms7.wbs .con [66.xx.110.yy] due to pre-greeting traffic d) /usr/ucb/mail katou とやった メ−ルはどこかに消えた Apr 4 14:33:35 hostA sendmail[1687]: ..N001687: from=root ... Apr 4 14:33:35 hostA sendmail[1688]: ..O001688: User unknown Apr 4 14:33:35 hostA sendmail[1687]: ..N001687: to=katou ... stat=User unknown Apr 4 14:33:35 hostA sendmail[1687]: ..N001687: ..XZIO001687: DSN: User unknown Apr 4 14:33:36 hostA sendmail[1687]: ..O001687: to=root ... Message) Apr 4 14:33:36 hostA sendmail[1690]: ..Q001688: Warning: program /usr/lib/mail.local unsafe: Group writable directory ※このメ−ルは Mail-Store に来てない。Mail-Relay の /var/spool/mqueue にもない。 [ メ−ルの数の数え方 ] ・from の数を数えればメ−ルの総数が分かるのでないか。to だと d) ので２つ出てくる。 ・discard の数で access のブラックリストに載せたやつ。 ・greeting の数で Greet Pause で捨てたやつ。 * Mail-Store での場合 Mail-Store のマシンでは InterScan が動いていて、それを sendmail がサンドイッチし ている。ログは２つの sendmail から出ることになる。正常な配送なら from は２回出る。 /usr/lib/sendmail -bd -q1h -C/etc/mail/sendmail-rx.cf これら LogLevel は9。 /usr/lib/sendmail -bd -q1h -C/etc/mail/sendmail-tx.cf [ 自分にメ−ルを送ってみた ] Process-ID (１つ sendmail が起動 するとユニ−クなＩＤが付けられる) # tail /var/log/syslog ↓ Apr 5 11:17:37 hostB sendmail[22047]: [ID 801593 mail.info] ..22047: from=, proto=SMTP, daemon=MTA-RX, relay=[192.168.1.9] Apr 5 11:17:37 hostB sendmail[22055]: [ID 801593 mail.info] ..22055: from=, proto=ESMTP, daemon=MTA, relay=localhost [127.0.0.1] Apr 5 11:17:37 hostB sendmail[22054]: [ID 801593 mail.info] ..22047: to=, stat=Sent (2.0.0 ..22055 Message accepted for delivery) Apr 5 11:17:37 hostB sendmail[22057]: [ID 801593 mail.info] ..22055: to=katou, mailer=local, relay=local, dsn=2.0.0, stat=Sent [ パソコンに届いたところ ] パソコンのＩＰアドレスは 192.168.1.9。POP3 で取得。 メ−ルソフトは Outlook 使用。 Return-Path: Received: from hostB.nix.co.jj (localhost [127.0.0.1]) by hostB.nix.co.jj (8.12.10) with ESMTP id l352Hbvv022055 for ; Thu, 5 Apr 2007 11:17:37 .. 下からここに来る Received: from katou ([192.168.1.9]) by hostB.nix.co.jj (8.12.10) with ESMTP id l352HapI022047 for ; Thu, 5 Apr 2007 11:17:36 .. ここを通って上へ From:"katou" To: | [ ログを見易くしてみた ] A=l352HapI022047 B=l352Hbvv022055 と表示 sendmail[22047] A from= SMTP MTA-RX relay=[192.168.1.9] sendmail[22055] B from= ESMTP MTA relay=localhost [127.0.0.1] sendmail[22054] A to= 送った sendmail[22057] B to=katou sendmail-rx.cf の処理 順番を時刻順に並べかえてみた ↓ sendmail[22047] A from= SMTP MTA-RX relay=[192.168.1.9] sendmail[22054] A to= 送った sendmail[22055] B from= ESMTP MTA relay=localhost [127.0.0.1] sendmail[22057] B to=katou ↑ sendmail-tx.cf の処理 * panic を起こしたメ−ル これは Mail-Relay の予備機で意図的にパニックを起こしてみた。本番機からメ−ルキュ −のファイルをコピ−してきて、予備機をネットワ−クから切り離した。メ−ルは行く場 を失ってパニックを起こした。モニタにも出た。メ−ルはどこへも行くことなくキュ−に ゾンビ化して溜まったままになる。/var/log/syslog。 Feb 22 14:41:39 hostA sendmail[931]: XXX: Losing ./qfXXX: savemail panic Feb 22 14:41:39 hostA sendmail[931]: XXX: SYSERR(root): savemail: cannot save rejected email anywhere * hostG からメ−ルを打った場合の履歴 `28/08 hostG# /usr/ucb/mail -v katou@nix.co.jj << mailコマンドで社内の katou にメ−ル。 以下は PC でメ−ルを受けたところ。 Received from hostB.nix.co.jj 4) by hostB.nix.co.jj (8.12.10+Sun/8.12.10) with .. for Received from hostG.nix.co.jj 3) by hostB.nix.co.jj (8.12.10+Sun/8.12.10) with .. for Received from hostG.nix.co.jj 2) by hostG.nix.co.jj (8.12.10+Sun/8.12.10) with .. for Received:( from root@localhost ) 1) by hostG.nix.co.jj (8.12.10+Sun/8.12.10/Submit) with .. for katou@nix.co.jj -------------- -------------- < hostG > | hostG | | hostB | root /usr/lib/sendmail -bd -q15m 1) |-----2)-----| 3) |-----4)-----| smmsp /usr/lib/sendmail -Ac -q15m ―→|| |→| || ―→ || |→| || |----- -----| |----- -----| hostBにPOP3でメ−ル取得 -------------- -------------- <--- □ PC | FireWall | Mail-Store ｜ hostG,B の sendmail は --------------------------------------------------- 8.12.10 とか。 < hostB > このホストは InterScan が稼働していて２つの sendmail が動いている。 root /usr/lib/sendmail -bd -q1h -C/etc/mail/sendmail-rx.cf root /usr/lib/sendmail -bd -q1h -C/etc/mail/sendmail-tx.cf 1)は来たメ−ルを hostG の sendmail -Ac -q15m が /etc/mail/submit.cf ファイルを見 て、/var/spool/clientmqueue/ クライアント専用キュ−に入れる。 2)では /var/spool/clientmqueue のメ−ルを hostG の sendmail -bd -q15m が、 hostG の /var/spool/mqueue に入れる。 3)は hostG の sendmail -bd -q15m が、hostG の /var/spool/mqueue のメ−ルを hostB の sendmail-rx.cf の sendmail とで /var/spool/mqueue-rx へメ−ルを送る。 4)は hostB の /var/spool/mqueue-rx に来たメ−ルを、sendmail-tx.cf の sendmail で /var/spool/mqueue へメ−ルを入れる。 [ hostB からメ−ルを打った場合の履歴 ] Return-Path: Received from hostB.nix.co.jj (localhost [127.0.0.1]) by hostB.nix.co.jj (8.12.10+Sun/8.12.10) with .. for Received from hostB.nix.co.jj (localhost [127.0.0.1]) by hostB.nix.co.jj (8.12.10+Sun/8.12.10) with .. for Received:( from root@localhost ) by hostB.nix.co.jj (8.12.10+Sun/8.12.10/Submit) with .. for katou@nix.co.jj From: Super-User ↑ ｜ sendmail -Ac -q15m が /etc/mail/submit.cf ファイルを見て処理する。 sendmail-8.12.x 代で入った機能らしい。安全のため root 権限でなく smmsp 権限で稼働する。 * Mail-Relay でのメ−ルのログ `28/08 # grep LogLevel /etc/mail/*.cf sendmail.cf:O LogLevel=4 submit.cf:O LogLevel=9 subsidiary.cf:O LogLevel=9 # ps -ef | grep sendmail root 150 Sep 13 ... /usr/lib/sendmail -bd -q1h -C/etc/mail/sendmail.cf root 6921 10:40:21 ... /usr/lib/sendmail -bd -q1h -C/etc/mail/sendmail.cf | smmsp 163 Sep 13 ... /usr/lib/sendmail -Ac -q15m Mail-Relay の syslog の出方がおかしいことに気付いた。Solaris 9 でsendmail-8.14.1。 メ−ルの送受信のログが出ていない。 mail.warning と mail.notice と mail.crit とい うエラ−になったのは出ているが、ちゃんと送受信できた mail.infoというのが出ていな い。しかし Mail-Relay のマシンに入って #/usr/ucb/mail ikken@tcp.or.jj とやってメ −ルを出すと、syslog には .. mail.info .. to= .. Message accept ed for delivery) というように出てくる。Mail-Relay で # mail ikken@tcp.or.jj とや ると、/usr/lib/sendmail -Ac -q15m デ−モンが監視していて、/etc/mail/submit.cf フ ァイルを使う。メ−ルは /var/spool/clientmqueue/ に入る。 Mail-Relay の submit.cf の LogLevel は 9 なので、 /var/log/syslog に送受信のログ が出る。しかし Mail-Store や外からのメ−ルは /usr/lib/sendmail -bd -q1h の方が処 理する、この sendmail.cf の LogLevel が 4 になっていたため、内外のメ−ル送受信の ログは出なかったということである。Mail-Relay では Greet Pause の効果をみるだけな ら LogLevel=4 にすれば、 SMTP 接続を待たせて諦めたメ−ルのシステムログは出て来る。 しかし全部のメ−ルの流れを把握したいのであれば LogLevel=9 にしておかないといけな い、でないと mail.info のシステムログが出て来ない。 [ Mail-Relay に溜まるメ−ル ] Solaris 2.6 の SS5 では、Mail-Relay のメ−ルキュ−に溜まったメ−ルをクロ−ンで消 去していた。Solaris 9 の新しいマシンに変えてからはやっていなかった。mailq で見た ら千通以上溜まっていた。相手先が存在しないとか "User unknown" なメ−ルである。や はり自動消去していくようにしないといけない。早々にやりたい。# ps -ef | grep send で見たら /usr/lib/sendmail -bd -q1h -C/etc/mail/sendmail.cf プロセスも一杯できて いた。しかし vmstat で見ても全然、負荷はかかっていなかった。ゾンビ化したようなプ ロセスはやはり幽霊なため、負荷もないのだろう。 以下のようなログが /var/log/syslog に一杯でていた。これは Greet Pause のログでは ないと思う、Greet Pause なら pre-greeting traffic というように出て来るはずである。 多分、エラ−メ−ルで返ろうとして相手先のＭＸレコ−ドにアクセスしたのだが、返事が 帰って来なくてタイムアウトになったログだと思う。Mail-Relay が SS5 の時は、ディス クの容量で少なかったのでメ−ルのシスログは取っていなかった。多分、昔からこのログ は出ていたのでないか。例えばこんなログ ... [ID xxxx mail.notice] xxxxxx: timeout waiting for input from f.mx.mail.yahoo.com. during client greeting。 * 参考 「Software Design」2006/08, P.50〜57, "４章 徹底解説！ Postfix のログ解析"。 > AWstat が紹介されている。よさそうだが Apache や Perl が必要。 http://www.bflets.dyndns.org/Tools/AWStatsJpn.html > AWStats 6.5 完全日本語版のペ−ジ。 「NETWORK MAGAZINE」2007/01, P.96〜99, "かんたんsendmail運用術,最終回|ログの管理"。 > フリ−ソフト Sendmail log analyzer。http://www.klake.org/sma/。 * もう一度 Mail-Store の場合 付録だったのをここに `2h/11/E パソコン katou@nix.co.jj から ikken@tcp-ip.or.jj へメ−ルを送ったところ。 システ ムログを必要部分のみ表示した。自分も相手アドレスも２回ずつ出ている。これは、正常 にメ−ル送信ができた場合のログである。分かりにくいところなので、なんべんでも確認 してみている。 Jun 4 15:25:15 .. from= .. msgid=<..katou@nix.co.jj>, daemon=MTA-RX, relay=[192.168.1.9] Jun 4 15:25:15 .. from= .. msgid=<..katou@nix.co.jj>, daemon=MTA, relay=localhost [127.0.0.1] Jun 4 15:25:16 .. to= .. relay=127.0.0.1 ( Message accepted for delivery) Jun 4 15:25:16 .. to= .. relay=[192.168.2.1] ( Message accepted for delivery) # tail /var/log/syslog メ−ルを送ってすぐにやった。省略なしのログ。 Jun 4 15:25:15 hostB sendmail[21398]: [ID 801593 mail.info] l546PFpI021398: from =, size=483, class=0, nrcpts=1, msgid=, proto=SMTP, daemon=MTA-RX, relay=[192.168.1.9] Jun 4 15:25:15 hostB sendmail[21403]: [ID 801593 mail.info] l546PFXm021403: from =, size=663, class=0, nrcpts=1, msgid=, proto=ESMTP, daemon=MTA, relay=localhost [127.0.0.1] Jun 4 15:25:16 hostB sendmail[21401]: [ID 801593 mail.info] l546PFpI021398: to= , delay=00:00:01, xdelay=00:00:01, mailer=esmtp, pri=120483, relay=127.0.0.1 [127.0.0.1], dsn=2.0.0, stat=Sent (2.0.0 l546PFXm021403 Message accepted for delivery) Jun 4 15:25:16 hostB sendmail[21407]: [ID 801593 mail.info] l546PFXm021403: to= , delay=00:00:01, xdelay=00:00:00, mailer=smtp, pri=120663, relay=[192.168.2.1] [192.168.2.1], dsn=2.0.0, stat=Sent (l546LR7I023641 Message accepted for delivery)