- PR -

６時間後にメールが届くのは何故ですか？

«前のページへ 1|2|3 次のページへ»
投稿者投稿内容
NeXT
大ベテラン
会議室デビュー日: 2004/04/06
投稿数: 215
お住まい・勤務地: 江戸
投稿日時: 2006-03-13 17:33
例えば，第三者 relay check については
http://www.rbl.jp/svcheck.php
を参照してみては如何でしょうか。
上記サイトには他にも色々と情報が掲載されています。

> Mar 13 07:57:30 mail sendmail[30150]: NOQUEUE: pl049.nas929.o-tokyo.nttpc.ne.jp
> [***.***.***.***] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA

http://www.spamcop.net/w3m?action=checkblock&ip=202.229.200.49

登録されているようですね。
# 登録されているからといって必ずしも spam の発信源とは限りませんが。
はゆる
ぬし
会議室デビュー日: 2004/02/16
投稿数: 1008
お住まい・勤務地: 首都圏をウロウロと
投稿日時: 2006-03-13 17:48
こんにちは。

「６時間後にメールが届く」 とのことですが、
まずはじめに、メール配送の仕組みをご理解ください。
こちら の 「図1」 を参考にしますと、
背景色が黄色いところが、クライアント PC で、
水色の 「POP3 サーバ」 「MTA（Mail Transfer Agent）」
の間にあるのが、今回対象にしているサーバだと
思っていただければと思います。
「SMTP ルーティング」 にある他のサーバは、
同一ネットワークやインターネット上のメールサーバに
なります。

sendmail のお仕事は、上記の図にある 「MTA」 の部分で、
POP3 サーバは別のソフトウェアが担当しています。
# MTA のお仕事の詳細は、ここ の 「図1」 などが参考になります


……前置きが長くなってしまいましたが、
今回の投稿とログを拝見して、
真っ先に思いついたスレがありますので、
ご覧になってみてくださいね。

　・ メールが
Ｒ・田中一郎
ぬし
会議室デビュー日: 2005/11/03
投稿数: 979
投稿日時: 2006-03-13 18:01
引用:

kazさんの書き込み (2006-03-13 16:47) より:

で，その際の「配信しようとしてできなかった」側の "１" ではどのような log が？


log は確認しておりませんが、メールが遅れなかった旨のメールがサーバー１のデー
モンから届いています。

引用:

kazさんの書き込み (2006-03-13 16:47) より:

戻ってきている，あるいは戻そうとしているのに「disk quota exceeded」なのでは？
つまり「送られている」のは特定の E_mail address ではなく
任意の E_mail address で，偽証している E_mail address に戻ってきているのでは？
その意味では「送られ続けている」という表現も可能でしょうけど，
この場合は妥当ではないと思います．
で，大量に戻ってきているために sendmail で制限している
session 数を超えてしまって，
結果として「外部からの配信を受け付けられない」とか．．．
※もしかして，sendmail で設定した上限を先読みして
※最初から同時に session 数を 20 で接続しに来て踏み台にしているとか．．．
それが「特定の時間帯」に実施されているとしたら．．．


実は、このご説明をいただいて、メールが受信できなくなっている時間帯のログを片
っ端から見てみると、問題のサーバーのアカウントのアドレスと、見たことの無いア
ドレスが、メールが受信できなかった時間帯に大量にログに記録されているところが
見つかりました。
サーバーのアカウントのアドレスは、全て「disk quota exceeded」で、見たことの
無いアドレスも、to 側だったので　？　だったのですが、多分スパムの送り主のア
ドレスなんだと思われます。

引用:

kazさんの書き込み (2006-03-13 16:47) より:

第三者 relay はちゃんと抑制していますか？


はい。これは既にテスト済みで全く問題ありません。
このため、不達メッセージのメールをスパムの送り主にシステムから送ろうとして
エラーになったのだと思います。

とりあえず、sendmail.cf で同時接続数を増やしてキュー保持期間を短くして様子
を見てみようと思います。

ありがとうございました。
Ｒ・田中一郎
ぬし
会議室デビュー日: 2005/11/03
投稿数: 979
投稿日時: 2006-03-13 18:08
引用:

NeXTさんの書き込み (2006-03-13 17:33) より:

例えば，第三者 relay check については
http://www.rbl.jp/svcheck.php
を参照してみては如何でしょうか。


ありがとうございました。
以前、テストはしたものの気になって試してみたら、「no relays accepted.」に
なりました。安心しました。

引用:

NeXTさんの書き込み (2006-03-13 17:33) より:

登録されているようですね。
# 登録されているからといって必ずしも spam の発信源とは限りませんが。


こんなことまでわかっちゃうんですね。
Ｒ・田中一郎
ぬし
会議室デビュー日: 2005/11/03
投稿数: 979
投稿日時: 2006-03-13 18:15
引用:

はゆるさんの書き込み (2006-03-13 17:48) より:

まずはじめに、メール配送の仕組みをご理解ください。
こちら の 「図1」 を参考にしますと、


ご丁寧にありがとうございました。
一応、仕組みは理解できているとは思うのですが、改めて見ると微妙かもしれません。

引用:

はゆるさんの書き込み (2006-03-13 17:48) より:

今回の投稿とログを拝見して、
真っ先に思いついたスレがありますので、
ご覧になってみてくださいね。

　・ メールが


参照させていただきました。ありがとうございました。
kaz
ぬし
会議室デビュー日: 2003/11/06
投稿数: 5403
投稿日時: 2006-03-13 18:16
引用:

Ｒ・田中一郎さんの書き込み (2006-03-13 18:01) より:

このため、不達メッセージのメールをスパムの送り主にシステムから送ろうとして
エラーになったのだと思います。

とりあえず、sendmail.cf で同時接続数を増やしてキュー保持期間を短くして様子
を見てみようと思います。

それは逆効果では無いでしょうか？
戻ってくるのはそのままで，負荷もそのまま．
本を絶たないとダメだと思います．
Ｒ・田中一郎
ぬし
会議室デビュー日: 2005/11/03
投稿数: 979
投稿日時: 2006-03-13 18:52
kazさん、いろいろとありがとうございます。

引用:

kazさんの書き込み (2006-03-13 18:16) より:
引用:

Ｒ・田中一郎さんの書き込み (2006-03-13 18:01) より:

このため、不達メッセージのメールをスパムの送り主にシステムから送ろうとして
エラーになったのだと思います。

とりあえず、sendmail.cf で同時接続数を増やしてキュー保持期間を短くして様子
を見てみようと思います。

それは逆効果では無いでしょうか？

そうなんですか？
一応、キュー保持期間が５日の場合、５日分の不達メールの再送にサーバーが翻弄
されることになるため、２日に減らせば、その瞬間においての再送する絶対量は減
らせると考えました。
同時接続数を増やしたのは、スパムの踏み台にされそうになっただけで、障害がで
るということを避けたかったからなのですが。

引用:

kazさんの書き込み (2006-03-13 18:16) より:

戻ってくるのはそのままで，負荷もそのまま．
本を絶たないとダメだと思います．

この場合の元とは、攻撃者のことでしょうか？
それともキューを削除した方が良いということでしょうか？

キューの削除については、２日に短縮したことでデーモンがやってくれると思い
ました。
攻撃者については、アクセス制限をかけるのが良いのでしょうか。
はゆる
ぬし
会議室デビュー日: 2004/02/16
投稿数: 1008
お住まい・勤務地: 首都圏をウロウロと
投稿日時: 2006-03-13 19:17
引用:

Ｒ・田中一郎さんの書き込み (2006-03-13 18:01) より:
サーバーのアカウントのアドレスは、全て「disk quota exceeded」で、見たことの
無いアドレスも、to 側だったので　？　だったのですが、多分スパムの送り主のア
ドレスなんだと思われます。

「dsn=4.2.0, stat=Deferred: 450 4.2.0 disk quota exceeded」
ですから、
該当ユーザのメールボックスがパンクしています。
ご対応を。

いずれにせよ、

引用:

Ｒ・田中一郎さんの書き込み (2006-03-13 09:25) より:
Mar 13 07:58:07 mail sendmail[18440]: waiting fork MTA: 20 children, max 20
Mar 13 07:58:38 mail last message repeated 31 times
Mar 13 07:59:39 mail last message repeated 61 times
Mar 13 08:00:40 mail last message repeated 61 times
Mar 13 08:01:41 mail last message repeated 60 times
：
中略
　：
Mar 13 08:04:44 mail last message repeated 61 times
Mar 13 08:05:45 mail last message repeated 61 times
Mar 13 08:06:46 mail last message repeated 61 times
Mar 13 08:31:01 mail last message repeated 52 times

な状態ですから、
sendmail がフル稼働しているのは事実でしょうか。
# 「20」 という上限は、理由があるのかしら？

不正中継チェックは大丈夫なようですから、
spammer に占有されている可能性は低いとすると、

　・ ウイルスに感染して、社内から大量にメールを発信していないか
　・ メーリングリスト（fml）で何か起きていないか

あたりを調べてみたほうがよいかもしれませんね。
maillog で見るのなら、「to=」 じゃなくて 「from=」 を。
同時刻に、syslog に何か書かれていないかなども、
あわせて見ておいたほうがよいかもしれません。
«前のページへ 1|2|3 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）