• 締切済み

【sendmail】mqueueの再送について

はじめまして。 sendmailを使ってのMTAの運用をしているのですが、sendmailの仕様でわからないことがあり困っています。 ある宛先のメールが[stat=deffered,no such file or directory ]というメールログが出力されていて、 送信できませんでした。 調べると送信先のメールサーバの負荷がそのとき高かったので送信できなかったというとはわかりました。 その時、そのメールは「mqueue」に保留されていたようです。 ただ、その宛先へ再送されたのが上記エラーが出た6日後でした。 教えていただきたいのは、 sendmailの仕様として、「mqueue」に保管されたメールの再送タイミングは、 どこか(sendmail.cf)に設定があるのでしょうか。 また、メールの再送が6日後になったことについて、考えられる原因はなんでしょうか。 一定期間で再送されるものではないのでしょうか。 当時の状況としては、 1.「mqueue」には約8000件のメールがたまっていました。 (ほとんどが送信元偽装のSPAMのリターンメール) 2.送信先サーバは、負荷が高かったようです。 教えてもらいたいことは、 1.「mqueue」の再送は、sendmail.cfに設定がありますでしょうか。 2.「mqueue」の再送は、古いものから順に再送されるのでしょうか。 3.6日間再送されなかった原因として想定されることはなんでしょうか。 4.このようなことを防止する策としてはどのようなことがあるのでしょうか。 以上、ご教授いただけると幸いです。宜しくお願いします。

みんなの回答

  • uwi
  • ベストアンサー率74% (55/74)
回答No.3

sendmail.cfなら キューを処理する最短時間 O MinQueueAge=30m 失敗してから再送するまで O Timeout.hoststatus=30m 返送するまでの時間 O Timeout.queuereturn=5d 対処としては処理が重いと処理全体が失敗することがあるので O RefuseLA=12 Load Averageがしきい値を超えている場合、新規を拒否するような設定もあります。 スパムが主原因とわかっているならそっちの対策した方がいいと思いますが。 ちなみにRFC5321にSMTPの再送のことが書いてあります。 ・再送信の間隔は少なくとも30分であるべきである。 ・再試行をあきらめるまでの時間は一般に4、5日である必要がある。 ・最初の1時間の内に2回、その後は2、3時間に一度に頻度を落とすのが望ましい。 SHOULDなのでしなければならないわけではないですが、存在すら知らないで守らないのはアレなので一度目を通すことを勧めます。(もう読んでたらごめんなさい)

  • pakuti
  • ベストアンサー率50% (317/631)
回答No.2

1.「mqueue」の再送は、sendmail.cfに設定がありますでしょうか。 ディストリビューション によっては異なりますが、最近のものであれば、ほぼ同じです。 /etc/sysconfig/sendmail内にある、QUEUE= で設定してあります。 通常は1時間です。 少し古い場合には、/etc/init.d/sendmail等に、sendmail -q (時間) で設定しています。 (デーモンモードでは無く、キュー配送専用に(時間)毎に実行する) 2.「mqueue」の再送は、古いものから順に再送されるのでしょうか。 違います。が、どのような順番で行なっているかは私もわかりません。 /usr/sbin/sendmail -q -v を実行すると、再配送時の詳細の確認が可能です。 3.6日間再送されなかった原因として想定されることはなんでしょうか。 2.を実行するとわかりますが、キュー数が多いと途中で再配送処理が停止してしまう事があります。 その場合、条件的に再配送処理が掛からないメールが出てしまうこともあるようです。 4.このようなことを防止する策としてはどのようなことがあるのでしょうか。 自サーバでの対策としては、spamを通さないようにする。 mqueueにメールが溜まり過ぎないようにする。 メールサーバのスペックを上げる などでしょうか。 私自身が管理するサーバでは全て15分おきに再配送するように設定しています。 また、相手サーバの理由であるとしても メールを届けられない場合には1日~3日程度でメールをリターンする方が良いでしょう。 sendmailのデフォルトは20年前のインターネットの仕様に基づいています:-)

回答No.1

sendmail.cfを直接編集した事はないのですが、Timeout.queuereturn= あたりの値が、6dになっているのではないでしょうか? ただ、再送の時間が問題ではなく、送信先サーバーが受け取りを明らかに拒否しているように思います。 状況がよく分かりませんが、mqueueに8000件ものメールが溜まるのは、サーバーの処理能力の問題よりもメールをリレーしたりする迷惑サーバーとしてブラックリストに載ってしまった結果、送信先にコネクションを断たれてしまうこともあります。 過去にサーバーに設定したSPAMメール対策が現在も有効に機能しているか、今一度確認してみるのも良いかもしれません。 まずは、4.の防止策としてSPAM対策と不正中継の踏み台にされていないか確認するところから始めることをお勧めします。

関連するQ&A