dot-courier †
名称 †
dot-courier -- ローカルメール配送指示
書式 †
$HOME/.courier $HOME/.courier-foo /etc/courier/aliasdir/.courier-foo $HOME/.courier$HOME/.courier-foo/etc/courier/aliasdir/.courier-foo
解説 †
殆どの場合、メールをあるアカウントに配送するとは、単にメッセージをアカウントのシステムメールボックスに置きに行くことを意味します。しかし、これで全てではありません。たとえば、外部プログラムを起動して、そのメッセージを処理する出あるとか、他のアドレスにメッセージを転送するなどということもありうるわけです。単純な配送指示であれば、.courier ファイルを使うことによって実現できます。複雑な処理を行いたい場合には、maildrop(1)のような、外部メールフィルタを使うと良いでしょう。
ファイル $HOME/.courier は、メッセージがこのアカウントにどのように配送されるかを指定します。もしこのファイルが存在しなければ、システム管理者によって指定された、デフォルトの配送指示が使用されます。システム管理者のデフォルトの配送支持派、アカウントのシステムメールボックスの位置を指定します。
〜以上、崎村〜
user@domain宛てのメールを受信することに加えて、userがuser-foo@domain宛て(fooは任意の値)のメールを受け取ることができます。これをするためには、user-foo@domain への配送指示を $HOME/.courier-foo に記述します。
システム管理者は、アドレスの大文字と小文字を区別しないメールを受信するように、Courierを設定できます。その場合、.courier ファイルには小文字だけでアドレスを書かなくてはなりません。どんな場合でも、ファイル名に使われるアドレスのピリオド(.)はすべてコロン(:)に置き換えなくてはなりません。例えば、user-Foo.Bar@domainのための配送指示は、~user/.courier-foo:bar に記述します。。
$HOME/.courier-foo-default ファイルは、任意のuser-foo-bar@domainのための配送指示を記述します。ここでbarはどんな値でもありえます。しかしそれは、user-foo@domain宛てのメールをコントロールしません。それは $HOME/.courier-foo によってコントロールされます。
メール配送指示には次のものが含まれます。
- 各メッセージは非標準のメールボックスに配送されるべきであるかどうか
- 別のemailアドレスへの転送
- メッセージを渡して別のプログラムを実行 .courier ファイルから実行されたプログラムは、いくつかの環境変数にアクセスします(環境変数を参照)。-default ファイルから実行されたプログラムは、メッセージが配送される正確なemailアドレスを決定するために、それらの環境変数が使えます。
規定の配送指示 †
/etc/courier/aliasdir ディレクトリは最後に探索されます。ローカルアドレスにメールを配送する方法を解く試みがすべて失敗した場合、最後に /etc/courier/aliasdir ディレクトリを調べます。
/etc/courier/aliasdir は、実際のシステムアカウントが必要ではない以外は、別名アカウントがqmailの中でどのように実行されるかに非常に似ています。<user@example.com>がローカルアドレスで、そのようなシステムアカウントがない場合で、/etc/courier/aliasdir にこのアドレスのための別名がある場合、Courierは /etc/courier/aliasdir/.courier-user から配送指示を読もうとします。
.courier による配送指定が、通常はすべて当てはまります。アドレス <user-foo@example.com> に一致するアカウントがない場合、Courierは /etc/courier/aliasdir/.courier-user-fooを、次に /etc/courier/aliasdir/.courier-user-default を、そして最後に /etc/courier/aliasdir/.courier-default を探します。
存在しないアドレスのためのローカルアドレス宛のメール配送を指示するために、あなたは /etc/courier/aliasdir/.courier-default を使用できます。動的なメール配送指示(以下を参照)と結合して、それはメールボックスの非標準の位置を指定するための方法の1つになります。
プログラム/メールボックス別名 †
ディレクトリ /etc/courier/aliasdir/.courier-:xalias/ は、プログラムやメールボックスに配送する別名を実装するmakealiases(8)?スクリプトによって作成され維持されます。より詳しくは、makealiases(8)?を参照してください。(このディレクトリは".xalias/"で始まるローカルアドレスに相当しますが、Courierではピリオド(.)から始まるローカルアドレスは禁止されています。)
さらに、makealiases(8)?は、-mオプションによってセットさされるプロトコルで /etc/courier/aliasdir/.courier-:xalias というサブディレクトリを作成します。
配送指示 †
各 .courier ファイルは、0個あるいはより多くの配送指示を記述します。.courierファイルが 0バイトのサイズのファイルの場合、それはシステム管理者によってセットされた規定のメール配送指示が使用されることを意味します。ファイルのサイズが 0バイトではないが配送指示が指定されない場合、対応するメールアドレスへのメッセージは捨てられます。
注: $HOME/.courier が存在しない場合、それは 0バイトのサイズのファイルとして扱われ、規定のメールボックスに配送されます。$HOME/.courier-foo が存在しない場合、それは存在しないアドレスとしてとして扱われ、配送できないという旨のメッセージを返します。
ホームディレクトリがグローバルな読み取り許可を持っている場合、Courierはすぐに存在しないメールボックスへのメールを拒絶するでしょう。CourierのESMTPサーバーは特権を持たないプロセスとして実行します。そのためCourierは、グローバルな読み取り許可を持たないホームディレクトリにアクセスすることはできません。したがってCourierが、メッセージを配送のために受理され、メッセージを配送しようとしたとき、即座に .courierファイルを見つけられないと、メッセージは配送できないものとして返されます。しかしながら、NDR(Non-Delivery Report:非配送報告書)を生成する前に、Courierは配送のためのメッセージを最初に受理しなければなりません。
.courierの中の配送指示は一度に実行されます。配送指示の実行がある理由のために失敗する場合、配送できないものとしてメッセージが返されるか、あるいは再配送の試みるため、再度待ち行列に登録されます。配送できないものとして、メッセージが長い期間の間、キューに残っていた場合も、配送できないものとして返されます。
注: 1つの配送指示が失敗した(また、配送できないものとして、メッセージが返された)ときでも、ファイルの中のそれより前の配送指示はとにかく終わっているでしょう。
ファイル中のブランクの行は無視されます。#文字で始まる行はコメントとして無視されます。 それ以外の各行は、3つの可能な配送指示のうちの1つを指定します:
- システムメールボックスあるいはMaildirに伝えます。
- 外部プログラムを実行します。
- あるいは、別のアドレスへメッセージを転送しします。
システムメールボックスあるいはMAILDIRへの配送 †
行頭から . あるいは / に続けて指定したメールボックスやMaildirに配送します。 行は、メールボックスファイル、あるいはMaildirの完全な位置を指定しなくてはなりません。 ファイル名が . から始まる場合は、アカウントのホームディレクトリからの相対位置になります。 メールボックスファイルは、ほとんどのメールソフトウェアによって判読可能な従来の形式です。 Maildirは、メールボックスファイルに対するいくつかの長所がある、ディレクトリに基づいたメール記憶フォーマットです。 メールボックスファイルはロックされます。また、そのため同時メール配送は許されません。 メールボックスファイルは、新しいメッセージが追加される際にロックされます。 同時配送されたメッセージの多くは捨てさられます。 Maildirsはロックを必要としないため、ひとつのMaildirに多数の同時配送をなすことができます。 Maildirsを作成するには、maildirmake(1)?コマンドを使用します。
注: Courierは、メールボックスファイルをロックする“dot-locking”形式を実装しません。Courierのロックは、もっぱらシステムのファイルロックの機能(すなわちlockf、またはflockのシステムコール)に依存します。追加のロックオプションを提供できるmaildrop(1)を、常に使用することもできます。
外部プログラムの実行 †
単一の|で始まる行は外部プログラムの実行を指示します。 行の|以降の部分は、シェルによって実行されるコマンドを指定します。 コマンドが長い場合は、行の最末尾を\にすることで、次の行に継続できます。
Courierは指定されたコマンドを実行し、標準入力にメッセージを送ります。
次の配送指示に行く前に、外部コマンドが実行を終えるまでCourierは待機します。 Courierは、配送が失敗したか否かを判断するために、外部コマンドの終了コードを検査します。
外部コマンドの終了コードが0の場合、次に指定されている配送指示が実行されます。 コマンドが最後の配送指示だった場合、メッセージの配送は成功したと見做します。
外部コマンドの終了コードが99の場合、残りの配送指示は実行されません。 しかし、メッセージの配送は成功したと見做します。
外部コマンドの終了コードが:64、65、67、68、69、70、76、77、78あるいは112のいずれかの場合は、電子メールメッセージは配送できなかったものとして返され、それ以上の配送指示は実行されません
外部コマンドの終了コードがこれら以外の場合、それは一時的エラーと見做され、メッセージは再配送のためにキューに留め置かれます。
注: 再配送の際は、.courierファイルの始めから配送指示が処理されます。
動的な配送指示 †
||から始まる行もまた外部プログラムを実行します。 行の||以降の部分は、シェルによって実行されるコマンドを指定します。 コマンドが長い場合は、行の最末尾を\にすることで、次の行に継続できます。
しかしながら、||指示によって実行されるプログラムは|指示によるものとは異なり、それらの標準出力を捕らえ、実行される追加の配送指示として解釈し直されます。 この特徴によってCourierは、外部プログラムを使った動的な配送指示を生成します。
外部プログラムの標準出力は、あたかもそれが .courier配送指示を含むかのように読まれ解析されます。 動的に生成される配送指示には、文字数に上限があります。 glibc では 8191byteが上限になります。他のシステムでも上限値は、ほとんど変わらないでしょう。
動的に生成された配達指示は、さらに再帰的に ||指示を指定するかもしれません。 再帰的な配送指示の繰り返しは、最高 4 回までです。
||指示によって起動されたプログラムの終了コードは次の例外を除いて、|指示によって起動されたプログラムの終了コードのように正確に解釈されます。 外部プログラムが、0または99の終了コードで終了する場合のみ、動的に生成された配送指示が行なわれます。 他の終了コードは、動的に生成されたどんな配送指示も廃棄します。 終了コードの扱いの他は、すべて同じです。 終了コードが99である場合、配送は成功したと見做されます。また、元の .courierファイルの残りの指示は無視されます。 終了コードが0である場合は、元の .courierファイルの残りの指示が実行されます。
別名に基づいた配送 †
Courierが /etc/courier/aliasdir の中のデフォルトの配送指示のために配送する場合、それらの配送指示は、Courierのインストールされたシステム・ユーザおよびグループidの下で行なわれます。 When Courier delivers to default delivery instructions in /etc/courier/aliasdir, those delivery instructions are carried out under Courier's installed system user and group id. それは、Courierのメール・システム・ユーザおよびグループとしてどんな実行されたプログラムあるいはメールボックスもアクセスされることを意味します。 That means that any executed programs or mailboxes are accessed as Courier's mail system user and group.
環境変数 †
.courierファイルから呼び出された外部コマンドは、以下の環境変数を持つことがあります。:
- HOME
- ホームディレクトリ。
- SENDER
- メッセージエンベロープの送信アドレス。
- RECIPIENT
- 完全な宛先のアドレス。
- HOST
- 宛先が user@domain である場合、HOSTは宛先アドレスの domain の部分です。
- LOCAL
- 宛先が user@domain である場合、LOCALは宛先アドレスの user の部分です。
- EXT
- USER が $USER-foobar である場合、EXTは foobar の部分です。
- EXT2
- EXTの最初のダッシュに続く部分です。
- EXT3
- EXT2の最初のダッシュに続く部分です。
- EXT4
- EXT3の最初のダッシュに続く部分です。
- DEFAULT
- アドレス user-foo-bar@domain のための配送指示が$HOME/.courier-foo-defaultファイルによる場合の、bar の部分です。
- UFLINE
- メッセージがメールボックスに配送される場合、メッセージに付け加えられるFrom_ヘッダ全体です。
- RPLINE
- 全ての Return-Path:ヘッダです。
- DTLINE
- 全ての Delivered-To:ヘッダです。
注: When the external program reads the message from standard input, the message will NOT have the customary From_, Return-Path:, and Delivered-To: headers which are customary for locally-delivered messages. The external program can find those headers in the respective environment variables. If you have a command that expects to see those headers as a part of the message, you can use the preline(1) wrapper to add them to the message. For example, the procmail mail filter requires those headers. 外部プログラムが標準入力からメッセージを読む時、メッセージは慣習的なFrom_、Return-Path:、Delivered-To:ヘッダを持たないでしょう。これらのヘッダはローカルに配送されるメッセージにとっては慣習的なものです。外部プログラムはそれぞれの環境変数にそれらのヘッダを見つけることができます。メッセージの一部としてそれらのヘッダを見ることを予期するコマンドを持っていれば、メッセージにそれらを加えるためにpreline(1)?包み紙を使用することができます。例えば、procmailメール・フィルタはそれらのヘッダを要求します。
注: The maildrop mail filter will not require preline if the system administrator correctly configures Courier. The system administrator can optionally configure Courier to recognize maildrop, and activate certain maildrop-specific optimizations in Courier. If these arrangemenets have been made, you can run maildrop directly from the .courier file, in a straightforward fashion, but those headers will automatically appear in the message, as seen by maildrop. Because the message is provided directly on standard input, without using a pipe, maildrop will be able to deliver the message directly from Courier's message queue, without using a temporary file. システム管理者が正確にCourierを形成すれば、maildropメール・フィルタは前行を要求しないでしょう。システム管理者は、maildropを認識し、かつ―特定のあるmaildropを活性化するために自由にCourierを設定することができます。Courierの中の最適化。これらのarrangemenetsが作られた場合、真直ぐな方法の中で、.courierファイルからmaildropを直接実行することができます。しかし、maildropによって見られるように、それらのヘッダは自動的にメッセージに現われるでしょう。メッセージが提供されるのでパイプの使用のない標準の入力およびmaildropで直接、でしょうテンポラリファイルを使用せずに、Courierのメッセージキューからメッセージを直接述べることができましてください。
フォワーディング †
.、/ あるいは | のいずれかの文字で始まらない行は、メッセージを転送するemailアドレスをコンマで区切って指定します。 行が & か ! のいずれかの文字で始まる場合、この文字は無視されます。これは過去の互換性オプションです。
バグ †
Courier's .courier may seem to be exactly like Qmail's .qmail, but there are some minor differences. Qmail, as of 1.03, does not implement dynamic delivery instructions. Courier also uses a slightly different set of return codes which are classified as hard errors. Courier's implementation of forwarding differs from Qmail's. According to Qmail's documentation, if any external command terminates in a permanent or temporary failure, the message is not forwarded to any forwarding address in the .qmail file, even to addresses that precede the failed delivery instruction. The message is forwarded only after it is successfully delivered. Courier forwards messages to addresses immediately. Also, in some cases Qmail resets the return address on the message to the address of the account being forwarded. Courierの.courierは、qmailの.qmailに正確に似ているように見えるかもしれません。しかし、いくつかの小さな違いがあります。qmailは1.03時点で、動的な配送指示を実行しません。Courierは、さらに困難なエラーとして分類されるリターン・コードのわずかに異なるセットを使用します。Courierのフォワーディングのインプリメンテーションはqmailと異なります。qmailのドキュメンテーションによれば、いずれかの外部コマンドが永久一時的失敗で終了する場合、メッセージは、失敗した配送指示に先行するアドレスへ?ｳえ、.qmailファイル中の任意の転送先へ転送されません。それが成功裡に伝えられた後だけ、メッセージが転送されます。Courierは、アドレスへのメッセージを直ちに転送します。さらに、ある場合には、qmailは、進められているアカウントのアドレスへのメッセージ上の差し出し人アドレスをリセットします。
To make things more confusing, there is a configuration setting to have Courier read $HOME/.qmail files, instead of $HOME/.courier. 事態をもっと混乱させるために、$HOME/.courierの代わりに$HOME/.qmailを読むようにする設定もあります。
参照 †
dot-forward(1), maildirmake(1)?, maildrop(1), courier(8)?.
Last-modified: Wed, 22 Jun 2005 07:59:20 JST (2893d)
