戻る
0001 see /var/log/messages intro
/var/log/messagesの抜粋
/var/log/messages の sendmail に 関係する 内容を 見てみよう これらは
たまたま 有ったというだけであり すべてということでは おへんhost という所には 其々の 計算機の 名前が 入ります
例えば ”neco.catland.kingdom” という ものであれば ”neco”が 入ります、
また IP アドレス とか ドメイン 等は そのままに してあります。良いか悪い
か は 別として その様な できごとが 発生したと 言う事です。"badmail_data"
というものに /var/log/messages の 中から sendmail に 関連するものを 抜き
出してあります その中の 一部分を 見てみましょう。
Sep 8 17:10:04 host sendmail[2858]:j888A3fv002858:
ruleset=check_rcpt, arg1=<pp168@so-net.net.tw>,
relay=61-216-82-185.dynamic.hinet.net [61.216.82.185],
reject=550 5.7.1 <pp168@so-net.net.tw>... Relaying denied
Sep 8 17:10:04 host sendmail[2858]: j888A3fv002858:
lost input channel from 61-216-82-185.dynamic.hinet.net [61.216.82.185]
to MTA after rcpt
Sep 8 17:10:04 host sendmail[2858]: j888A3fv002858:
from=<fgsgmaildsfa@msa.hinet.net>, size=0, class=0, nrcpts=0,
proto=SMTP,
daemon=MTA, relay=61-216-82-185.dynamic.hinet.net [61.216.82.185]
Sep 8 17:11:17 host sendmail[2859]: j888BGRt002859:
ruleset=check_rcpt, arg1=<popogigi1975@yahoo.com.tw>,
relay=[219.133.174.225], reject=550 5.7.1
<popogigi1975@yahoo.com.tw>... Relaying denied.
IP name lookup failed [219.133.174.225]
Sep 8 17:12:08 host sendmail[2859]:
j888BGRt002859: lost input channel from [219.133.174.225] to MTA after rcpt
要するに この様な あまり好ましからぬ お客の 足跡が残ってると云うこと
です。
Relaying Denied/Allowed (in sendmail 8.8/8.9-8.12)
http://www.sendmail.org/~ca/email/relayingdenied.html
色々 ゑー部を彷徨うこと 燦然哩 上記の所をたまたま参考にすると
550 5.7.1 ... Relaying denied
に関する事柄として このような 例が 載っている
1.Correct DNS data
QAA02454: <ESCAPEFOUR@AOL.COM>... Relaying denied
QAA02454: ruleset=check_rcpt, arg1=<ESCAPEFOUR@AOL.COM>,
relay=170-51-209.ipt.aol.com [152.170.51.209], reject=550
<ESCAPEFOUR@AOL.COM>... Relaying denied
QAA02454: from=<Anonymous@aol.com>, size=0, class=0, pri=0, nrcpts=0,
proto=SMTP, relay=170-51-209.ipt.aol.com [152.170.51.209]
Here, the machine with hostname 170-51-209.ipt.aol.com and
the IP address 152.170.51.209
tried to deliver an e-mail to <ESCAPEFOUR@AOL.COM>. However, this has been denied
since neither the recipient <ESCAPEFOUR@AOL.COM> is a local recipient
nor is the relaying machine 170-51-209.ipt.aol.com a local sender.
この場合 は
170-51-209.ipt.aol.com という 計算機
IP address 152.170.51.209 ものが
ESCAPEFOUR@AOL.COM いう 所に 郵便を 配送し
ようと しているが 拒否される
理由は
ESCAPEFOUR@AOL.COM が local の 受信者 若し
くは
170-51-209.ipt.aol.com の 計算機が local の 送信者
で有る場合ということのようです
次のような 場合は
2. Missing DNS data
QAA02454: <ESCAPEFOUR@AOL.COM>... Relaying denied
QAA02454: ruleset=check_rcpt, arg1=<ESCAPEFOUR@AOL.COM>,
relay=[134.245.85.93], reject=550 /* IP Adr だけに なっている */
<ESCAPEFOUR@AOL.COM>... Relaying denied
QAA02454: from=<Anonymous@aol.com>, size=0, class=0, pri=0, nrcpts=0,
proto=SMTP, relay=[134.245.85.93]
This is the same as above, but this time no PTR record for the IP
address 134.245.85.93 was found.
This causes problems if that machine is a local sender, but relaying is
enabled only based on host/domainnames
(e.g., FEATURE(relay_entire_domain)).
You can either add PTR records for these IP addresses to your DNS,
or add IP numbers (or nets) to the relevant classes or maps ( see below,
first case).
この場合は IP address 134.245.85.93 に対する PTR record が無いよ という
ことのようです 追加必要というより 表示を敢えて避けている場合が 多いようです
PTR (domain name PoinTeR)
いわゆる逆引き （つまり IP Adr 134.245.85.93 に 対する ものが 無い）
次のような 場合は
3. Inconsistent DNS data
QAA02454: <ESCAPEFOUR@AOL.COM>... Relaying denied
QAA02454: ruleset=check_rcpt, arg1=<ESCAPEFOUR@AOL.COM>,
relay=some.domain [10.0.0.1] (may be forged),reject=550
<ESCAPEFOUR@AOL.COM>... Relaying denied
QAA02454: from=<Anonymous@aol.com>, size=0, class=0, pri=0, nrcpts=0,
proto=SMTP, relay=some.domain [10.0.0.1] (may be forged)
Here the (may be forged) is the important part:
it means that the DNS data for the host
is inconsistent, and hence the name is not used for the relaying check
but only the IP number.
So this is the same situation as before. If the host name would be used,
it would be simple to circumvent basic anti-relaying checks because
the PTR records might be under the control of an attacker,
so he can chose any name he wants for his IP address.
That is, he can select a name for which you allow relaying because
that name is one that you control (your domain name). However,
the forward (A) lookup will fail or give at least a different IP
address, hence the name is marked as (may be forged)
IP address が一致しないよ ということでしょうか
”he can chose any name he wants for his IP address.
That is, he can select a name for which you allow relaying because
that name is one that you control (your domain name).”
つまり
some.domain [10.0.0.1] である場合 [10.0.0.1] は 他人が コントロール
some.domain が 自分の 場合
some.domain の IP Adr を 調べると [10.0.0.1] でなく[43.876.87.77] となっ
ているかも しれない
通常は 或る 組合せとして somedomain.com.gf IP Adr [43.876.87.77] となっ
ている時に
somedomain.com.gf IP Adr [10.0.0.1] で 申し込まれると どうなるんだ とい
うことの 様です
http://www.melma.com/backnumber_125293_895876/
http://wwwsoc.nii.ac.jp/cgi-bin/lsdproj/ejlookup04.pl?lang=Japanese&query=circumvent&mode=include
上記参考に circumvent の 意味は
note :circumvent : 回避する, 包囲する, 出し抜く [かいひする, ほうい
する, だしぬく]
包囲する（しばしば計略を用いて）・わなにかける・回る・迂回する・逃れる・人を出し抜く
と云うことのようである
次のような 場合は
lost input channel from [219.133.174.225] to MTA after rcpt
http://www.monkey.org/openbsd/archive/misc/0306/msg01334.html
上記参考にすると
"Lost input channel" does not mean lossy network. It means that
the connection was somehow closed without getting a "QUIT" command.
That could be the result of
defective client software
network problems
The most common cause of "lost input channel" that I see is from
spammer software. Those too often don't say bye nicely. You can't
fix those with mtu. (at least, not nicely.)
なにか 無造作に 切断した場合が 多いようです 全てでは有りませんが。
どうも このままでは 何が何だかわかんねい状態に 陥りそうです
一部削除
適当に整理するために 一部削除します。 方法は適当に
$ sed -e 's/host sendmail//' badmail_data | sed -e 's/[[0-9]*]//'>nyanta_bad_mail001
その結果の 抜粋（ データーの 一部 を 上記処理にて 削除したもの） 又改
行も 適当に している これに ついて少し見てみましょう 少なくともj888A3fv002858と j888BGRt002859 の 組で 異なる
所から アクセスしている というか メールの 番号としては 異なるものと 言う
事は 理解できると 思います。
Sep 8 17:10:04 : j888A3fv002858:
ruleset=check_rcpt, arg1=<pp168@so-net.net.tw>,
relay=61-216-82-185.dynamic.hinet.net [61.216.82.185], reject=550 5.7.1
<pp168@so-net.net.tw>... Relaying denied
Sep 8 17:10:04 : j888A3fv002858:
lost input channel
from 61-216-82-185.dynamic.hinet.net [61.216.82.185] to MTA after rcpt
Sep 8 17:10:04 : j888A3fv002858:
from=<fgsgmaildsfa@msa.hinet.net>,
size=0, class=0, nrcpts=0, proto=SMTP, daemon=MTA,
relay=61-216-82-185.dynamic.hinet.net [61.216.82.185]
Sep 8 17:11:17 : j888BGRt002859:
ruleset=check_rcpt, arg1=<popogigi1975@yahoo.com.tw>,
relay=[219.133.174.225], reject=550 5.7.1 <popogigi1975@yahoo.com.tw>
... Relaying denied.
IP name lookup failed [219.133.174.225]
Sep 8 17:12:08 : j888BGRt002859:
lost input channel
from [219.133.174.225] to MTA after rcpt
j888A3fv002858 の 組にて 考えてみると
受信者アドレス pp168@so-net.net.tw
接続元サーバ 61-216-82-185.dynamic.hinet.net [61.216.82.185]
送信元アドレス fgsgmaildsfa@msa.hinet.net
つまり
fgsgmaildsfa@msa.hinet.net というものから （これは 表現が？であるが）
| [ msa.hinet.net 168.95.4.211]
V
61-216-82-185.dynamic.hinet.net [61.216.82.185] 発信元
|
V
自分の サーバー : ここで 中継の お断りをした
X : これ以上は 送らないよ！
|
V [ so-net.net.tw 61.64.127.16]
pp168@so-net.net.tw
なんで こんな ややこしい事を するのでしょう？？？、なにか 見通しが 良
く有りません が 素人の にゃんたろうに とっては 仕方のないことです。とに
かく このような log が 残されていて あまり 好ましくない お客様の ようです。
戻る
にゃんたろう 拝！
2006年 9月 7日 (木) 21:48:27 JST 作成
Copyright © 2004.-2007.
nyantarou
All Rights Reserved.