ストーリーは勝手に編集しています。関係者の方、気を悪くなされないようお願いいたします。

sendmail　と qmail　の配送再試行間隔についてのディスカッション

BBS雑記帳で、ドコモへのメールが遅延している事を日記として起票した。

かつさんがすかさずフォローを起こしてきた。

どうやらかつさんも気になっていたらしく、独自に調査と実験を開始していた。

遅延、そう、しばらく前にめちゃくちゃ遅延して大騒ぎになっていたのだがそれも徐々に落ちついて来ていた。

最近すっかり安定したと思っていた。

それがここへ来てまた変だ。ちょこっと数分、なんだか数時間、ほんとかよ数日と、支障を感じるくらい遅れて届く事が多くなってきた。

ドコモの配信が遅れるのは、どんなに議論しても所詮、我々にはどうにもならない。

どうにもならないのではあるが．．．調査をして現状を把握することに関して情熱がわき上がる、なんなんだろう。

かつさんは定期的にメール自動配信をし遅延状態を測っている。

そしていずれその結果が明らかになるだろう。この時点で第二次の調査計画が発表されているから。きっと．．．

と思っていたらUPされてました。こちらに

で、ここからはメールサーバーに関しての記載になります。

かつさんのメールサーバーはsenmail。

標準のリトライ間隔は次の通りだ（かつさん情報より）

・再送間隔1時間
・4時間経っても送れなかったら警告メール
・5日間経っても送れなかったら送信者にリターン

かつさんのチューニングによってsendmailは次のようにしてあるという。

・10分間隔で再送
・1時間たっても送付できないときは警告メール
・1日たっても送付できないときは送信者にリターン

かわいそうにsendmail、全体的に忙しくはたからされている。

きっとご主人が早く食べる癖になってしまったからでは無いか？と思う。（ここのNo99に書いてありました、ぜひ参照して投票を！）。

さて私は、というと、このサーバーの説明を見ていただいた通り、qmail ってやつを使っている。

リトライはどうなってんだ？　そういえば設定した覚えがないぞ、ちょっとあせった。

とりあえず、ＢＢＳからは姿を消して調査することにした。ここで答えるべく意地が、すこしはある。

調べても調べても・・・・そんなインターバルどこにも見当たらない。

その件で疑問に思っている人は・・・いない？　なんで？

みんな気にならないのか？

さて、このへんから qmail のお話しになってしまいます。といっても、私自身 qmailに特別詳しい訳ではありませんのでそこそこに割り引いてお読みください　ね。

qmailの配送エージェントは qmail-send ってプログラムだ。

そもそも qmail はその本体だけでなく　-send や -pop3d 、 -popup 、 -smtpd 、 -inject　、 -remote などという細かなソフトがそれぞれ分業して動作している。qmail-xxxxの前を省略して記載しました。

配送に関してはその qmail-sendだ。

そのパラメーターを調べてみる。ここ

リトライに関する項目でみつけられるのは一つだけ。転記させて頂く。

queuelifetime -- [604800 (7日)] -- キューに滞在できる秒数
指定時間経過後、qmail-sendは再度配送を試みる。ただし、今度は一時的エラーも配送不能と見なされる。

さてかつさんの記載に照らし合わせると

・xx分間隔で再送
・xx時間たっても送付できないときは警告メール
・７日たっても送付できないときは送信者にリターン

一項目だけは分かったぞ。

でもかつさんにならって一日にしてしまおう。

３日も４日もたって届かなかったよ、ってエラーメールが帰ってきても困るし。

【操作】

ファイル
/var/qmail/controls/queuelifetime
を作って
86400
を中に突っ込んでおいた。

qmailの再起動手順、ここは手順書のページではないけど書いておこう。

pa aux | grep qmail

で表示された qmail-send のプロセスIDを覚えておいて

kill -HUP プロセスID

これでＯＫ

・xx分間隔で再送
・xx時間たっても送付できないときは警告メール
・１日たっても送付できないときは送信者にリターン

こうなった。

以上で報告は終わりです、かつさん。

いいのかな？そこまででいいのか？

間隔はどうなのかな？

sendmailに負けた気がした。

間隔は、そうだ、サンプルがあった。

ここのところ仮称 j-p の携帯宛メールがしばしば蹴られている。先方のサーバが忙しいらしい。

そのリトライの情報がちょうど手元にあった。

エラー表示の時間は

22:45
22:52
23:12
23:45
00:32

それぞれインターバルとして差を算出すると　

７分
20分
33分
47分
と徐々にのびている。

こんなところでいいでしょうかねぇ〜

すっきりしない。

本格的に調査を開始しよう。調べるところは一つ、見たくないけど・・・・・・・・・そうだよ、ソースだよっ

qmail-send.c

みます。

ソース冒頭にインターバルタイムについて幾つか宣言されている。

SLEEP_TODO 1500 /* check todo/ every 25 minutes in any case */
SLEEP_FUZZ 1 /* slop a bit on sleeps to avoid zeno effect */
SLEEP_FOREVER 86400 /* absolute maximum time spent in select() */
SLEEP_CLEANUP 76431 /* time between cleanups */
SLEEP_SYSFAIL 123
OSSIFIED 129600 /* 36 hours; _must_ exceed q-q's DEATH (24 hours) */
int lifetime = 604800;

最後の lifetimeだけはあとからパラメータで指定できるやつですね。
最初の25分のチェックタイム、これがキーかな？
maximum timeは24時間(86400)、cleanups間隔21時間？
なんだか良くわからない？
SYSFAILの123秒はシステムでFAILになった時に待たすらしい。
どうなんだろう、これで可変しているのとどう関係するのか？

とりあえずこの数値を掲示板でかつさんに報告してみた。

でもくやしいなぁ。

よくわからない。

ソースをもう一度見直す。

インターバルを

static datetime_sec squareroot(x) /* result^2 <= x < (result + 1)^2 */
datetime_sec x; /* assuming: >= 0 */
{
datetime_sec y;
datetime_sec yy;
datetime_sec y21;
int j;

y = 0; yy = 0;
for (j = 15;j >= 0;--j)
{
y21 = (y << (j + 1)) + (1 << (j + j));
if (y21 <= x - yy) { y += (1 << j); yy += y21; }
}
return y;
}

この関数で計算しているのがわかる。
名前からしてルートを計算しているのか？
ちょっと疑わしい。

しかたない、これを検証してみるとしよう。
といってもlinuxでCコンパイラどどうやって動かすのか知らない私は、Windowsで試しました。
どうやら、引数に与えた数値のルートが戻ってくる様だ。名前は伊達じゃないって、当たり前だよね。

さてそうすると、このルートのインターバルを使った関数をあちこち拾い集め、統合すると次の式にまとめられる。

Interval=B+(20+sqrt(A-B))^2

Aはrecentという変数で、qmail-sendが起動した時刻が与えられるが実際にどうなっているのかは不明。
Bはbirthという変数で、どう処理されていて数値が与えられているのかわかりませんでした。とある関数で構造体として定義されていて、構造体を書き換えているのは別の関数で、その値は別のどこかのファイルから読み出したもので、その元になるファイルの名前は別の構造体が持っていてその構造体の構成を作っている場所が見つかりません。だからBの実態がわかりません。

でも式がわかったから、先のJ-P宛のリトライと比較して、一致する変数を探してみればいいですね。

簡単です。こういう時にはExcelって最高です。

Aをゼロ（なんでゼロだかはわかりません）　Ｂを　for(B=0;;B+=800)　とする

ぴったり一致です。そうです。qmailはこうやって初期のリトライインターバルを算出していたんですねー多分。

ソースコード最初の定義ってどこで聴いているのかわかりません。

とりあえずここまでわかったので、ちょっと満足しました。

・上記の可変インターバルで再送
・xx時間たっても送付できないときは警告メール・・・・・これ不明
・１日たっても送付できないときは送信者にリターン

不明なところがありますが、報告を終了させていただきます。