.qmail ファイルに挟むプログラムを作成するには

とりあえず .qmail ファイルとして次のようなものを用意して、いろいろと実験してみようと思います。

このような感じで、とりあえず /home/test/smtp.bin/test.sh を実行した後で、Maildir へメールを格納するという感じです。

そしてまずは単純に、期待通りの動作を行ってくれるかどうか、次のようなスクリプトを使って実験してみます。

この状態でメールを送信してみると、なんら問題なくメールを受信することができました。

　

これを行うに先立って、まずは .qmail ファイルを次のように調整してみます。

この状態でメールを送信してみると、"further-delivery@dummy.ez-net.jp" 宛ておよび自分自身の Maildir へメールが配信されます。ここで続いて、スクリプトを次のように修正して、スクリプト以降の行を処理の対象としないようにしてみます。

すると、最初の行に記載されているアドレスへメールが転送されてきましたけど、コマンドを実行した行より下にある Maildir への配信は、リザルトコードの 99 が意味するように処理されずに終わりました。

　

次のように最初の行と最後の行を入れ替えてみても、今度は Maildir にだけ配信されるというように、予期したとおりの処理結果となりました。

　

.qmail ファイルは上記のままに、今度はスクリプトにハードエラーを通知させてみます。

このようにしてメールを送信してみると、qmail からエラーを示す "failure notice" メッセージが送信元へ返送されてきました。それと併せてポイントとなるのが、ハードエラーを通知する前に記載した "./Maildir/" 行は有効なため、ローカルにはしっかりと配信されているというところでした。

なお、qmail から返却されてきたエラーメールは次のような内容となっていました。

続いてもうひとつのチェックポイントです。

qmail の付属文書によると、転送処理は最後に行われるとのことなので、もしエラーの前に実行していたとしても最後までの間にエラーになると、一切の転送が行われないとのことでした。

それを試してみるために、ふたたび .qmail ファイルの最初の行と最後の行とを取り替えて、送信実験を行ってみました。

このようにしてみると、不達メールが送信元へ返却されるだけでした。

付属文書の示すとおり、転送メールの行を通過はしているものの全体的には失敗となるので、エラーよりも次の行のローカル配信も然ることながら、最後の締めの転送処理も中士となりました。

　

qmail から返送されてきたエラーメッセージを眺めていてふと思ったんですけど、エラーメッセージを自分で指定することはできないのかなと思って、単純に標準出力へメッセージを出力したらどうなるのかやってみました。

スクリプトをこのように書き換えてメールを送信してみると、なんとしっかり、標準出力に含めたメッセージがメールに含まれるようになりました。これは便利かもしれないですね。

そのときの通知メッセージは次のような感じです。

ちなみにこれは不達メールとして送信元へ返却されたエラー通知メールだけが対象で、正常に送信できた場合はどこにも含まれないようです。

　

とりあえず、どんな環境変数が登録されているのかを目で確認してみることにしました。

確認方法はいたって簡単で、わざと exit 100 でエラーを出すとともに、環境変数を確認するためのコマンド env を実行するだけな感じです。

こうやってエラー通知を受け取ってみると、次のような環境変数が登録されていました。

HOST2	xxx.ez-net
HOST3	xxx
SENDER	sender@dummy.ez-net.jp
RECIPIENT	test@dummy.ez-net.jp
HOST	dummy.ez-net.jp
/HOST4	xxx
USER	test
EXT
LOCAL	test
PATH	/var/qmail/bin:/usr/local/bin:/usr/bin:/bin
_	/usr/bin/env
RPLINE	Return-Path: <sender@dummy.ez-net.jp>
/NEWSENDER	sender@dummy.ez-net.jp
PWD	/home/test
HOME	/home/test
SHLVL	2
EXT3
EXT2
EXT4
UFLINE	From sender@dummy.ez-net.jp Mon Oct 31 09:36:39 2005

ここで現れた環境変数はこれですべてでしたので、その他の細かなシェル変数については含まれないようですね。それ以上の情報が必要だった場合には、命令指定の際に引数で渡す必要がありそうです。

　

各環境変数の詳細については、いろいろ試してみた結果を最初の方の表へ含めてみましたので参考にしてみてください。

なお、.qmail によるコマンドの実行に関する付属文書に記されていなかった環境変数名がいくつかありますけど、それぞれは次のような役割となっています。

PATH	実行ファイルを検索するパスです。見る限りは svscan で実行したときに run スクリプトで指定したものが示されていましたので、そのような都合で登録されてきているものなのかも知れないです。
_	この変数は何なのでしょうね。とりあえず、環境変数を登録するプログラム env の存在位置が記録されている感じです。
PWD	現在のディレクトリ位置です。
SHLVL	シェルの深さを示す値だそうです。最初のシェルには 1 が設定され、そこからさらにシェルを呼び出すと、それが 2 になり、3 になり、そんな感じのもののようです。

　

ところで、環境変数を env で表示してみると、HOST4 と NEWSENDER の変数名の頭に "/" という文字がついてしまっていたりしたのですけど、いったい何なのでしょうね。

とりあえず、スラッシュを無視した変数名でちゃんと値を読み取ることができるようでした。

　

呼び出されたスクリプトが、どのアカウントで実行されているかを調べてみます。

やり方は簡単で、スクリプト上で whoami コマンドを実行することで標準出力へ実効ユーザ名を出力させます。そして終了コード 100 によって不達メールを受け取れば、目で確認することが出来るはずです。

このようにして不達メールを確認してみると、そのメールアカウントを管理しているユーザ名がメッセージ内に含まれていました。実効ユーザはそのメールを取り扱うアカウントになるみたいですね。

　

結果の方は先に上の表に書きましたけど、qmail の拡張部分にではなく、アカウントそのものにハイフンが含まれている場合には、そのハイフンを含む後ろの文字列も、しっかりとアカウント名として取り扱われるようでした。

この場合、環境変数の EXT の値にはアカウントに含まれるハイフン以下は含まれませんので、そういう面での状況想定でごちゃ混ぜになってしまうことはなさそうです。

　

ところで設定されている環境変数をスクリプトで変更するとどうなるのでしょう。

何か調整できたりするのかとも思って、少し実験してみました。SENDER や NEWSENDER, RECIPIENT, RPLINE, UFLINE など、もしかすると変更したら何か変わりそうに思えたものを中心にスクリプト内で値を設定しなおしてみましたけど、それで何かが変わることはありませんでした。

　

標準入力には Delivery-To: や Return-Path: が含まれないとのことでしたので、実際にはどのような感じで始まるのかを調べてみました。

このようにして標準入力から一行読み込んで、環境変数 MESSAGE へ値を保存してそれを表示してみると、最初の行は次のようになっていました。

これは、戻ってきたメールに引用されていたオリジナルメッセージの中の最初の Return-Path: 行を除いた次の行でしたので、 ほんの少しだけ情報が落ちる程度のようですね。

落ちた値についても環境変数の RPLINE で確認できるので、実質的にもなんら問題なさそうでした。

/var/qmail/bin/bouncesaying に、メッセージ ('MESSAGE') と条件判定を行うプログラム (PROGRAM) を引数として渡すと、その条件を満たした場合には 'MESSAGE' を添えてハードエラーとなるようです。

条件は 0 を返したときを真とみなし、そのときに 'MESSAGE' を標準出力に出しつつ、終了コード 0 でハードエラーとして終了します。条件が 111 を返した場合は、終了コード 111 でソフトエラーとして終了するそうです。

/var/qmail/bin/condredirect に、メールアドレス (ADDRESS) と条件判定を行うプログラム (PROGRAM) を引数として渡すと、その条件に見合った場合には ADDRESS 宛にメールを転送し、それ以降の行は無視して処理を終了するようです。

条件が 0 を返した場合、ADDRESS に指定されたメールアドレスへメールを転送するとともに、終了コード 99 としてその時点で正常終了とします。条件がそれ以外の値を返したり、そもそも条件判定プログラムが存在しなかったりしたときには、終了コード 0 で継続処理されるようです。

　

/var/qmail/bin/except にプログラムを渡すと、その終了コードの意味合いを反転させてくれるような感じで動作するそうです。

プログラムが正常継続を示す 0 を渡した場合にはハードエラーを示す 100 を返しますが、プログラムがソフトエラーを示す 111 を渡した場合には、except も 111 を返すとのことでした。また、それ以外の値が渡された場合には、except は正常継続を示す 0 を返してくれるそうです。

ソフトエラーの状態を維持したまま、正常だったらハードエラーに、それ以外ならば正常継続に、状態を変更するもののようですね。これを bouncesaying や condredirect と併せて条件判定で使用することで、判定条件を反転させることができるようになります。

使い方としてはこのような感じです。