&fml8; 最大の目的の一つは、 メンバーリストの取得操作におけるコードの統合と抽象化です。 配送システムも抽象化された IO 層を利用して配送先の情報を取得しています。 配送には抽象化された Mail::Delivery クラスを次のように使っています。 Mail::Delivery::* に属するクラスは SMTP および LMTP 配送へのインターフェイスを提供します。 つまり Mail::Delivery は Mail::Delivery 以下の派生クラス SMTP、ESMTP へのインターフェイスを提供するアダプター層です。 たとえば次のように使います。 use Mail::Delivery::SMTP; my $service = new Mail::Delivery::SMTP; if ($service->error) { Log($service->error); return;} $service->deliver( { mta => '127.0.0.1:25', smtp_sender => 'rudo@nuinui.net', recipient_maps => $recipient_maps, recipient_limit => 1000, mesage => $message }); ここで $message は Mail::Message オブジェクトです。 このオブジェクトはメールを解析し、 header -> body header -> preamble -> part1 -> part2 -> trailor (multipart) のようにオブジェクトが「数珠つなぎ」になったデータ構造を作ります。 Mail::Message クラスはこのようなデータ構造を操作するメソッドを提供しています。 §.mailqueue; 2004 夏以降、 &fml8; の配送システムはキュー管理システムのもとで動いています。 これにより &fml8; 自力での再送処理が可能となりました。 別の言い方をすれば、 実質的に &fml8; をメールサーバと言ってよくなったわけです。 FML::Process::QueueManager が使っているのみなので 独立したモジュールである必要があるだろうか？という疑問です。 現状 reply_message() メソッドが何でもしてしまうので、 FML::Mailer を呼ぶことはないかもしれません。 もっとも reply_message() 以外の送信メソッドがあり得るかもしれません。 将来、どうも使ってないようなら FML::Process::QueueManager に合併するべきなのでしょう。 ねんのため、HOOK などでは FML::Mailer は使わないようにして下さい。 &recipes.delivery;