中継メールサーバーの高可用性・負荷分散に対応する - Postfix Advent Calendar 2014 - ダメ出し Blog
Postfix Advent Calendar 2014 の 17日目の記事です。 安定の 4日遅れです。毎度すみません。 今回は、メールの中継処理の高可用性・負荷分散を実現するため、 複数の中継メールサーバーを用意し、それに対応するための Postfix とその周辺の設定方法について解説します。 筆が乗らず、後半は説明が雑になっています。すみません。 おいおい改善します。 構成 要件 ユーザー名@example.jp をホストするメールサイトであると仮定します。 example.jp ドメインの DNS MX RR は中継用の SMTP サーバー (Postfix でも何でも構いません) relay1.example.jp と relay2.example.jp を指しており、 インターネットから来るメールはこれを経由して LAN 内の Postfix SMTP サーバーである mail
postfixで送信元毎の同時送信数を制限する方法 - 理想未来ってなんやねん
名探偵コナンじゃないですが、 『犯人はこの中にいる！』 みたいな事件が社内で起こってしまいました。 今回の犯人はT.M.君。 犯した罪はメールボムを使用したサーバー攻撃です。 どうもプログラムのデバッグでメールを送信するようにしていたようですが、そのプログラムを走らせたまま帰ってしまいました。 おかげでメールのキューが溜まってしまった結果、業務のメールが送信できなくなり他部署から思いっきり怒られてしまう始末。トホホです。 一度間違いを犯した人は間違いを犯さなくなると思いますが、他の人がやってしまう可能性もあるわけで、善良な社員をゲリラ的テロリストにさせない為にも、きちんと制限を行っておいた方が良いでしょう。 という訳でpostfixで送信元毎の同時送信数を制限する方法について調べて設定してみました。 postfixで使用できるパラメータ postfixのパフォーマンスチューニングに関するマ
Postfixの設定もろもろ - 偽じ日報
思い込み多々あり。 http://www.postfix-jp.info/trans-2.3/jhtml/postconf.5.html ＜再送まわり＞ minimal_backoff_time maximal_backoff_time maximal_queue_lifetime bounce_queue_lifetime queue_run_delay ここらへんの設定がいる模様。 たとえば、 minimal_backoff_time = 60s maximal_backoff_time = 600s maximal_queue_lifetime = 1800s bounce_queue_lifetime = 1800s queue_run_delay = 60s ※「s」は秒 した場合、 最初再送に失敗したら、defferedキューに入って、queue_run_delayごとにdef
バウンスした宛先に再送できるかどうか? | bounceHammerは2016年02月29日(月)をもって製品ライフサイクルの終了となりました
次に列挙する理由でバウンスした宛先はほぼ確実に再送信が不可能と言えるものです。 できるだけ早く配信対象から除外するほうがよいでしょう。 不明なホスト(hostunknown) 宛先メールアドレスの ドメインパート(@の右側)が間違っている、ドメインが存在しない、ドメインが消滅した などの理由で、多くはメールアドレスの綴り間違いです。 Webサイトなどで登録時のメールアドレスチェックが甘い場合、 無茶苦茶なアドレスで登録されるとこのエラーが頻発します。 宛先不明(userunknown) 宛先メールアドレスの ローカルパート(@の左側)が間違っている、メールボックスが存在しないなどの理由です。 日本の携帯電話宛では宛先不明で返ってきたアドレスにメールを送り続けると、キャリア側から受信ブロックをもらうこと があるので要注意です。 次に列挙する理由でバウンスした宛先に再送信しても到達する確率はか
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
