[PREVIOUS CHAPTER] [NEXT CHAPTER]

3 Internal

    3.1	SMTPライブラリについて

    SMTP ライブラリは SMTP(プロセス間通信)で sendmail 等のMTA(Mail
    Transport Agent)と通信するライブラリです。

    $PORT = 25 (25/tcp) で通信しますが、

    	$PORT

    を変えることで別のポートで通信することもできます。また通常

    	$SMTP_LOG (default "var/log/_smtplog")

    というファイルに通信のログを残します。このログはデバッグに非常に役立ち
    ます。

    	$NOT_TRACE_SMTP

    をセットすると、このログは残りません。

    また、どのマシンの sendmail を使うかも自由に設定できます。デフォールト
    はそのマシンです。もしMLサーバのマシン(受けるマシン)が貧弱ならそのマシ
    ンが何十通もメールを送り出すのは酷です。

    	$HOST         = 'localhost'; (default)

    そういう場合変数 $HOST を書き換えて別のマシンに配送を任すこともできま
    す。その時は

    	$HOST         = 'beth.foo.bar.ac.jp'; (another host)

    のようにそのマシン名を書いて下さい。もちろんアクセスできないマシンとか
    ではできません(あったりする)し勝手にそのマシンのパワーを使うことになる
    のでそのマシンを使う許可を得るべきです。

    HOSTではポート番号が25でないMTAへのアクセスも可能です。例えば port
    10025/tcp を使うこともできます。

    	$HOST         = 'beth.foo.bar.ac.jp:10025';

    3.2	予備のSMTPサーバ

    もし SMTP サーバに何かあった時のために @HOSTS に複数台の予備の
    sendmail の走っているマシンを定義することが出来ます。

       @HOSTS = (machine-1.domain, machine-2.domain, machine-3.domain, ...);

    この場合、もし $HOST に connect() できない時は、machine-1 に、
    もし machine-1 に connect() できない時は machine-2 へ…とい
    う風に予備のサーバを使い何とか配送をしようと試みます。
    全部だめだった場合は sendmail コマンドを使って配送を試みます。
    sendmail がないシステムでは qmail-smtpd, exim なdも試します。

    3.3	SMTP の MAIL FROM: を $MAINTAINER 以外にしたい時

    $SMTP_SENDER に指定して下さい。

    例: プロバイダ(例えば fml.org とすると)が不正中継対策のため、MAIL
    FROM: のドメイン名を自由にできない場合などに使います。

    	$MAINTAINER  = 'elena-admin@nuinui.net';
    	$SMTP_SENDER = 'elena-admin@fml.org';

    3.4	同じmxについて

    sendmail 8.xではCHANGES-R5-R8にあるとおり↓

       For example, if two sites ``foo.com'' and ``bar.com'' are both
       served by UUNET, they will have the same set of MX hosts and will
       be sent in one transaction.  UUNET will then split the message

    一通で送られます。ばらばらの順番でも大丈夫。

    sendmail 5.xでは@.*の部分が厳密に同じで、さらにちゃんと並んで書いてあ
    れば

    	fukachan@phys.titech.ac.jp
    	Elena@phys.titech.ac.jp
    	cocoa@phys.titech.ac.jp

    一通にまとめられます。

    qmail 1.0 はそうことをせず相手の負荷も回線の太さも考えず、ひたすら一通
    ずつ投げつけます(だ〜っ)。

    3.5	MCI Cache

    TCP Connection Cache の基本的なアイデアは TCP Connection 自体のコスト
    の高さです。

    もともとの sendmail は

    	for (…おくるべきホストのリスト…) {
    		ソケット、コネクト、通信、おしまひ
    	}

    を一つ一つおこないます。これだと 通信が遅いだろうが、なんだろうが、
    TIMEOUT か error が起こるまで長い間無駄な配送がありえます。

    sendmail 8.7 では標準装備ですが、いまは
    #旧もとのりさんのWIDEぱっち ってやつです

    	for (…おくるべきホストのリスト…) {
    		ソケット1
    		ソケット2
    		…

    		じゅんぐりにまわしていって、
    		通信がしやすい connection へ優先的に
    		通信、(…おしまひ)

    		………
    	}
    	#ちょっと、簡単化し過ぎかな↑

    のように、さっさと送ることが可能なホストへどんどん送って、駄目なところ
    は駄目なままです。どうしてもだめなら、最後は queue up されて、次回30分
    後とかに retry です。

    そういう意味で、MCI CACHE は多いと だめなホストが2、3個ならかなり理想
    的な速度で配送できるでしょう。もし、MCI_CACHE が2個で、2個だめなホスト
    があると、そこでしばらくつかえてしまうので、遅くなってしまい R5 のよ
    うになってしまうと。

    そういう意味で MCI CACHE は多ければ多いほどよさそうに見えますが、やり
    すぎると 今度はカーネルと折り合いがつかなくなるので、まぁ数個が妥当な
    数字なのでしょうね。

    ○ 1つのメールは常に1か所づつ配送されるのでしょうか?

    これは (multi thread kernel でないのなら) kernel がある時点ではかならず
    CurrentProcess を実行しているのだから、YES です。ただ 通信はしていなく
    ても Connection 自体は OkN の N 個(MAX) ACTIVE なままです(netstat で
    みえるもの)。

    これにさらに MX Cache 等が組合わさって、R8はR5にくらべ非常に高速化さ
    れましたね。

    3.6	配送効率についての考察

    配送効率についての考察

    3.7	配送プロセスの律速段階とは

    律速段階はやっぱり sendmailの配送プロセスそのものでしょう。この部分の
    overhead は R5 にくらべ R8 では非常に改善されましたがそれでもかなりの
    overhead があります。single thread であることが最大の要因の一つです。
    並列度をあげるためには、SMTP connection や DNS query を並列化しないと
    いけません。高速配送には例えば smtpfeed を利用して下さい:)
    qmail vs smtpfeed: 本当に複数のプロセスを立ち上げるという暴挙をやると
    qmail になります;_;理論の上ではマシンの負荷は圧倒的に違うはずですが、
    配送するアドレス分布のスペクトルが白色雑音状態なら配送時間はあまり違わ
    ないように振舞うでしょうね。

    逆にいえば fml 自体を tuning して速度を例えば 0.1 sec 上げても ML の配
    送プロセスには何のメリットも生じないということでもあります。基本的には
    MTAのチューンや機能の並列化を先に考えるべきです。

    １	十分なパワーのマシンで十分な file descriptor や
    	多くの process が走っても大丈夫であれば、
    	複数の sendmail を起動して配送を試みる。
    	この場合ちゃんと Load Average と sendmail.cf を tune する
    	必要があります。人それを qmail と呼ぶという話もあります(苦笑)

    ２	非力でも複数のマシンが用意できるなら複数のマシンでパラレルに実行

    ３	リレーサーバを用意する。例えば東京方面、関西方面のように分けて
    	一回そのリレーサーバに投げて、そこから再配送をする。

    ケース1、2は fml の $MCI_* 変数群がそれを可能にします。

    ケース3のリレーサーバは各ユーザごとに”管理者”が設定できます。ここで
    考えるべきこととしてリレーサーバは相手のマシンに負荷をかけることに注意
    しなくてはなりません。またネットワークトポロジーを考慮の上決めるべきで
    す。そして現在ではSPAM不正中継のため普通リレーはできないので特定のホス
    トからのリレーだけはあけてもらうなどの設定変更も必要なことにも注意して
    下さい。

    なお $DEFAULT_RELAY_SERVER が定義されている場合は強制的に全てのメールを

    	$DEFAULT_RELAY_SERVER

    で定義されたリレーサーバへ投げそのサーバに配送してもらうということもで
    きます。
    4.2

    qmail というひたすら配送プロセスを fork() しまくって、何も考えずにばん
    ばん投げるMTAがあります。そういう配送の仕方でバックボーンならいいと思
    いますが、細い線のサイトにばんばん投げ付けられてしまうようになったら最
    低ですよね？世の中どこも線が太いなんていう仮定は誤りですから。
    http://www.qmail.org/

[PREVIOUS CHAPTER] [NEXT CHAPTER]