Provided by: manpages-ja_0.5.0.0.20210215+dfsg-1_all
名前
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 から起動され る、バッククォートで囲まれたプログラムは、 メール全体を標準入力から受け取る。 コメント # から始まる行は、全ての文字が改行まで無視される。 但し、条件行には当てはまらない。 条件行 にはコメントが付けられない。 レシピ ':'で始まる行はレシピの開始を示す。 書式は以下の通り: :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 :/bin :/usr/bin :/usr/local/bin :/usr/bin/X11 (但し、 /etc/procmailrc を除く。 /etc/procmailrc の場合は、次のようになる: `/bin:/usr/bin:/usr/local/bin:/usr/bin/X11'.) SHELLMETAS &|<>~;?*[ 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 の一部には非標準の拡張を含む実装があることに注意されたい): ^ 行頭 $ 行末 . 改行以外のすべての1文字とマッチする 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|Cc|Bcc)|(X-Envelope |Apparently(-Resent)?)-To):(.*[^-a-zA-Z0-9_.])?)' と置換される。 これにより、特定の アドレ ス を含む送付先の記述を全て捕捉できるだろう。 正規表現に `^TO' とある場合、 `(^((Original-)?(Resent-)?(To|Cc|Bcc)|(X-Envelope |Apparently(-Resent)?)-To):(.*[^a-zA-Z])?)' と置換される。 これにより、特定の 単語 を含む 送付先の記述を全て捕捉できるだろう。 正規表現に `^FROM_DAEMON' とある場合、 `(^(Mailing-List:|Precedence:.*(junk|bulk|list)|To: Multiple recipients of |(((Resent-)?(From|Sender)|X-Envelope-From):|>?From )([^>]*[^(.%@a-z0-9])?(Post(ma?(st(e?r)?|n)|office)|(send)?Mail(er)?|daemon|m(mdf |ajordomo)|n?uucp|LIST(SERV'u' |proc)|NETSERV|o(wner|ps)|r(e(quest|sponse)|oot)|b(ounce'u' |bs\.smtp)|echo|mirror|s(erv(ices?|er)|mtp(error)?|ystem)|A(dmin(istrator)?|MMGR |utoanswer))(([^).!:a-z0-9][-_a-z0-9]*)?[%@>\t ][^<)]*(\(.*\).*)?)?$([^>]|$)))', と置換さ れる。 これにより、大多数のデーモンから来るメールを捕捉できるだろう。 (正規表現としていか がかな? :-) 正規表現に `^FROM_MAILER' とある場合、 `(^(((Resent-)?(From|Sender)|X-Envelope-From): |>?From )([^>]*[^(.%@a-z0-9])?(Post(ma(st(er)?|n)|office)|(send)?Mail(er)?|daemon|mmdf |n?uucp|ops|r(esponse|oot)|(bbs\.)?smtp(error)?|s(erv(ices?|er)|ystem)|A(dmin(istrator)? |MMGR))(([^).!:a-z0-9][-_a-z0-9]*)?[%@>\t ][^<)]*(\(.*\).*)?)?$([^>]|$))' と置換される (`^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>