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


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/