[plamo:24184] Re: MTA の反応

[smt 管理s 齋藤哲]

齋藤です。

sendmailについて話があったので投稿します。

加藤さんの文を一部引用します。
>   http://www.sendmail.org/faq/section4.html#4.5
> の "Note" の部分にそのような感じの記述がありますね．"don't do that" と
> ありますが... (^_^;)
>
>   http://james.terra-intl.com/james_and_sendmail.html
> の Step 3 にも何かそれらしいのがありますが，全く分かってないので外して
> いるかも知れません．(_o_)

早間さんのやりたいこともなんとなくわかります。
既存のレイアウトを崩さずに冗長性を持たせる方法として考案されたと思われます。
しかし、加藤さんの記した情報の通り、オープンソース版のsendmailは負荷分散の技術を保持していません。たとえ外部に分散装置をつけてもです。同じ設定情報を
持つホスト同士のメールを確認しあって配送する仕組みが無いためです。

ループチェックのロジックをスキップすることは可能なのですが、
・実際ローカルループが発生するとメールホップをカウントしないので
　永遠にリソースを消費し続ける。設定によってはログが残らない。
・ホスト情報を偽証しいてるので回避方法はあるけど正式なESMTPが
　会話できなくなる。
などの弊害もあります。
これを回避するにはクラスタ構成の有償版sendmail(ノードマネージャ含有)としてのライセンスが必要と思われますし、ノードマネージャホストも必要であることから、現実味がありません。

素直にMX 10,20 のプライマリ・セカンダリ構成が技術的に枯れてますし、安全です。上記冗長構成もとれますが、障害時の対応が未確定であり、保守性にかけているように思われます。

どうしても負荷分散が目的でしたら、新たに中継ホストを並走させて、そこから外部ホストと内部ホスト(locala,localb,localc)に中継配送させるほうがシンプルです。

ダウン時のホットスタンバイでしたら、ディスク共有型のクラスタ構成のホストに
同じ設定情報のsendmailを稼動させるフローティングIP管理が適切なのでは。
少々高いですが…。

最後に。
これが最良とはいえないですが、
localbのメールルーティングで、
locala宛ては一度localcへ配送とします。
localcのメールルーティングで、
locala宛てはlocalaへ配送とします。
配送量はかさむのですが、現実問題として妥当なのはこの線でしょうか。
もしくは新規ホストlocaldを立てて、そこを介してlocalaへ配送することもできるでしょう。
どうなんでしょ。

齋藤 哲   tetsu@smt.city.sendai.jp