Postfix
アドレス書き換え Postfix
アドレス書き換え アドレス書き換えは Postfix メールシステムの核心です。Postfix は多くの 様々な目的でアドレスを書き換えます。単に表面的なものもありますし、正しい 形式のメールを正しい配送先に配送するのに必要なものもあります。Postfix の アドレス書き換えの例:
不完全なアドレスを完全なアドレスに書き換えます。例えば、 "username" を "username@example.com" に書き換えたり、"username@hostname" を "username@hostname.example.com" に書き換えます。
アドレスを同等のアドレスで置き換えます。例えば、メール送信時に "username@example.com" を "firstname.lastname@example.com" に書き換え、 受信時には逆に書き換えます。
内部アドレスを外部アドレスで置き換えます。例えば、家の コンピュータからインターネットにメールを送る際に "username@localdomain.local" を "isp-account@isp.example" で置き換えます。
一つのアドレスを複数のアドレスで置き換えます。例えば、エイリアスの アドレスをエイリアス以下にリストアップされたアドレスで置き換えます。
特定のアドレス宛のメールの配送方法や配送先を決定します。例えば、 "username@example.com" 宛のメールを smtp(8) 配送エージェントで、ドメイン "example.com" のメールサーバとして DNS に リストアップされたホストに配送します。
Postfix は現在アドレス書き換え言語を持っていませんが、テーブル検索を 使って驚くほど強力なアドレス操作をおこなうことができます。Postfix は一般に、 一つのアドレスを一つもしくは複数のアドレスにマッピングするには固定された 文字列を持つ検索テーブルを、複数のアドレスを一つもしくは複数のアドレスに マッピングするには正規表現を使います。固定された文字列の検索テーブルは ローカルファイルや NIS、LDAP、SQL データベース形式かもしれません。 DATABASE_README ドキュメントに Postfix 検索テーブル入門があります。
このドキュメントがカバーしている話題:
Postfixバージョン2.1以前では常にメッセージヘッダアドレスを書き換え、 Postfixが不完全と見なしたアドレスにはPostfix自身のドメイン情報を加えて いました。ローカルで生成されたメールではメッセージヘッダを書き換えても 問題ありませんが、リモートメールの書き換えは望ましくありません:
Postfixバージョン2.2ではリモートSMTPクライアントからのメッセージヘッダを 全く書き換えないか、メッセージヘッダの不完全なアドレスを不正なものとして ラベリングするという選択肢が与えられます。これは次のように動きます:
以下の図は Postfix でアドレス書き換え動作に最も関係のある部分を拡大した ものです。完全な Postfix アーキテクチャの概要は OVERVIEW ドキュメントを参照してください。 数字が続く名前は Postfix デーモンプログラムで、数字のない名前は Postfix キューまたはメールメッセージの内部ソースを表します。
trivial-
rewrite(8)
(標準 形式)trivial-
rewrite(8)
(解決)
^
||
v
^
||
vsmtpd(8) >- cleanup(8) -> incoming -> active -> qmgr(8) -< smtp(8) qmqpd(8) lmtp(8) pickup(8) local(8) ^
|
^
||
vbounces
forwarding
noticesdeferred
以下の表は全ての Postfix アドレス操作をまとめたものです。この ドキュメントを初めて読むのであれば、 "メール受信時のアドレス 書き換え " に飛んでください。このドキュメントの残りを読み終わると、 必要なものをすぐに見つけるのにこの表が役立つでしょう。
cleanup(8) サーバは転送されたメールの ような内部ソースからのメールや送信者にバウンスされる配送できないメール、 メールシステムの問題を postmaster に通知するメールと同様に、Postfix の 外からのメールを受信します。
cleanup(8) サーバは送信者や受信者、 メッセージの中身を incoming キューに書き込む前に標準的な形式に変形します。 サーバはメッセージヘッダおよびエンベロープの送信者および受信者アドレスを 整え、From: や Date のようなメールの規格で要求されるメッセージヘッダを 加え、Bcc: のように現れるべきではないメッセージヘッダを取り除きます。 このドキュメントの後の方で述べるように、 cleanup(8) サーバは複雑なアドレス操作を trivial-rewrite(8) サーバに委任します。
このステージでのアドレス操作:
cleanup(8) デーモンはアドレスマッピング 検索テーブルを走査する前に、初めにアドレスを trivial-rewrite(8) デーモンに送ることによって、標準的な "user@fully.qualified.domain" 形式に 書き換えます。標準形式への書き換えによって検索テーブルに必要なエントリの 数を減らします。
Postfix trivial-rewrite(8) デーモンはハードコードされた次のアドレス操作を実装しています:
- "@hosta,@hostb:user@site" から "user@site" への書き換え
"@hosta,@hostb:user@site" から "user@site" への書き換え これが何だかわからないかもしれませんが、上のアドレス形式はルート アドレスと呼ばれていて、"user@site" 宛のメールが "hosta" と "hostb" を 通って配送されるよう指定しています。この形式の使用は長い間非推奨になって います。Postfix はルート部分を取り除く以外にルートアドレスを扱う ことはできません。
注意: Postfixバージョン2.2以降では、クライアントが local_header_rewrite_clients パラメータにマッチするか、remote_header_rewrite_domain 設定パラメータに空でない値が指定されている場合に限り、リモートの SMTPクライアントからのメッセージヘッダを書き換えます。Postfix 2.2以前の 動作を求めるのであれば、"local_header_rewrite_clients = static:all" を 指定します。
- "site!user" から "user@site" への書き換え
この機能はブール値の swap_bangpath パラメータ (デフォルト: yes) で制御されます。UUCP 形式のアドレスを ドメイン形式に書き換えることが目的です。UUCP を通してメールを 受け取る場合にのみ有用ですが、受け取らない場合でも特に問題はないでしょう。
注意: Postfixバージョン2.2以降では、クライアントが local_header_rewrite_clients パラメータにマッチするか、remote_header_rewrite_domain 設定パラメータに空でない値が指定されている場合に限り、リモートの SMTPクライアントからのメッセージヘッダを書き換えます。Postfix 2.2以前の 動作を求めるのであれば、"local_header_rewrite_clients = static:all" を 指定します。
- "user%domain" から "user@domain" への書き換え
この機能はブール値の allow_percent_hack パラメータ (デフォルト: yes) で制御されます。典型的には、これは "user%domain@otherdomain" のような怪物を扱うために使われます。
注意: Postfixバージョン2.2以降では、クライアントが local_header_rewrite_clients パラメータにマッチするか、remote_header_rewrite_domain 設定パラメータに空でない値が指定されている場合に限り、リモートの SMTPクライアントからのメッセージヘッダを書き換えます。Postfix 2.2以前の 動作を求めるのであれば、"local_header_rewrite_clients = static:all" を 指定します。
- "user" から "user@$myorigin" への書き換え
この機能はブール値の append_at_myorigin パラメータ (デフォルト: yes) で制御されます。多くの Postfix コンポーネントは全てのアドレスが "user@domain" 形式であることを 期待しているので、この機能を無効にすべきではありません。
注意: Postfixバージョン2.2以降では、クライアントが local_header_rewrite_clients パラメータにマッチするか、remote_header_rewrite_domain 設定パラメータに空でない値が指定されている場合に限り、リモートの SMTPクライアントからのメッセージヘッダを書き換えます。Postfix 2.2以前の 動作を求めるのであれば、"local_header_rewrite_clients = static:all" を 指定します。
あなたのマシンが $myorigin のメインマシンではなく、ユーザの一部をメインマシンを通さずにローカルに 配送したいのであれば、"user@$myorigin" を "user@$myhostname" に向け直す ような バーチャル エイリアス テーブルのエントリを 作ってください。 STANDARD_CONFIGURATION_README ドキュメントの "一部ユーザのローカルへの配送" も参照してください。
- "user@host" から "user@host.$mydomain" への書き換え
この機能はブール値の append_dot_mydomain パラメータ (デフォルト: yes) で制御されます。同じホスト名の異なる形式を 一貫して扱うことが目的です。
注意: Postfixバージョン2.2以降では、クライアントが local_header_rewrite_clients パラメータにマッチするか、remote_header_rewrite_domain 設定パラメータに空でない値が指定されている場合に限り、リモートの SMTPクライアントからのメッセージヘッダを書き換えます。Postfix 2.2以前の 動作を求めるのであれば、"local_header_rewrite_clients = static:all" を 指定します。
"host" を "host.domain" に書き換えるのは問題があるとする議論もあります。 そのため、これは無効にすることもできます。Postfix自身のドメイン が自動的に付けられる利便性が好きな人もいるでしょう。
- "user@site." から "user@site" (最後のドットを削る) への書き換え
最後についた1つだけのドットは静かに削られます。しかし複数のドットで 終わるアドレスは無効なアドレスとして拒否されます。
注意: Postfixバージョン2.2以降では、クライアントが local_header_rewrite_clients パラメータにマッチするか、remote_header_rewrite_domain 設定パラメータに空でない値が指定されている場合に限り、リモートの SMTPクライアントからのメッセージヘッダを書き換えます。Postfix 2.2以前の 動作を求めるのであれば、"local_header_rewrite_clients = static:all" を 指定します。
cleanup(8) デーモンはメッセージ エンベロープやメッセージヘッダに現れるアドレスを書き換えるために canonical(5) テーブルを使います。 デフォルトでは、すべてのヘッダとエンベロープのアドレスが書き換えられます; これは canonical_classes 設定パラメータで制御できます。
注意: Postfixバージョン2.2以降では、クライアントが local_header_rewrite_clients パラメータにマッチするか、remote_header_rewrite_domain 設定パラメータに空でない値が指定されている場合に限り、リモートの SMTPクライアントからのメッセージヘッダを書き換えます。Postfix 2.2以前の 動作を求めるのであれば、"local_header_rewrite_clients = static:all" を 指定します。
アドレス書き換えはローカルおよびリモートアドレスに対してなされます。 このマッピングはログイン名を "Firstname.Lastname" 形式のアドレスで 置き換えたり、古いメールシステムが生成したメールアドレスの無効な ドメインを整えるのに便利です。カノニカルマッピングはデフォルトで無効になっています。有効にするには、 main.cf ファイルの canonical_maps パラメータを編集して一つ以上の検索テーブルを空白またはカンマで区切って 指定します。
例:
/etc/postfix/main.cf:
canonical_maps = hash:/etc/postfix/canonical
/etc/postfix/canonical:
wietse Wietse.Venema
上で示したようなスタティックマッピングでは、hash: や ldap:、 mysql:、 pgsql: のような検索テーブルが適して います。ダイナミックなマッピングでは、正規表現テーブルが使えます。 それには regexp_table(5) や pcre_table(5)、 canonical(5) にあるような概念にかなり 詳しくなる必要があります。
送信者および受信者アドレスに適用されるカノニカルマップに加えて、送信者 アドレスまたは受信者アドレスだけに適用されるカノニカルマップを指定することも できます。
例:
/etc/postfix/main.cf:
sender_canonical_maps = hash:/etc/postfix/sender_canonical
recipient_canonical_maps = hash:/etc/postfix/recipient_canonical
送信者および受信者カノニカルマップは共通のカノニカルマップの前に 適用されます。sender_canonical_classes および recipient_canonical_classes パラメータはそれぞれ sender_canonical_maps や recipient_canonical_maps を受ける アドレスを制御します。
送信者に限定した書き換えは、醜い送信者アドレスをきれいなものに 書き換えたいが、メーラループを起こさずにこれらの醜いアドレスにもメールを 送れるままにしたい場合に便利です。
master.cf の設定で main.cf の設定を上書きすることで、カノニカルマップは smtpd(8) や qmqpd(8)、 pickup(8) で受信したメールを選択的に無効に することができます。この機能は Postfix バージョン 2.1 以降で使えます。
例:
/etc/postfix/master.cf:
:10026 inet n - n - - smtpd
-o receive_override_options=no_address_mappings
注意: "=" の前後に空白を置いてはいけません。
アドレスマスカレードはメールゲートウェイの後ろにあるドメイン内のホストを 隠し、個々のマシンではなく、あたかもメールがゲートウェイ自身から来たように 見せるための手法です。
注意: Postfixバージョン2.2以降では、クライアントが local_header_rewrite_clients パラメータにマッチするか、remote_header_rewrite_domain 設定パラメータに空でない値が指定されている場合に限り、リモートの SMTPクライアントからのメッセージヘッダを書き換えます。Postfix 2.2以前の 動作を求めるのであれば、"local_header_rewrite_clients = static:all" を 指定します。
アドレスマスカレードはデフォルトで無効になっており、 cleanup(8) サーバによって実装されています。 有効にするには、main.cf ファイルの masquerade_domains パラメータを編集して、一つ以上のドメイン名を空白またはカンマで区切って 指定します。Postfix がドメインをマスカレードしようとする際、リストを 左から右へと処理し、最初にマッチしたところで処理を止めます。
例:
/etc/postfix/main.cf:
masquerade_domains = foo.example.com example.com
は "any.thing.foo.example.com" を "foo.example.com" へと削りますが、 "any.thing.else.example.com" を "example.com" へとは削りません。
ドメイン名の前に "!" が付けられると、このドメインまたはその サブドメインはマスカレードしないことを意味します:
/etc/postfix/main.cf:
masquerade_domains = !foo.example.com example.com
は "any.thing.foo.example.com" や "foo.example.com" を変えませんが、 "any.thing.else.example.com" を "example.com" へと削ります。
masquerade_exceptions 設定パラメータにはアドレスマスカレードを受けないユーザ名を指定します。 一つ以上のユーザ名を空白またはカンマで区切って指定してください。
例:
/etc/postfix/main.cf:
masquerade_exceptions = root
デフォルトでは、Postfix は例外を作りません。
微妙な点: デフォルトでは、アドレスマスカレードはメッセージヘッダおよび エンベロープ送信者アドレスのみに適用されますが、エンベロープ受信者には 適用されません。これによりアドレスマスカレードをメールゲートウェイマシンで 使えるようにしていますが、外部から個々のマシンのユーザへはメールを転送 できるままになっています。
エンベロープ受信者アドレスもマスカレードを受けさせるには、次のように 指定します (Postfix バージョン 1.1 以降):
/etc/postfix/main.cf:
masquerade_classes = envelope_sender, envelope_recipient,
header_sender, header_recipient
このようにエンベロープ受信者を書き換えると、Postfix は個々のマシンにメールを 送ることができなくなります。
master.cf の設定で main.cf の設定を上書きすることで、アドレス マスカレードは smtpd(8) や qmqpd(8)、 pickup(8) で受信したメールを選択的に無効に することができます。この機能は Postfix バージョン 2.1 以降で使えます。
例:
/etc/postfix/master.cf:
:10026 inet n - n - - smtpd
-o receive_override_options=no_address_mappings
注意: "=" の前後に空白を置いてはいけません。
カノニカルおよびマスカレードマッピングの適用後、 cleanup(8) デーモンはオプションで BCC (blind carbon-copy) 受信者を生成することができます。 Postfix は3つの メカニズムを提供します:
- always_bcc = address
- 全てのメールのコピーを指定されたアドレスに配送します。Postfix バージョン 2.1 以前では、この機能は smtpd(8) や qmqpd(8)、pickup(8) によって実装されていました。
- sender_bcc_maps = type:table
- エンベロープ送信者アドレスを持つ、指定された "type:table" 検索テーブルで自動 BCC アドレスを探します。この機能は Postfix 2.1 以降で使えます。
- recipient_bcc_maps = type:table
- エンベロープ受信者アドレスを持つ、指定された "type:table" 検索テーブルで自動 BCC アドレスを探します。この機能は Postfix 2.1 以降で使えます。
注意: 自動 BCC 受信者は新しいメールに対してのみ生成されます。メーラ ループを防ぐため、自動 BCC 受信者は Postfix が内部で転送するメールや Postfix 自身が生成するメールに対しては作られません。
master.cf の設定で main.cf の設定を上書きすることで、自動 BCC 受信者 (always_bcc を含む) は smtpd(8) や qmqpd(8)、 pickup(8) で受信したメールを選択的に無効に することができます。この機能は Postfix バージョン 2.1 以降で使えます。
例:
/etc/postfix/master.cf:
:10026 inet n - n - - smtpd
-o receive_override_options=no_address_mappings
注意: "=" の前後に空白を置いてはいけません。
受信者をキューファイルに書く前に、cleanup(8) デーモンは受信者宛のメールを向け直すためにオプションの virtual(5) エイリアステーブルを使います。 マッピングはエンベロープ受信者のみに影響します; メッセージヘッダや エンベロープ送信者アドレスには影響しません。バーチャルエイリアス検索は バーチャルエイリアス ドメイン 宛のメールを実在するユーザのメールボックスに向け直したり、 存在しないドメイン宛のメールを向け直すのに便利です。バーチャルエイリアス 検索は " Firstname.Lastname " を UNIX ログイン名に戻すのにも使えますが、 ローカル エイリアス の方がより適切な手段でしょう。 Postfix でバーチャルドメインをホスティングする方法の概要については、 VIRTUAL_README ドキュメントを参照して ください。
バーチャルエイリアスはデフォルトで無効になっています。有効にするには、 main.cf ファイルの virtual_alias_maps パラメータを編集して一つ以上の検索テーブルを空白またはカンマで区切って 指定してください。
例:
/etc/postfix/main.cf:
virtual_alias_maps = hash:/etc/postfix/virtual
/etc/postfix/virtual:
Wietse.Venema wietse
バーチャルエイリアスマップで見つかったアドレスは繰り返し他のバーチャル エイリアスを適用されますが、ループを避けるため、カノニカルマッピングの適用は 受けません。
上で示したようなスタティックマッピングでは、hash: や ldap:、 mysql:、 pgsql: のような検索テーブルが適して います。ダイナミックなマッピングでは、正規表現テーブルが使えます。それには can use regular expression tables. This requires that you become regexp_table(5) や pcre_table(5)、 virtual(5) にあるような概念にかなり詳しく なる必要があります。
注意: 自動 BCC 受信者は新しいメールに対してのみ生成されます。メーラ ループを防ぐため、自動 BCC 受信者は Postfix が内部で転送するメールや Postfix 自身が生成するメールに対しては作られません。
master.cf の設定で main.cf の設定を上書きすることで、バーチャルエイリアスは smtpd(8) や qmqpd(8)、 pickup(8) で受信したメールを選択的に無効に することができます。この機能は Postfix バージョン 2.1 以降で使えます。
例:
/etc/postfix/master.cf:
:10026 inet n - n - - smtpd
-o receive_override_options=no_address_mappings
注意: "=" の前後に空白を置いてはいけません。
この時点でメッセージは Postfix incoming キュー に格納する 準備ができます。
Postfix キューマネージャは配送先でメールをソートし、それを local(8) や smtp(8)、 lmtp(8) のような Postfix 配送エージェントに渡します。 cleanup(8) サーバと同様に、Postfix キュー マネージャは複雑なアドレス操作を trivial-rewrite(8) サーバに委任します。
このステージでのアドレス操作:
それぞれの Postfix 配送エージェントはメールをその配送先に配送しようとし、 さらに SMTP や LMTP などのプロトコルのルールに従って送信者や受信者、 メッセージの中身をカプセル化します。メールが配送できない場合は、送信者に 返されるか deferred キュー に移動されて後で再び試行されます。
smtp(8) 配送エージェントでメールが配送される際のアドレス操作:
local(8) 配送エージェントでメールが配送 される際のアドレス操作:
このドキュメントの残りの部分では、特定の例や例のあるドキュメントへの ポインタとともに、それぞれのアドレス操作のステップをより詳細に示します。
Postfix qmgr(8) キューマネージャは incoming キュー から新しい メールを、または deferred キュー から古い メールを選び、 trivial-rewrite(8) アドレス書き換え および解決デーモンに配送すべき場所を尋ねます。
バージョン 2.0 の時点で、Postfix は4つの主なアドレスクラスを区別します。 それぞれのクラスにドメイン名のリストがあり、以下の表で示されるような デフォルトの配送方法を持っています。詳細は ADDRESS_CLASS_README ドキュメントを 参照してください。Postfix バージョン 2.0 以前ではローカル配送とそれ以外 全てしか区別しません。
配送先ドメインリスト デフォルトの配送方法 利用可能 $mydestination, $inet_interfaces, $proxy_interfaces $local_transport Postfix 1.0 $virtual_mailbox_domains $virtual_transport Postfix 2.0 $relay_domains $relay_transport Postfix 2.0 なし $default_transport Postfix 1.0
trivial-rewrite(8) デーモンが デフォルト配送方法を決定すると、続いてオプションの transport(5) テーブルでメッセージの配送先や 配送方法を上書きする情報を探します。典型的には、インターネットに接続されて いないシステムにメールを送ったり、特別な要求をする配送先に特別な SMTP クライアント設定を使う場合に、transport(5) テーブルが使われます。例えば、 STANDARD_CONFIGURATION_README や UUCP_README ドキュメント、 transport(5) マニュアルページの例を参照して ください。
transport テーブルの検索はデフォルトで無効です。有効にするには、main.cf ファイルの transport_maps パラメータを編集し、一つ以上の検索テーブルを空白またはカンマで区切って 指定してください。
例:
/etc/postfix/main.cf:
transport_maps = hash:/etc/postfix/transport
次に、trivial-rewrite(8) アドレス 書き換えおよび解決デーモンはそれぞれの受信者に対して relocated(5) データベースを参照します。この テーブルはアカウントを持たなくなったユーザへの到達方法や、存在しなくなった ドメイン全体に対するメールの扱い方に関する情報を提供します。このテーブルに リストアップされているアドレスにメールが送られると、そのメールは情報を持つ メッセージとともに送信者に返されます。
ある受信者が異なるもので置き換えられる可能性がある transport(5) テーブルを見越して、 relocated(5) データベースは transport(5) テーブル検索の後で検索されます。
再配置ユーザの検索はデフォルトで無効です。有効にするには、main.cf ファイルの relocated_maps パラメータを編集し、一つ以上の検索テーブルを空白またはカンマで区切って 指定してください。
例:
/etc/postfix/main.cf:
relocated_maps = hash:/etc/postfix/relocated
/etc/postfix/relocated:
username@example.com otheruser@elsewhere.tld
Postfix バージョン 2 の時点では、再配置ユーザに対するメールは "user has moved to otheruser@elsewhere.tld" として、SMTP サーバで拒否されます。 古いバージョンの Postfix はまずメールを受け取り、そして同じ理由で配送 できないとして送信者に返されます。
ホストの中には有効なインターネットドメイン名を持たず、代わりに localdomain.local のような名前を使っているものがあります。無効な ドメイン名を持つメールアドレスを多くのメールサーバが拒否するため、 インターネット越しにメールを送りたいときに問題になるかもしれません。
smtp_generic_maps パラメータを使うと、メールがSMTPを使ってマシンを出て行くときに ローカルメールアドレスを有効なインターネットアドレスで置き換える generic(5) 検索テーブルを指定することができます。 generic(5) マッピングはエンベロープ およびヘッダアドレスを書き換えますが、再帰的にはおこないません。 ローカルマシン上のアドレス間でメールを送る場合には書き換えはなされません。
この機能はPostfixバージョン2.2以降で使えます。
例:
/etc/postfix/main.cf:
smtp_generic_maps = hash:/etc/postfix/generic
/etc/postfix/generic:
his@localdomain.local hisaccount@hisisp.example
her@localdomain.local heraccount@herisp.example
@localdomain.local hisaccount+local@hisisp.example
SMTPでリモートホストにメールが送られるときに、これは his@localdomain.local を彼のISP メールアドレスで置き換え、 her@localdomain.local は彼女のISPメールアドレスで置き換え、 また他のローカルアドレスは彼のISPアカウントに +local という 拡張アドレスが付いたもので置き換えます (この例ではISPが "+" 形式の拡張 アドレスをサポートしていると想定しています)。
ローカルにメールが配送される場合、local(8) 配送エージェントはそれぞれのローカル受信者名に対して aliases(5) データベースを参照します。 マッピングはメッセージヘッダのアドレスには影響しません。ローカル aliases は典型的には、配布リストを実装したり、postmaster のような標準的な エイリアスに対するメールを実在する人に向けたりするのに使われます。 "Firstname.Lastname" アドレスをログイン名にマッピングするのにも使えます。
エイリアス検索はデフォルトで有効です。デフォルトの設定はオペレーティング システム環境に依存しますが、典型的には次のうちのどれかです:
/etc/postfix/main.cf:
alias_maps = hash:/etc/aliases
alias_maps = dbm:/etc/aliases, nis:mail.aliases
エイリアスデータベースファイルのパス名は alias_database 設定パラメータで 制御されます。値はシステム依存です。たいていは次のどれかです:
/etc/postfix/main.cf:
alias_database = hash:/etc/aliases (4.4BSD, LINUX)
alias_database = dbm:/etc/aliases (4.3BSD, SYSV<4)
alias_database = dbm:/etc/mail/aliases (SYSV4)
aliases(5) ファイルはメールのローカル ファイルへの配送や、標準入力ストリームでメッセージを受けるコマンドへの 配送を指定することもできます。セキュリティ上の理由で、コマンドおよび ファイルの配送先へはエイリアスデータベースの所有者権限で配送されます。 "root" が所有するエイリアスでのコマンドやファイルへの配送にはデフォルトの userid、default_privs が 使われます。
local(8) 配送エージェントを使った配送では、 ユーザはそれぞれのホームディレクトリの .forward と呼ばれるファイルで自分の メールの配送先を制御することができます。これらのファイルの文法はエイリアスの 左側 (検索キーとコロン) が現れない以外はローカル aliases(5) ファイルと同じです。
メッセージ受信者が存在しないことが local(8) 配送エージェントにわかると、メッセージは通常送信者に ("user unknown" で) 返されます。存在しない受信者宛のメールは別のマシンに転送する方が望ましい 場合もあります。このような目的では、 luser_relay 設定パラメータで 代わりの配送先を指定することができます。
他にも、存在しない受信者宛のメールを fallback_transport 設定パラメータで指定される、完全に異なるメッセージ配送 transport に 委任することもできます。詳細は local(8) 配送エージェントドキュメントを参照してください。
注意: 非 UNIX アカウント宛のメールを受信するために luser_relay 機能を使う場合、 以下も main.cf ファイルで指定しなけばいけません:
/etc/postfix/main.cf:
local_recipient_maps =
(すなわち空)。そうしないと、Postfix SMTP サーバは非 UNIX アカウント宛の メールを "User unknown in local recipient table" で拒否してしまいます。 これに関する詳細な情報は LOCAL_RECIPIENT_README ファイルを 参照してください。
luser_relay は1つのアドレスを 指定することができます。これは "$name" 展開を受けます。例:
- $user@other.host
拡張アドレスのない裸のユーザ名が "@other.host" に付けられます。 例えば、"username+foo" 宛のメールは "username@other.host" に送られます。
- $local@other.host
拡張アドレスを含む、元の受信者ローカル部分全体が "@other.host" に 付けられます。例えば、"username+foo" 宛のメールは "username+foo@other.host" に 送られます。
- sysadmin+$user
拡張アドレスのない裸のユーザ名が "sysadmin" に付けられます。 例えば、"username+foo" 宛のメールは "sysadmin+username" に送られます。
- sysadmin+$local
拡張アドレスを含む、元の受信者ローカル部分全体が "sysadmin" に 付けられます。例えば、"username+foo" 宛のメールは "sysadmin+username+foo" に 送られます。
Postfix バージョン 2.1 以降では、Postfix にデバッグ用メール配送レポートを 生成させることができます。これらのレポートはアドレス書き換えやエイリアス展開、 転送後の送信者/受信者アドレスを示すだけではなく、メールボックスへの配送や 非 Postfix コマンドへの配送、リモート SMTP サーバの応答なども示します。
Postfix はデバッグ用に2種類のメール配送レポートを生成することが できます:
What-if: 何が起こるかを報告しますが、実際にメールは配送しません。 この動作モードは次のようにして要求します:
$ /usr/sbin/sendmail -bv address... メール配送状態レポートは <your login name> にメールで送られます。
What happened: メールを配送して、リモート SMTP サーバからの応答を含む 成功や失敗を報告します。この動作モードは次のようにして要求します:
$ /usr/sbin/sendmail -v address... メール配送状態レポートは <your login name> にメールで送られます。
これらのレポートには Postfix 配送エージェントが生成した情報が含まれます。 これらはデーモンプロセスとして動き、ユーザとは直接接触を持たないため、 結果はテストメッセージの送信者にメールとして送られます。これらのレポートの 書式は通常の非配送通知と事実上同じ書式です。
例として、以下に "sendmail -bv postfix-users@postfix.org" コマンドで 生成された配送レポートを示します。レポートの最初の部分には人間が読める文章が 含まれます。この場合、メールは mail.cloud9.net を通り、SMTP サーバは "250 Ok" という応答を返しています。それ以外に、レポートはメールボックスへの配送を 示したり、非 Postfix コマンドへの配送を示すかもしれません。
Content-Description: Notification
Content-Type: text/plain
This is the Postfix program at host spike.porcupine.org.
Enclosed is the mail delivery report that you requested.
The Postfix program
<postfix-users@postfix.org>: delivery via mail.cloud9.net[168.100.1.4]: 250 Ok
レポートの2番目の部分はマシンが読める形式で、以下の情報を含んでいます:
Postfix が DSN (delivery status notification, 配送状態通知) の標準を 実装するために、細かい点はまだ仮のもので変更される予定です。
Content-Description: Delivery report Content-Type: message/delivery-status Reporting-MTA: dns; spike.porcupine.org X-Postfix-Queue-ID: 84863BC0E5 X-Postfix-Sender: rfc822; wietse@porcupine.org Arrival-Date: Tue, 13 Apr 2004 19:27:43 -0400 (EDT) Final-Recipient: rfc822; postfix-users@postfix.org Action: deliverable Status: 2.0.0 Diagnostic-Code: X-Postfix; delivery via mail.cloud9.net[168.100.1.4]: 250 Ok
レポートの3番目の部分には Postfix が配送しようとした From: および To: メッセージヘッダを持つメッセージが含まれるので、これらに対するアドレス 書き換えの効果がわかります。"sendmail -bv" によるメール投函には本文を 持たないため、以下の例では何も現れません。
Content-Description: Message
Content-Type: message/rfc822
Received: by spike.porcupine.org (Postfix, from userid 1001)
id 84863BC0E5; Tue, 13 Apr 2004 19:27:43 -0400 (EDT)
Subject: probe
To: postfix-users@postfix.org
Message-Id: <20040413232743.84863BC0E5@spike.porcupine.org>
Date: Tue, 13 Apr 2004 19:27:43 -0400 (EDT)
From: wietse@porcupine.org (Wietse Venema)