研究ノート

ECA (Event-Condition-Action) 規則によるフォローアップのための方法として，サーバ・ベース，受信クライアント・ベース，送信クライアント・ベースの 3 とおりがある． これらのうちサーバ・ベース (メイル・ワークフロー・サーバ・ベース) がもっともつよく，送信クライアント・ベースがもっともよわいとかんがえられるが，後者には送信クライアントだけがワークフロー対応していればフォローアップできるという利点がある．

メイル・ワークフローにおいてはつぎのようなシステム・レベルのスケジュール管理機能がもとめられる．

Thunderbird などにおけるテンプレートは個人ごとに管理しなければならない． しかし，コラボレーションのためにテンプレートを使用するばあいは，テンプレートを共有する必要がある． そのためのかんたんな方法はテンプレートに URL をあたえて，HTTP などによってアクセスする方法である．

メイル・テンプレートは Thunderbird のそれのように，メイルを書くまえにアクセスして，メイルの記述をガイドすることもできる． また，メイルを書いたあと送信前にアクセスして，メイルの形式や内容をチェックすることもできる． 目的によってテンプレートの形式もかわってくる．

テンプレートの数がすくなければ，Thunderbird の　「テンプレート」　フォルダーのような，メイラーのフォルダにいれておくのがよい． しかし，テンプレートの数がおおいとき，あるいは組織ごとにテンプレートがわかれているようなときは，メイラーには必要最小限のものだけをいれて，他は Web ブラウザなどで検索 (ブラウズ) するようにするのがよい．

「QuickML におけるメイル・アドレスの用法 — 機能実現の手段」 に書いたように，QuickML においてはメイリング・リストをかんたんな方法によって管理することができる． ここではメイリング・リストだけでなく，ひとびとがメッセージをやりとりする場としての “会議室” の管理に対象をひろげて，その応用についてかんがえる．

SMTP の使用を前提とするかぎり，メイルサーバまたはメイルプロキシを使用した機能拡張の範囲は比較的かぎられている． Reasonable な方法はメイルの宛先 (RCPT コマンドの指定内容) や送信元 (MAIL コマンドの指定内容) によって動作をきりかえることである． QuickML [Tak 03] [Mas 03] はそういう機能拡張によってメイリング・リストを実現している．

「メイル誤送信の分析」 に書いたように，重要なメイル誤送信のパターンとして添付ファイルのとりちがえや不足・過剰などがある． これらはメイルを送信する際にチェックすることによってふせぐことができるはずである． そこで，宛先として特定のテンプレートにもとづくメイル・チェック機能を指定することによって，このような誤送信をふせぐ方法について検討する．

QuickML の方法を改良したメイリング・リストの実現に関しては 「QuickML 方式の簡易 “会議室” 管理の応用」 において仕様を検討したが，ここではそこでの選択肢をしぼって，ひとつの仕様にまとめる．

添付ファイルの自動チェックに関しては 「宛先指定による添付ファイル自動チェック機能の仕様」 に書いたが，ここでは手動チェックもふくめた，よりひろいチェック機能の仕様について検討する．

ワークフローにおいては個々のトランザクションを識別する必要があるが，メイル・ワークフローにおいてその識別子としてなにを使用するかをきめる必要がある．

宛先によって機能を指定する際に，パラメタをわたしたいことがある． たとえば添付ファイル名のチェックにおいてはファイル名やプレフィクス，ポストフィクスなどをパラメタとしてわたしたい． こういうときのために，メイルアドレスを機能とパラメタとに分解するしくみをそなえておくのがよいとかんがえられる．