企業環境では、ポート 25/tcp と 587/tcp のみが使用可能なメール サーバーが存在します。
Perl スクリプト (HTML::Mail を使用) を使用して数百の正当なメールを送信すると、「メール サーバーに接続できませんでした」というエラーが表示されて失敗することがあります。
sendmail サーバーの負荷が大きいために接続が拒否されたり、最初の要求に応答しなかったりするのではないかと思われます。
現在、メール サーバーを所有するチームは協力的ではなく、サーバーが接続を拒否したことの証拠を要求しています。
質問: 問題がサーバー側にあると仮定して、障害が発生した場合にクライアント側から収集できる情報は何ですか? 実際に問題がサーバー側にある場合、それをどのように証明しますか?
[[この質問がここで有効かどうかわかりません。問題自体が明確でない場合、問題解決の支援を求めることはできません。この問題のデバッグに役立つヒントとコツの短いリストを求めています。回避策に関する意見も歓迎します。]]
答え1
解決策としては、sendmail チームが「/etc/mail/sendmail.mc」ファイルを確認することです。
dnl #
dnl # The following limits the number of processes sendmail can fork to accept
dnl # incoming messages or process its message queues to 20.) sendmail refuses
dnl # to accept connections once it has reached its quota of child processes.
dnl #
dnl define(`confMAX_DAEMON_CHILDREN', `20')dnl
dnl #
dnl # Limits the number of new connections per second. This caps the overhead
dnl # incurred due to forking new sendmail processes. May be useful against
dnl # DoS attacks or barrages of spam. (As mentioned below, a per-IP address
dnl # limit would be useful but is not available as an option at this writing.)
dnl #
dnl define(`confCONNECTION_RATE_THROTTLE', `3')dnl
(Treat "dnl" as a comment leadin string.)
電子メールを大量に送信している場合は、おそらく送信量を調整する必要があります。
答え2
エラー メッセージと問題が発生した正確な時間をログに記録します。これにより、sendmail 管理者はログ ファイル内の問題を正確に特定できるようになります。
大量メール送信では、次の点に注意する必要があります。a
) SMTP 接続を再利用して多数のメールを送信する (例: 50)
b) 1 秒あたりに送信されるメッセージの数を制限する (例: 20 ~ 50)
私が提案できる他の対策は sendmail に固有のものであり、sendmail 管理者の協力が必要になります。