procmailrc - procmail の rcfile 【訳注: 設定ファイル】 $HOME/.procmailrc 取り敢えずすぐ始めたい場合は、 procmail (1) マニュアルの最後 にある備考を参照されたい。 rcfile は (procmail にとって特別な意味を持つものもある) いくつもの 環境変数への値の設定とレシピを含めることができる。 最も簡単な形式は、到着したメールのヘッダを検索する、一行におさまる 正規表現よりなるレシピである。 マッチした最初のレシピは、メールの行き先 (通常はファイル)を決定する為に使われる。 もし、処理が rcfile の終りに到達すると、 procmail はメールを $DEFAULT へ配送する。 【訳注: procmail では、受信するメールに対する様々な処理の命令を recipe (レシピ/処方)と呼んでいる。】 レシピは2種類存在する: 配送指示と非配送指示である。 マッチする 配送の指示 がある場合、 procmail は (推測した) メールが配送されたと見なす。 そして、レシピの動作指示を首尾良く完遂した後、rcfile の 処理を終了する。 非配送の指示 がある場合、レシピの動作指示を首尾良く完遂した後、rcfile の処理は 続行される。 配送レシピはメールのヘッダ及び/又は本文に以下の作用を引き起こす: ファイルへ書き込まれる、プログラムに呑み込まれる、あるいはメールアドレスへ転送される。 非配送のレシピは以下の通り: プログラムやフィルタの出力を procmail が 取り込むもの、あるいは入れ子構造のブロックを開始させるもの。 procmail に対し、 配送レシピ をあたかも非配送レシピであるかのように 取り扱うように命令することもできる。 その際には、該当するレシピに `c' フラグを指定する。 こうすると procmail は当該レシピへ配送する為のメールの カーボンコピー を作成し、 rcfile の処理を続行する。 沢山のレシピを使うことによって、受信したメールを、幾つかのメールフォルダへ とても簡単に振り分けることができる。 但し、メールはそれらメールフォルダに同時に到達するかも知れない、ということも 心に留めておいて欲しい。(幾つかの procmail プログラムが同時に起動する場合を 想定している。沢山のメールが到着するなら、あり得ないことではない。) このことでぐちゃくちゃにならない為に、是非ともロックファイルを正しく使って 頂きたい。 環境変数の 指定 と レシピ は rcfile 中に自由に配置できる。 procmail にとって特別な意味を持つ環境変数は全て、解析された瞬間に、適切に 使われる。(すなわち、必要なときにはいつでも新たに MAILDIR を指定すれば、カレントディレクトリを変更できるし、新たに LOCKFILE を指定すればロックファイルを切替えることができるし、いつでも umask を 変更できる等々。可能性は無限である :-) 。 これら環境変数の設定や値の置換は sh(1) における処理と完全に等しい。(これはあらゆる引用符やエスケープを含む。) 更に特典として、 '=' の前後の空白は無視してくれるし、 環境変数の後に '=' がない場合はその環境変数自体を環境から消去してくれる。 procmail から起動される、バッククォートで囲まれたプログラムは、 メール全体を標準入力から受け取る。 # から始まる行は、全ての文字が改行まで無視される。 但し、条件行には当てはまらない。 条件行にはコメントが付けられない。 ':'で始まる行はレシピの開始を示す。 書式は以下の通り: 3 :0 [flags] [ : [locallockfile] ] <ゼロあるいはそれ以上の条件 (1行に1つ)> <アクション行は厳密に1つ> 条件行は先頭に `*' が付く。この文字に続く全ての文字は、先頭と末尾の 空白を除き、procmail 内部の egrep へ 正確に 渡される。これらの正規表現は一般的な egrep(1) の拡張正規表現と 完全に 互換性がある。 拡張正規表現 の章も参照されたい。 条件行は論理積で評価される; 条件がない時はデフォルトで全て真となる。 使用可能な フラグ は以下の通り: H ヘッダを egrep する (デフォルト)。 (訳注: 正確には、egrep と同じ正規表現の解釈にて検索を行う。 フラグを省略すると、この `H' フラグが付されたものとみなされ、 続く条件行はヘッダが対象となる。) B 本文を egrep する。 D 内部の egrep に対して大文字と小文字を区別するよう指示する (デフォルトでは逆に大小文字を区別しない)。 A このレシピは、(現在のネスト構造の段階における) `A' あるいは `a' フラグが 付されていない直前のレシピも同様にマッチしない限り、実行されない。 これによって、ある条件が成立した時に実行されるアクションを複数列挙できる。 a `A' と同じ意味を持つが、更に追加される条件として、現在のレシピが 実行される前に、直前のレシピは必ず 正常終了 しなければならない、という制約がある。 E このレシピは直前のレシピが実行されなかった時にだけ実行される。 このレシピの実行はまた、直後に `E' フラグを伴う全てのレシピの実行が禁止される。 これにより、 `else if' アクションを構築することができる。 e このレシピは直前のレシピの実行が 失敗した 時にだけ実行される。(すなわち、直前のアクション行の実行結果がエラーを伴う終了であった場合である。) h メールのヘッダをパイプ、ファイルあるいはメール配送先(デフォルト)に渡す。 b メールの本文をパイプ、ファイルあるいはメール配送先(デフォルト)に渡す。 f パイプをフィルタと見なす。 c 受信したメールの カーボンコピー を作成する。 これは 配送 レシピにだけ意味がある。 このフラグが唯一有効な非配送レシピは入れ子構造 にて使われる場合である。 この時、カーボンコピーを生成する為に、実行中の procmail プロセスの クローン が作成される。(ロックファイルは継承されない。) これによってクローンは普通に実行され、親プロセスはこの時点のブロックの 処理を飛ばして次に進む。 w フィルタあるいはプログラムの実行終了を待ち、その終了コードをチェックする (通常は無視される); フィルタが正常終了しなかった場合、テキストは フィルタされず、フィルタに渡す以前の状態のままになる。 W `w' フラグと同じ意味を持つが、あらゆる `プログラムの失敗' の メッセージは抑止され、出力されない。 i このレシピにおけるあらゆる書き込みエラーを無視する (すなわち、通常は早期に閉じられたパイプに起因する)。 r Raw mode である。メールの最後が空行となるような処理を行わず、 メールが入力されたとおりに書き出す。 正しい正規表現ではないものの、特殊な条件を設定するものがある。 使用する際に、下記の条件記号は先頭になければならない: ! 条件の論理否定。 $ この条件の直後に続くダブルクォートで囲まれた中身を sh(1) の置換ルールに従って置換する。 そして先頭の空白を読み飛ばした後、再度解析する。 ? 指定したプログラムの終了コードを使う。 < 指定したバイト数(10進数)よりメール全体のバイト数が小さいか否か比較する。 > '<' の反対。 変数名 ?? この環境変数の値に対し、この条件の後に続く項目と照合する (疑似変数は指定できない)。 特殊なケースとして、環境変数名が `B', `H', `HB' および `BH' の場合は; このレシピの初期フラグによって定義されたデフォルトのヘッダ/本文検索領域を単に上書きする。 \ 上述の条件記号の意味を消す為に、記号の直前に置いて使われる。 (訳注: この `\' (バッククォート) は、条件記号の意味を消して通常の 文字 (literal character: リテラル文字) として扱う機能を持つものであり、 条件記号ではない。よって、本来は条件記号と同列に扱われて説明されるべき ものではない。また、このマニュアルの後半に例示があるが、これら条件記号 の先頭に使われるだけに留まらないので、注意が必要である。) 最初のレシピ行に2個目の ':' をレシピの末尾に付加すると、 procmail は ローカルロックファイル を (このレシピに対してのみ) 使用する。 ':' の後に、 オプションとして任意のローカルロックファイル名を指定できる; もし、 ':' の後にローカルロックファイル名を指定しない場合は、配送先のファイル名 (あるいは '>>' 【訳注: 追加リダイレクタ】 の後に指定されるファイル名) に拡張子 $LOCKEXT を付加したファイル名がローカルロックファイル名として使われる。 アクション行は以下に記す文字で開始する: ! この後に指定される全てのメールアドレスにメールを転送する。 【訳注: メールアドレスはスペースで区切って列挙可能。】 | 指定したプログラムを実行し、そのプログラムの標準入力にメールをパイプで渡す。 もし、 $SHELLMETAS に含まれる文字が '|' 直後に指定されるプログラムのコマンドライン中にあれば、プログラムは $SHELL を介して起動される。 オプションとして、このパイプ記号の前に variable= を指定すると、プログラムの標準出力が環境変数 variable に取り込まれる。 (この時点において procmail は rcfile の処理を終了 しない 。) 【訳注: すなわち、パイプ記号の後に指定されるプログラムが終了しないと、 procmail のプロセスは終了できない。】 このパイプ記号だけを指定し、パイプ記号の後にプログラム等の記述を一切しない場合には、 procmail はメールを標準出力に書き出す。 { の後にスペース、タブ、改行のいずれか一つ以上を伴うことにより、入れ子構造の開始を示す。 次の閉じ括弧までの全ては、このレシピにて指定される条件に依存する。 ネストの数は無制限である。 閉じ括弧は単にブロックの終りを示す為だけに存在し、どのような状態であっても閉じ括弧に procmail を終了させる機能はない。 ブロックの終了に到達すれば、そのブロックの後の処理を続行する。 ネストされたブロック上において、フラグ `H' と `B' だけがブロックを導く条件として作用し、逆にフラグ `h' と `b' はブロック内においては全く意味をなさない。 以上に示した以外のものは全てメールボックス名 (ファイル名、ディレクトリ、絶対パスあるいはカレントディレクトリからの相対パス(MAILDIR を参照のこと)) として解釈される。 ファイル名の場合 (まだ存在していない可能性もある) は、メールはそのファイルに追加される。 ディレクトリ名の場合、メールは指定されたディレクトリ内に重複しないことを保証されたファイル名 $MSGPREFIX* として新たに作成され、配送される。 メールボックスのディレクトリ名が "/." で終っていると、当該ディレクトリは MH フォルダと見なされる; すなわち、 procmail はそのディレクトリ内に存在する有効な最終メッセージ番号のファイル名を探し、その次の番号を新たなメールのファイル名とする。 メールボックスのディレクトリが "/" で終っていると、当該ディレクトリは maildir フォルダと見なされる; すなわち、 procmail は一旦メッセージを "tmp" というサブディレクトリにファイルとして配送した後、 "new" というサブディレクトリへリネーム (rename) する。 メールボックスを MH フォルダあるいは maildir フォルダとして指定した際に、もし指定されたディレクトリがない場合は、 procmail はそのディレクトリを新たに作成する。 メールボックスの作成規則として、当該ディレクトリ名をその時点で存在していないファイル名として置き換えるような処理は行わない。 procmail がディレクトリに配送している時には、配送先に複数のディレクトリを指定できる。( procmail は複数ディレクトリへの配送をハードリンクを用いて行う。) LOGNAME, HOME およびSHELL あなた (受信者) のデフォルト値 PATH $HOME/bin 'u' :/bin 'u' :/usr/bin 'u' :/usr/local/bin 'u' :/usr/bin/X11 (但し、 /etc/procmailrc を除く。 /etc/procmailrc の場合は、次のようになる: `/bin 'u' :/usr/bin 'u' :/usr/local/bin 'u' :/usr/bin/X11'.) SHELLMETAS & 'u' |<>~;?*[ SHELLFLAGS -c ORGMAIL /var/spool/mail/$LOGNAME
(オプション -m を指定していない場合に限る。 -m を指定すると設定 されない。) MAILDIR $HOME
(但し、最初の読み込みに成功した rcfile のファイル名が `./' で始まっているか、 -m オプションが指定されている場合を除く。これらの場合、 MAILDIR のデフォルト値は `.' になる。) DEFAULT $ORGMAIL MSGPREFIX msg. SENDMAIL /usr/sbin/sendmail SENDMAILFLAGS -oi HOST 現在のホスト名 COMSAT no
(rcfile がコマンド行で指定されている場合) PROCMAIL_VERSION 3.22 LOCKEXT .lock 上記以外に、 procmail の実行の際に初期化されるか予め設定される環境変数 として、 IFS, ENV, PWD がある。 セキュリティ上の理由により、 procmail の実行開始の際に procmail プログラムにリンクされているランタイムリンカの動作を変更する恐れのある環境変数は全て除去される。 沢山の環境変数に面食らってしまう前に、これらは全て妥当なデフォルト値を備えていることを忘れないでいて欲しい。 MAILDIR procmail が動作する際のカレントディレクトリ。 (すなわち、全てのパスは $MAILDIR からの相対指定であることを意味する。) DEFAULT デフォルトの メールボックス ファイル。 (特に指定しない場合、 procmail はこのメールボックスへメールを追記する。) このメールボックスファイルへの書き込みに先立ち、 procmail は $DEFAULT$LOCKEXT というロックファイルを自動的に作成して用いる。 この変数を明示的に設定する必要はない。デフォルトでシステム標準のメールボックスが設定されているからである。 【訳注: 但し、 qmail にて /var/mail/useraccountname から $HOME/Mailbox へのシンボリックリンクが張られている環境下では、 src/authenticate.c の MAILSPOOLHOME のコメントアウトを外し、 #define MAILSPOOLHOME "/Mailbox" と定義させてビルドした上で、 ~/.procmailrc では DEFAULT=$HOME/Mailbox に設定する必要がある。 そうしないと、シンボリックリンクは /var/spool/mail/BOGUS.useraccountname.PID にリネームされてしまう。 シンボリックリンクのファイル名を書き換える理由は procmail.1 を参照されたい。】 LOGFILE このファイルには procmail から発生したエラーメッセージあるいは診断メッセージ (通常は何もない :-) あるいは procmail から起動された任意のプログラムのメッセージ も含まれる。 このファイルが設定されない場合、診断メッセージあるいはエラーメッセージは送信者へメールにて返送される。 LOGABSTRACT も参照のこと。 VERBOSE この変数に `yes' または `on' を書き込むと、 拡張診断メッセージ 機能が有効になる。 再度これを無効にするには、 `no' または `off' を設定する。 LOGABSTRACT 実行終了する直前に、 procmail は配送メッセージの要約を $LOGFILE にログ記録する。 ログにはヘッダの `From ' と 'Subject:' 、最終的に送達されたフォルダ、 メッセージのバイト数が記録される。 この環境変数に `no' を設定すると、このような要約の生成が抑止される。 この環境変数に `all' を設定すると、実行に成功した 配送レシピ の処理結果の要約をログ記録する。 LOG この変数に割り当てられたものはすべて $LOGFILE に追加される。 ORGMAIL 通常、システムメールボックス (ORiGinal MAILbox の略) を指す。 (`filesystem full' 等の) 何らかの原因でメールを配送できない場合、 このメールボックスが最後の手段となる。 procmail がこのメールボックスへの保存に失敗した場合 (深刻な、深刻なトラブルである :-)、メールは送信元に返送される。 LOCKFILE グローバルなロックファイル。 このファイルが既に存在している場合、 procmail は処理を進める前にこのファイルが除去される迄待ち、 (当該ファイルが除去されたら) 処理に先立って同様のロックファイルを自ら作成しようとする。 グローバルロックファイルの使用はできるだけ控えて欲しい。 可能な限り、代わりに (レシピ毎に) ローカルロックファイルを使って欲しい。 LOCKEXT ローカル ロックファイル を識別する為に、配送先ファイルのファイル名に付加する拡張子。 (オン設定されている時のみ、レシピ毎に。) LOCKSLEEP もし、 procmail が処理に先立って ロックファイル を作成しようとした際に、 ロックファイル が既に存在していた場合、 procmail が ロックファイル の再作成を待つ秒数。 特に指定なき場合、デフォルトとして8秒が設定されている。 LOCKTIMEOUT ロックファイル が最後に変更された/作成された時点から、procmail が 「これは誤って残ったロックファイルであり、今、強制的に削除できる」 と決定する前に経過しなければならない秒数。 これにゼロを設定すると、タイムアウトは生じない。 すなわち、 procmail はロックファイルが取り除かれる迄永遠に待つこととなる。 特に指定なき場合、デフォルトとして1024秒が設定されている。 この変数は sendmail/procmail の不明瞭なハングアップを防ぐ為に有用である。 procmail はマシンを跨ったクロックずれに影響されない。 TIMEOUT procmail が、「いくつか起動した子プロセスのどれかがハングしている」と決定する迄に経過しなければならない秒数。 この変数に設定された時間が経過すると、問題となるプログラムは procmail から TERMINATE シグナルを受け、 rcfile の処理は続行される。 これにゼロを設定すると、タイムアウトは生じない。 すなわち、 procmail は子プロセスが終了する迄永遠に待つこととなる。 特に指定なき場合、デフォルトとして960秒が設定されている。 MSGPREFIX メッセージをディレクトリに配送する際に使用する、ファイル名の接頭辞。 (但し、 maildir 或いは MH ディレクトリに配送する際には使われない。) HOST これがマシンの ホスト名 と異なる場合、現在の rcfile の処理を直ちに中断する。 この他にも rcfile がコマンドラインにて指定された場合は、処理は次の rcfile へ続行される。 全ての rcfile が使い尽くされると、プログラムは終了するが、エラーは生成されない。 (すなわち、メイラにとってみればメールは配送されたかのように見える。) UMASK この変数名が全てを物語っている。 (わからないなら気にしないで欲しい:-) UMASK への指定は全て 8進数 の数値として取り扱われる。 特に指定なき場合、デフォルトとして077が設定されている。 umask の指定が o+x を許可する設定になっている場合、 procmail が直接配送する全てのメールボックスは o+x モード変更を受け入れる。 これは新着メールの有無のチェックに役立つ。 SHELLMETAS もし、 SHELLMETAS に含まれる文字が指定されるフィルタやプログラムの コマンドライン中にあれば、プログラムは直接実行されず、コマンドラインは $SHELL に渡され、$SHELL を介して起動される。 SHELLFLAGS $SHELL の実行は以下のようなコマンドラインにて実行される:
"$SHELL" "$SHELLFLAGS" "$*"; SENDMAIL 転送 機能を使っていない場合、気にする必要はない。 この変数には、あらゆるメールを転送する為に呼び出されるプログラムを指定する。
起動方法は次の通り: "$SENDMAIL" $SENDMAILFLAGS "$@"; NORESRETRY `process table full', `file table full', `out of memory' あるいは `out of swap space' というエラーが発生した際の、再試行の回数。 この変数に設定する数が負の値の場合、 procmail は無限に再試行する; 特に指定なき場合、デフォルトとして4回が設定されている。 再試行は $SUSPEND 秒の間隔を伴って実行される。 これは、元々以下のようなアイディアから端を発している。 例えば、 スワップ スペース が使い尽くされたか、あるいは プロセス テーブル が一杯になった場合、大概は他の幾つかのプログラムもこの状態を同様に検出して中断するか、クラッシュするだろう。8-) このことにより、貴重な リソース が procmail の為に開放されるであろうことを期待している。 SUSPEND 何らかの利用できないもの (メモリ、 fork 【訳注: 子プロセスの生成】等) の為に procmail が待たなければならない際に、一時停止する秒数。 特に指定なき場合、デフォルトとして16秒が設定されている。 LOCKSLEEP も参照のこと。 LINEBUF 内部ラインバッファの大きさ。 128未満には設定できない。 rcfile から読み込む行は、展開前後にかかわらず $LINEBUF を越えてはならない。 特に指定なき場合、デフォルトとして2048バイトが設定されている。 勿論、この制限はメール自身の読み込みには 適用されない。 メールの行は任意の長さになり得るし、バイナリファイルもあり得る。 PROCMAIL_OVERFLOW も参照のこと。 DELIVERED これに `yes' が設定されていると、 procmail は (メールエージェントに対し) メールが配送されたかの如く振舞う。 この変数に `yes' が設定された後にメールの配送に失敗した場合、メールは 失われる。(すなわち、送信元に返送されない。) TRAP procmail の処理がシグナルの受信によらず、一致によって正常終了する時、 この変数の内容を実行する。 メールのコピーは標準入力から読み込める。 このコマンドにて生成される全ての出力は $LOGFILE へ追記される。 TRAP の用途としては: 一時ファイルの消去、カスタマイズした要約のログ記録等。 EXITCODE 及び LOGABSTRACT も参照されたい。 EXITCODE デフォルトでは、 procmail は以下の場合において終了コード "0" (正常終了) を返す: メッセージを正常に配送できた場合。 変数 HOST が設定されておらず、コマンドラインにて rcfile が全く指定されていなかった場合。 上記以外の場合、 procmail は失敗を示す終了コードを返す。 上述のデフォルト動作を実行する前に、 procmail はこの変数の値を調べる。 この変数に正の値が設定されている場合、 procmail は正常終了時の終了コードとして この値を用いる。 この変数が設定されていながらその値が空であり、且つ変数 TRAP が設定されている場合は、 procmail は変数 TRAP に記述されているプログラムの帰り値を終了コードとして返す。 この変数が設定されていない場合、変数 TRAP に記述されているプログラムを実行する直前に、終了コードを設定する。 【訳注: すなわち、 TRAP プログラムの終了コードは用いられない。】 LASTFOLDER procmail がメールをフォルダやプログラムに配送する際には、必ず この変数に値が設定される。 この変数の値は、 procmail がメールを配送した最後のファイル (あるいはプログラム) の名前である。 最終配送が複数のディレクトリフォルダに対するものであるなら、 $LASTFOLDER にはスペースで区切られたハードリンクのファイル名リストが格納される。 MATCH レシピ中に正規表現のマッチング文字列を抽出する指示があると、この変数が 設定される。 `\/' トークン以後の正規表現に合致するテキストが全て格納される。 SHIFT この変数に正の値を設定すると、 sh(1) の `shift' コマンドと同じ効果が得られる。 このコマンドは procmail を一般的なメールフィルタとして使う際に、 procmail に渡された引数を抽出する時に最も有用である。 INCLUDERC (カレントディレクトリからの相対指定で) rcfile のファイル名を指定すると、 そのファイルを現在の rcfile の一部として組み込む。【訳注: include: インクルード】 入れ子構造ができ、その数はシステムリソース (メモリ及びファイルディスクリプタ) によってのみ制限される。 インクルードされる rcfile のパーミッション及び所有者はチェックされないので、 INCLUDERC を使用する場合には、インクルードされる rcfile あるいは rcfile のあるディレクトリへの書き込み権限を、信用できる ユーザだけが持つことを確認すべきである。 なお、 INCLUDERC に対するコマンドライン引数の指定は無意味であり、何の効果も持たない。 SWITCHRC (カレントディレクトリからの相対指定で) rcfile のファイル名を指定すると、 procmail の処理はそのファイルへ切替えられる。 この変数に指定された rcfile のファイル名が存在しないものであるか、 通常のファイルでないか、あるいは /dev/null である場合は、エラーがログ記録 され、それ以降の現在の rcfile の処理が継続される。 そうでない場合、 procmail による現在の rcfile の処理は中断され、この 変数に記述された rcfile の処理が開始される。 変数 SWITCHRC の内容を消去すると、その時点で割り当てが終了したかの如く、それまで 実行していた現在の rcfile の処理を中断する。 INCLUDERC と同様、 rcfile のパーミッション及び所有者はチェックされず、また コマンドライン引数の指定は無意味であり、何の効果も持たない。 PROCMAIL_VERSION 実行中の procmail バイナリのバージョン番号。 PROCMAIL_OVERFLOW procmail がバッファオーバフローを検出すると、この変数に何らかの値が設定される。 オーバフロー発生時の操作の詳細は、 バグ の章を参照のこと。 COMSAT デフォルトでは Comsat(8)/biff(1) によるメール到着時の通知が有効になっている。 この変数に `no' を設定すると、この機能をオフにできる。 別の方法として、この変数に `service@', `@hostname' あるいは `service@hostname' と設定することにより、 biff サービスをカスタマイズできる。 特に指定なき場合、デフォルトは `biff@localhost' である。 DROPPRIVS この変数に `yes' を設定すると、 procmail は本来持っている権限 (suid あるいは sgid) を全て放棄する。 これは /etc/procmailrc ファイルの後半を確実に受信者の権限にて実行させたい 時にのみ役立つ。 standard 次のトークンは procmail 内部の egrep および標準的な egrep(1) の両方で 知られた表現である (egrep の一部には非標準の拡張を含む実装があることに注意されたい): ^ 行頭 $ 行末 . 改行以外のすべての１文字とマッチする a* *の直前の文字aの0回以上の繰り返し a+ *の直前の文字aの1回以上の繰り返し a? 0個あるいは1個のa [^-a-d] ハイフン(dash)でもなく、aからdまででもなく、改行でもない、任意の1文字 de|abc `de'あるいは`abc'の文字列のいずれか (abc)* 文字列 `abc' の0回以上の繰り返し \. 単一のドット; あらゆる特殊文字の特別な意味付けを除去し、リテラル文字として マッチングさせたい場合には、\ を先頭に置いて使う。 $\ の変数代入も参照のこと。 勿論、これらは単なる一例でしかないので、より複雑な組合せも有効である。 次のトークンの意味は procmail 特有の拡張定義である: ^ or $ 改行 とマッチする (複数行にわたるマッチング用) ^^ 正規表現の先頭に記述することにより、検索領域の一番最初の部分にマッチする。 あるいは、正規表現の末尾に記述することにより、検索領域の一番最後の部分にマッチする。 \< or \> 単語の直前あるいは直後の文字にマッチする。 これらは単に `[^a-zA-Z0-9_]' の省略形でしかないが、但し、改行にもマッチする。 これらは実際の文字にマッチするので、単語の区切りにのみ有用であり、 単語間のスペースを区切るものではない。 \/ 正規表現を、 \/ を境にして二つに分ける。 \/ の右側の正規表現にマッチした文字列は、環境変数 MATCH に格納される。 procmailex(5) man page を参照されたい。 環境の基礎となるシェルがコマンドラインの継続行の指示にバックスラッシュ を必要としないものであったとしても、 プログラム名を指定するアクション行 における継続行は、常にバックスラッシュで 終っていなければならない。 これは二段階の構文解析処理が必要だからである (第一に procmail, 次にシェ ル (あるいはそうでない場合は、変数 SHELLMETAS の内容に依存する))。 レシピ中の正規表現の条件行にコメントを入れないこと。 それらの行は内部の egrep に 文字通りそのまま 渡される(但し、行末の継続行指定の為のバックスラッシュを除く)。 複数行にわたる正規表現条件行における行頭の空白は、通常無視される (すなわち、インデント可能である)。 但し、連続する条件行がダブルクォーテーション内の sh(1) の置換規則に従って評価される場合を除く。 あなた自身のアカウントへメールを転送する等の危険な行為を行う際には、 デッドロックを見張っていて頂きたい。 デッドロックは変数 LOCKTIMEOUT に指定されている時間が経過すると、正常終了の結果としてなくなってしまう。 幾つかの環境変数のデフォルト値は、 procmail 内部に定義済のデフォルト値にて 常に 上書きされる。 このデフォルト値を更に上書きしたい場合は、 rcfile にて直接指定するか、あるいはコマンドラインの引数にて指定しなければならない。 /etc/procmailrc は、ユーザ rcfile を処理する時点の PATH 設定を変更することは できない。 /etc/procmailrc にて PATH を設定しても、 /etc/procmailrc の処理を終了した 時点でリセットされてしまう。 この領域における将来の拡張が望まれるが、 procmail を所望の値にて定義して 再コンパイルするのが、現時点での唯一の解決法である。 レシピの一部分においてシェルが解釈する `|' によるパイプ動作の内部で設定する環境変数は、 レシピの終了後にその値は保持 されない 。 何故なら、それら環境変数の指定は procmail のサブシェル上で行われるからである。 環境変数の設定を確実に保持したいなら、レシピの `|' の前に環境変数を 設定しなければならない。 そうすれば、プログラムの標準出力がその環境変数の値としてキャプチャされる。 もし、配送指示で `h' あるいは `b' フラグのみ指定され、且つレシピがマッチ し、そして更に `c' フラグがない場合、各々のフラグに対応するメールの本文 あるいはヘッダは、エラーメッセージ等を伴うことなく静かに消え去る。 【訳注: すなわち、レシピの指示行が `c' フラグを伴わない `h' のみの場合はメール本文が、同様に `b' のみの場合はメールヘッダが、各々失われる。】 procmail(1), procmailsc(5), procmailex(5), sh(1), csh(1), mail(1), mailx(1), binmail(1), uucp(1), aliases(5), sendmail(8), egrep(1), regexp(5), grep(1), biff(1), comsat(8), lockfile(1), formail(1) procmail 自身が処理できる環境変数の置換機能は以下の通り: $name, ${name}, ${name:-text}, ${name:+text}, ${name-text}, ${name+text}, $\name, $#, $n, $$, $?, $_, $-, $=; procmail の置換機能によれば、上述の置換機能は以下のように置換される: $\name は $name 内に存在する全ての特殊正規表現文字の機能を \ で無効化した 文字列に等しく置換される。 $_ は現在の rcfile のファイル名に置換される。 $- は $LASTFOLDER に置換される。 $= は最後のレシピのスコアを含む。 更に、 $\name の置換結果は決して空白文字では分割されない。 -a あるいは -m オプションが用いられる時、 $# は指定した引数の数に展開される。 そして、 "$@" (ダブルクォーテーションは必須) は指定した引数に 展開される。 しかしながら、 "$@" はプログラムの引数リストに使う時にだけ展開され、 且つこの展開動作は一回だけである。 procmail によって行われるクォートされない変数展開は、常にスペース、タブ、 及び改行文字によって分割される; IFS 変数は内部では用いられない。 (訳注: IFS は Internal Field Separator (内部フィールドセパレータ) のこ とで、ある文字列を 指定した文字毎に分割し、配列変数に格納する際に指定 する区切り文字である。 sh や bash 等のコマンドライン展開に用いられるが、 この環境変数におかしな値を設定すると、セキュリティが脅かされる可能性が 指摘されている。) procmail は `~'の展開をサポートしない。 ラインバッファ長 $LINEBUF は rcfile の処理の際に用いられる。 $LINEBUF の制限からはみ出てしまう変数展開は切り詰められ、その時点で PROCMAIL_OVERFLOW が設定される。 オーバフローした行が条件行あるいはアクション行である場合、当該行は解析あるいは処理に 失敗したものと見倣され、 procmail はそれ以降の処理を継続する。 オーバーフローした行が変数設定あるいはレシピの開始行である場合、 procmail は その時点で当該 rcfile 全体の処理を中断する。 グローバルロックファイルが 相対 パスであり、且つカレントディレクトリがグローバルロックファイルが作成された 時点とは異なる時に procmail が終了した場合、グローバルロックファイルは消去 されない (処方箋: グローバルロックファイルは 絶対 パスにて指定すべし)。 rcfile が 相対 パスであり、 rcfile 中にて最初に開いた MAILDIR が相対パスを含んでおり、且つ、 rcfile を開いた時からカレントディレクトリが 変更された後に procmail に自身のクローンを作成する指示がなされた場合、 procmail は自身のクローンを作成できない (処方箋: rcfile の指定は 絶対 パスにて行うか、 rcfile 中の MAILDIR の指定に絶対パスが含まれるように 注意すべし)。 レシピ上で fork しないネストされたブロックの先頭に記すローカルロックファイルは、 期待通りには動作しない。 レシピから標準出力を環境変数へ取り込む時、必ず最後の改行が一つだけ取り除かれる。 幾つかの適切でない、あるいは不明瞭な正規表現は変数 MATCH に不正な値を設定してしまう。 その際、正規表現中の \/ トークンの左側にある一つ以上の不要な '*', '+', あるいは '?' 記述子は正常動作の為に除去される。 正規表現に `^TO_' とある場合、 `(^((Original-)?(Resent-)?(To 'u' |Cc 'u' |Bcc) 'u' |(X-Envelope 'u' |Apparently(-Resent)?)-To) 'u' :(.*[^-a-zA-Z0-9_.])?)' と置換される。 これにより、特定の アドレス を含む送付先の記述を全て捕捉できるだろう。 正規表現に `^TO' とある場合、 `(^((Original-)?(Resent-)?(To 'u' |Cc 'u' |Bcc) 'u' |(X-Envelope 'u' |Apparently(-Resent)?)-To) 'u' :(.*[^a-zA-Z])?)' と置換される。 これにより、特定の 単語 を含む送付先の記述を全て捕捉できるだろう。 正規表現に `^FROM_DAEMON' とある場合、 `(^(Mailing-List 'u' : 'u' |Precedence 'u' :.*(junk 'u' |bulk 'u' |list) 'u' |To 'u' : Multiple recipients of |(((Resent-)?(From 'u' |Sender) 'u' |X-Envelope-From) 'u' : 'u' |>?From )([^>]*[^(.%@a-z0-9])?(Post(ma?(st(e?r)? 'u' |n) 'u' |office) 'u' |(send)?Mail(er)? 'u' |daemon 'u' |m(mdf 'u' |ajordomo) 'u' |n?uucp 'u' |LIST(SERV 'u' |proc) 'u' |NETSERV 'u' |o(wner 'u' |ps) 'u' |r(e(quest 'u' |sponse) 'u' |oot) 'u' |b(ounce 'u' |bs\.smtp) 'u' |echo 'u' |mirror 'u' |s(erv(ices? 'u' |er) 'u' |mtp(error)? 'u' |ystem) 'u' |A(dmin(istrator)? 'u' |MMGR 'u' |utoanswer))(([^).! 'u' :a-z0-9][-_a-z0-9]*)?[%@>\t ][^<)]*(\(.*\).*)?)?$([^>] 'u' |$)))', と置換される。 これにより、大多数のデーモンから来るメールを捕捉できるだろう。 (正規表現としていかがかな? :-) 正規表現に `^FROM_MAILER' とある場合、 `(^(((Resent-)?(From 'u' |Sender) 'u' |X-Envelope-From) 'u' : 'u' |>?From )([^>]*[^(.%@a-z0-9])?(Post(ma(st(er)? 'u' |n) 'u' |office) 'u' |(send)?Mail(er)? 'u' |daemon 'u' |mmdf 'u' |n?uucp 'u' |ops 'u' |r(esponse 'u' |oot) 'u' |(bbs\.)?smtp(error)? 'u' |s(erv(ices? 'u' |er) 'u' |ystem) 'u' |A(dmin(istrator)? 'u' |MMGR))(([^).! 'u' :a-z0-9][-_a-z0-9]*)?[%@>\t ][^<)]*(\(.*\).*)?)?$([^>] 'u' |$))' と置換される (`^FROM_DAEMON' の機能制約バージョンである)。 これにより、大多数のメイラデーモンから来るメールを捕捉できるだろう。 VERBOSE, DELIVERED あるいは COMSAT のような、変数にブール値を割り当てる時、 procmail は以下の文字列から始まる文字列を論理真と認識する: 非ゼロの数、 `on', `y', `t' あるいは `e' 。 同様に、procmail は以下の文字列から始まる文字列を論理偽と認識する: ゼロ、 `off', `n', `f' あるいは `d' 。 レシピのアクション行がプログラムを指定している場合、空行に唯一 「バックスラッシュ-改行」の組合せのみ存在する行は、改行へ変換される。 procmail に組み込まれている正規表現エンジンは名前付けされた文字クラスを サポートしない。 rcfile 内において、囲み記号等で囲まれていない行頭の空白は、通常無視される。 よって、好みに応じてインデント可能である。 プログラムあるいはフィルタを指定する、アクション行の先頭の `|' は $SHELLMETAS のチェックの前に除去される。 環境変数の指定だけを含む、INCLUDERC ディレクティブに含まれるファイルは sh と共有されうる。 現在のコマンドラインにおける INCLUDERC 及び SWITCHRC の動作の仕様は未確定である。 既に動作仕様は一度変更されており、将来には変更あるいは除去される可能性がある。 本当に 複雑な処理を行いたいなら、 procmail を再帰的に呼び出すことも検討すると良いだろう。 かつて、レシピの始まりを示す `:0' は、条件の数 n に応じて `:n' と 書き換える必要があった。 Stephen R. van den Berg <srb@cuci.nl> Philip A. Guenther <guenther@sendmail.com>