web-dev-qa-db-ja.com

Sendmailリレー/接続拒否エラーの構成についてサポートが必要

VMWare VMでSendmailを使用してUbuntu 10.04を実行しています。私のmail.logファイルに何千もの接続拒否エラーがあり、それらを取り除きたいのですが。毎秒複数のエラーがあり、この問題が正当な電子メールの一部を送信していないことを確信しています。

例：

Jul 13 08:20:02 mail sm-msp-queue[28076]: s6C3K6e0008595: to=root, ctladdr=smmsp (115/126), delay=1+08:59:56, xdelay=00:00:00, mailer=relay, pri=8940371, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Connection refused by [127.0.0.1]
Jul 13 08:20:02 mail sm-msp-queue[28076]: s6C3K19D008593: to=smmsp, delay=1+08:59:58, xdelay=00:00:00, mailer=relay, pri=8941647, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Connection refused by [127.0.0.1]
Jul 13 08:20:02 mail sm-msp-queue[28076]: s6D2K2lX023270: to=postmaster, delay=09:59:56, xdelay=00:00:00, mailer=relay, pri=9331939, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Connection refused by [127.0.0.1]
Jul 13 08:20:02 mail sm-msp-queue[28076]: s6C7e3Cp010618: to=postmaster, delay=1+04:39:47, xdelay=00:00:00, mailer=relay, pri=9754324, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Connection refused by [127.0.0.1]
Jul 13 08:20:02 mail sm-msp-queue[28076]: s6BNe474006871: to=root, ctladdr=smmsp (115/126), delay=1+12:39:58, xdelay=00:00:00, mailer=relay, pri=9930371, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Connection refused by [127.0.0.1]
Jul 13 08:20:02 mail sm-msp-queue[28076]: s6CMK1lb021417: to=root, delay=13:59:57, xdelay=00:00:00, mailer=relay, pri=10410356, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Connection refused by [127.0.0.1]
Jul 13 08:20:02 mail sm-msp-queue[28076]: s6BLK2Bk005641: to=postmaster, delay=1+14:59:56, xdelay=00:00:00, mailer=relay, pri=10571717, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Connection refused by [127.0.0.1]
Jul 13 08:20:02 mail sm-msp-queue[28076]: s6BK01i9004244: to=postmaster, delay=1+16:20:00, xdelay=00:00:00, mailer=relay, pri=10926911, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Connection refused by [127.0.0.1]`

Sendmailがポート25でリッスンしていないという潜在的な問題を読んだので、このコマンドを実行しました

# Sudo netstat -a -n -p |grep 0.0.0.0:25
tcp        0      0 0.0.0.0:25                  0.0.0.0:*               LISTEN      1137/sendmail: MTA:`

私も行を変更しようとしました：

DAEMON_OPTIONS('Name=MTA, Addr=127.0.0.1, Port=smtp')dnl`
DAEMON_OPTIONS('Name=MSP, Addr=127.0.0.1, Port=submission')dnl`

私のsendmail.mcで、sendmail構成を再構築しましたが、それを行ったときに電子メールをまったく送信できませんでした。

私はそれが正しいことを100％確信していないので、私のhostsファイルのコピーも添付しています。

127.0.0.1 example.org localhost localhost.localdomain mail.example.org.localdomain`
10.1.1.204 example.org mail.example.org mail.example.ci.oh.us mail-server`

メールサーバー 'mail.example.org'は、ウェブサーバー 'example.org'からのすべての中継メールを処理します。この部分は常に混乱しますが、これらのサーバーの管理を引き継いだときにこのように設定されました。

何か助けてくれてありがとう、他に何か投稿する必要があるかどうか教えてください。これらのエラーを修正するために必要なことは何でもします。

sendmailubuntu-10.04
3
user671460

Sendmailログでrejecting connections ...を検索しましたか？
システム負荷平均が高すぎる場合、Sendmailは着信接続の受け入れを拒否することがあります。

「クライアントキュー」（mailq -Ac）内のメッセージ数を確認します-場合によっては、このような問題は、クライアントキュー内の膨大な数のスパムメッセージ（たとえば、ホスト/ハッキングされた「スパムに優しい」Webページが原因です。
巨大なclientmqueueを人間の形式で読み取る方法

Sendmail.mcファイルの次の行を使用して、「負荷平均の拒否」をデフォルトの12から増やすことができます。

define(`confREFUSE_LA',`20')

"Sendmail Performance Tuning" by Nick Christenson （139ページ）は、専用の非Linuxサーバーで12〜20に設定し、専用のLinuxサーバーでさらに高く設定することについて説明しています。 [Linuxは別の方法で負荷平均を計算します]

Sendmail-8.14.0では、DaemonPortOptionsパラメーターとして設定するオプションが導入されました。これを使用して、ループバック（127.0.0.1）、内部IPアドレス、およびパブリックIPアドレスに異なるrefuseLAを設定できます。

3
AnFi

メッセージが延期されているようです。そのため、キューに何度か再試行されているメッセージがある可能性があります。キュー（mailq）を調べて、その可能性があるかどうかを確認してください。

キュー内の個々のメッセージを確認できます。キューディレクトリに移動すると、電子メールごとに2つのファイルがあり、1つはdf *で始まり、もう1つはqf *です。それらを組み合わせて、メッセージ全体を構成します（1つはキューの詳細に関する情報を含み、もう1つは電子メールのコンテンツを含みます...はい、意図的に簡略化された説明:-)）。詳細を確認し、キューからメッセージを削除する場合は、同じキューIDの両方のファイルを削除できます。または、すべてのファイルを別のディレクトリに移動して、キューから削除することもできます。そこで、余暇を調べ、実際にやり直したいものを戻します（キューIDの問題に遭遇したことはありません）そうですが、当然、これを行うことで、通常のsendmailプロセスの真ん中に足を踏み入れています。

それらが正当で再試行する必要がある場合は、sendmail構成の再試行設定を微調整して、試行頻度が少なくなるようにする必要があります（NDRをあきらめて生成する前に再試行される頻度と合計時間の両方）。これらの設定を確認するという演習は、あなたに任せます（config自体で見つけるのも、基本的なWeb検索で見つけるのも簡単です）。

もちろん、メッセージが何かを判別することは、何かがキューをいっぱいにしているかどうか、または単に不正な電子メールの送信を再試行しているなどを確認できるようにするための最初のステップです。

ウェブサーバーがメールサーバーを介して中継するのはそれほど珍しいことではありません。通常、メールの出力ポイントを1つだけにすると、SPFレコードなどの管理が容易になります。通常、ウェブサーバーが危険にさらされていないことを確認し、スパマーに変えます（メールサーバーが送信するものをリレーするため）。もちろん保証されています。

最後に、正当な電子メールに影響を与える再試行/接続を通常想定する唯一の方法は、正当な電子メールが再試行を待機できるように十分な大きさのキューを処理している場合です。新しい電子メールはキューで最初に試行されるため、これは通常は当てはまりません。ただし、通常の正当な理由で延期された場合は、通常のキューの再試行を行う必要があります。

追加：ログエントリを見ると、キューIDが提供されます。たとえば、「s6C3K6e0008595」のエントリがまだキューにある場合は、qfs6C3K6e0008595とdfs6C3K6e0008595のファイルを確認できます。

0
SendMail