デジタルドリームワークスから比嘉です。
さてサーバーを持っていると必ずと言っていいほど打ち当たるのが負荷問題です。
一時的なものであればまだ良いのですが、頻繁に負荷がかかり処理が出来なくなる状況であれば対策をねらなければなりません。
そもそもスペック的な問題なのか、一部のシステムが高負荷になり全体に影響を与えているのか。
ログを確認しても難しい部分もあります。

今回はメールサーバ（Postfix）を見ていきます。
弊社の環境ではメールサーバーが負荷を与えている状況ではありませんでしたが、改善出来るポイントを確認してみました。

※以下のチェック項目はあくまでPostfixの他の部分（スパムメールの踏み台にされない）など 適切な設定を行っている場合の追加チェックポイントみたいなものです。

———-

/etc/postfix/main.cfを確認していきます。

1. unknown_local_recipient_reject_code 項目の確認

「unknown_local_recipient_reject_code」の項目は名前通り、宛先ユーザーが存在しない場合のresponse codeの設定です。
バージョンが古いpostfixでば、「450」となっている場合があるようです。

コード「450」の場合は一時的にメール配送ができない状態を表し、時間をおいて再送される仕組みになっています。
宛先ユーザーが存在しない場合でも設定されている期間内で繰り返しメールを配送しようと処理するので「450」の場合は「550」修正します。
※ コード「550」は宛先ユーザーが存在しないということで即座に拒否（送り返す）します。

unknown_local_recipient_reject_code = 550

色々と記事を見ていると配送設定の期間もデフォルトではいけませんよ 的な記事もありました。

【 参考 】
http://perl.no-tubo.net/2012/03/04/postfixの再送設定/

minimal_backoff_time =
maximal_backoff_time =
maximal_queue_lifetime =
bounce_queue_lifetime =
queue_run_delay =

2. エラーメールの返信ポリシーを検討する

宛先ユーザーが存在しない場合はエラーメールとして送り主にエラーメールが返信されます。
しかしスパムメールは送り主を偽装して実在しないメールからメールを送信されたかのようになっている場合があり、エラーメールが送信出来ずにサーバー内に溜まっていく場合があります。
調べた結果、管理者によりエラーメールの設定ポリシーは異なるようです。

1. 従来通りエラーメールを送り主に送信（サーバー内に溜まるエラーメールを定期的に削除？）
2. エラーメールを送信せずそのままサーバー内で削除

1の場合は送信者がエラーでメールが届いていないことが分かるメリットがありますが、サーバーに溜まるエラーメールを削除する必要がありそうです。
2の場合は溜まったメールを処理する手間は省けますが、メールが届いてない場合も確認出来ないなどの問題が出てきそうです。

どちらもメリット、デメリットがあります。
そして一般的な設定はどうなっているのでしょうか。気になるところですがその部分を確認することは出来ませんでした…
ご存知の方がいらっしゃいましたらコメントいただけると幸いです m(_ _)m
弊社のサーバー環境も確認＆検討してみようと思います。