Postfix はアクセス制御やアドレス書き換え、コンテンツフィルタリングの ための情報を保存したり検索するために検索テーブルを使います。全ての Postfix 検索テーブルは"type:table" として指定されます。ここで "type" はこのドキュメントの最後にある "Postfix 検索テーブルの種類" に書かれたデータベースの 種類のうち1つで、"table" は検索テーブル名です。Postfix のドキュメントでは "データベース" と "検索テーブル" という用語は同じものに対して使います。
Postfix ドキュメントによく出てくる検索テーブルの例:
/etc/postfix/main.cf: alias_maps = hash:/etc/postfix/aliases (ローカルエイリアシング) header_checks = regexp:/etc/postfix/header_checks (コンテンツフィルタリング) transport_maps = hash:/etc/postfix/transport (ルーティングテーブル) virtual_alias_maps = hash:/etc/postfix/virtual (アドレス書き換え)
全ての Postfix 検索テーブルは情報を (キー、値) のペアとして保存します。 このインターフェースは最初は単純すぎるものと思われましたが、非常に強力で あることがわかりました。(キー、値) 問い合わせインターフェースは LDAP や SQL の複雑さを Postfix から完全に隠します。これは単純なインターフェースで 複雑なシステムに接続する例です。
Postfix (キー、値) 問い合わせインターフェースの利点:
ほとんどの Postfix 検索テーブルは情報を検索するのに使われます。 アドレス書き換え (検索文字列は古いアドレスで、結果は新しいアドレス) や アクセス制御 (検索文字列はクライアントや送信者、受信者で、結果は "reject" のようなアクション) がその例です。
しかしいくつかのテーブルでは、Postfix は検索キーが存在するかだけを 知る必要があります。Postfix がネットワークからメールを受け取るローカル 受信者を決める local_recipient_maps や Postfix がローカルに配送するドメインを指定する mydestination パラメータ、信頼するクライアントやクライアントネットワークの IP アドレスを 指定する mynetworks パラメータが その例です。技術的には、これらはリストでありテーブルではありません。 その違いにもかかわらず、基礎となる構造が Postfix 検索テーブルと同じで あるため、Postfix リストはここで記述されます。
LDAP や SQL は複雑なシステムです。同時に Postfix と LDAP や SQL を セットアップ使用とするのは全くよい考えではありません。まず Postfix を Berkeley DB のようなローカルファイルで実装することでかなりの時間を 節約することができます。ローカルファイルには意外さはあまりなく、 postmap(1) コマンドで簡単にデバッグすることが できます:
% postmap -q info@example.com hash:/etc/postfix/virtual
ローカルファイルが正しく動いたら、ldap_table(5) や mysql_table(5)、 pgsql_table(5) の指示に従ってローカル ファイル検索を LDAP や SQL 検索で置き換えることができます。それを おこなったら、再び postmap(1) コマンドを 使って、データベース検索がローカルファイル検索と正確に同じ結果を生成するか 確認します:
% postmap -q info@example.com ldap:/etc/postfix/virtual.cf
対応するマニュアルページ: access(5) や canonical(5)、 virtual(5)、 transport(5) または対応する設定パラメータ: mynetworks、 relay_domains、 parent_domain_matches_subdomains の "テーブル検索順序" に書かれている部分アドレスや親ドメインの問い合わせを 必ず全て試してください。
メールシステムが動いているときにデータベースに変更を加える場合には、 情報が変更されている間、Postfix が情報の読み込みを避けることが望ましいです。 Postifx に新しい情報を使わせるための "postfix reload" を実行したりせずに データベースを変更するのもよいことです。"postfix reload" するたびに Postfix はかなりパフォーマンスが落ちます。
LDAP や NIS、SQL のようなネットワークデータベースを変更した場合、 "postfix reload" を実行する必要はありません。LDAP や NIS、SQL サーバは 読み込み/書き込みアクセスの衝突を管理し、新しいデータが使えるようになると それを Postfix に渡します。
regexp: または pcre: ファイルを更新した場合、Postfix は 即座にファイルの変更を取得するかもしれませんししないかもしれません。 これは Postfix プロセスが一度ファイル全体をメモリに読み込み、再び ファイルを調べないためです。
smtpd(8) や cleanup(8)、local(8) のような短命のプロセスによってファイルが使われる場合、変更を加えた後で "postfix reload" を実行する必要はありません。
忙しいサーバの trivial-rewrite(8) のように長く走るプロセスによってファイルが使われる場合、"postfix reload" を 実行する必要があるかもしれません。
DBM や Berkeley DB のようなローカルファイルベースのデータベースを 変更した場合、"postfix reload" を実行する必要はありません。Postfix は 読み込み/書き込みアクセスの衝突を避けるためにファイルロッキングを使い、 Postfix デーモンプロセスがファイルの変更に気づくと、次のクライアント 要求を扱う前に終了します。その結果、新しいプロセスが新しいデータベースで 初期化することができます。
Postfix は Berkeley DB や他のローカルデータベースファイルの更新中、 アクセスの衝突を避けるためにファイルロッキングを使いますが、 ディスクフルや何か他のことがおこって更新に失敗した場合には問題が 起こります。これは postmap(1) や postalias(1) のようなコマンドが存在する ファイルを上書きするためです。途中で更新に失敗すると、利用可能な データベースがなくなり、Postfix は動くのを止めます。Postfix 2.2以降で使える CDB データベースの再構築はアトミックであるため、 CDB データベース形式ではこの問題は起きません。
DBM のような複数ファイルのデータベースでは、簡単な解決策はありません。 Berkeley DB やその他の "1ファイル" データベースでは、上書きする代わりに 存在するデータベースファイルを置き換えるのに "mv" を使うことで、 いくらか堅牢性を上げることができます:
# postmap access.in && mv access.in.db access.db
これは入力ファイル "access.in" を出力ファイル "access.in.db" に変換し、 postmap(1) コマンドが成功した場合にのみその ファイルを "access.db" に置き換えます。もちろんそのようなコマンドを 打つのはすぐに飽きるますが、それが以下に示すような "make" を代わりに 使う理由です。ユーザの入力は太字で示されます。
# cat Makefile all: aliases.db access.db virtual.db ...etcetera... # Note 1: commands are specified after a TAB character. # Note 2: use postalias(1) for local aliases, postmap(1) for the rest. aliases.db: aliases.in postalias aliases.in mv aliases.in.db aliases.db access.db: access.in postmap access.in mv access.in.db access.db virtual.db: virtual.in postmap virtual.in mv virtual.in.db virtual.db ...etcetera... # vi access.in ...editing session not shown... # make postmap access.in mv access.in.db access.db #
"make" コマンドは変更されたファイルのみを更新します。エラーの場合、 "make" コマンドは止まって "mv" コマンドを呼び出さないので、Postfix は 何も起こらなかったように存在するデータベースファイルを使い続けます。
あなたの Postfix システムがサポートしているデータベースの種類を知るには、 "postconf -m" コマンドを使ってください。これはよくサポートされるデータベース 種類のリストです:
- btree
- ソートされたバランス木構造。これは Berkeley DB データベースをサポート したシステムでのみ使えます。データベースファイルは postmap(1) または postalias(1)コマンドで作られます。 "btree:table" で使われる検索テーブル名はデータベースファイル名から ".db" サフィックスを取ったものです。
- cdb
- 増分更新をサポートしない、読み込みに最適化した構造。データベース ファイルは postmap(1) または postalias(1) コマンドで作成されます。 "cdb:table" で使われる検索テーブル名はデータベースファイル名から ".cdb" サフィックスを取ったものです。この機能はPostfix 2.2以降で使えます。
- cidr
- 値が Classless Inter-Domain Routing (CIDR) パターンに関連付いている テーブル。テーブルの書式は cidr_table(5) に記述されています。
- dbm
- ハッシュに基づいてインデックス化されたファイル形式。これは DBM データベースをサポートしたシステムでのみ使えます。データベースファイルは postmap(1) または postalias(1) コマンドで作られます。 "dbm:table" で使われる検索テーブル名はデータベースファイル名から ".dir" または ".pag" サフィックスを取ったものです。
- environ
- UNIX プロセス環境配列。検索キーは変数名です。"environ:table" の 検索テーブル名は無視されます。
- hash
- ハッシュに基づいてインデックス化されたファイル形式。これは Berkeley DB データベースをサポートしたシステムでのみ使えます。データベースファイルは postmap(1) または postalias(1) コマンドで作られます。 "hash:table" で使われる検索テーブル名はデータベースファイル名から ".db" サフィックスを取ったものです。
- ldap (read-only)
- LDAP プロトコルを使った検索をおこないます。設定の詳細は ldap_table(5) に書かれています。
- mysql (read-only)
- MySQL データベース検索をおこないます。設定の詳細は mysql_table(5) に書かれています。
- netinfo (read-only)
- Netinfo データベース検索をおこないます。
- nis (read-only)
- NIS データベース検索をおこないます。
- nisplus (read-only)
- NIS+ データベース検索をおこないます。設定の詳細は nisplus_table(5) に あります。
- pcre (read-only)
- Perl 互換正規表現に基づく検索テーブル。ファイルの書式は pcre_table(5) に記述されています。 "pcre:table" で使われる検索テーブル名は 正規表現ファイルの名前です。
- pgsql (read-only)
- PostgreSQL データベース検索をおこないます。設定の詳細は pgsql_table(5) に書かれています。
- proxy (read-only)
- Postfix proxymap(8) サービスを使って 情報にアクセスします。検索テーブル名の文法は "proxy:type:table" です。
- regexp (read-only)
- 正規表現に基づく検索テーブル。ファイルの書式は regexp_table(5) に記述されています。 "regexp:table" で使われる検索テーブル名は 正規表現ファイルの名前です。
- sdbm
- ハッシュをベースにしたインデックス化したファイル種。これは SDBM データベースをサポートしたシステムでのみ使えます。データベースファイルは postmap(1) または postalias(1) コマンドで作られます。"sdbm:table" で 使われる検索テーブル名はデータベースファイル名から ".dir" または ".pag" サフィックスを取ったものです。
- static (read-only)
- 検索結果として常に検索テーブル名を返します。例えば、検索テーブル "static:foobar" は常に検索結果として "foobar" を返します。
- tcp
- TCP/IP サーバを使って情報にアクセスします。プロトコルは tcp_table(5) に 記述されています。検索テーブル名は "tcp:host:port" で、"host" には ホストのシンボル名または数値の IP アドレスを、"port" にはサービスの シンボル名または数値のポート番号を指定します。このプロトコルはPostfix 2.2を含めたそれ以前のバージョンでは使えません。
- unix (read-only)
- UNIX 認証データベースに問い合わせる制限された方法。以下のテーブルが 実装されています:
- unix:passwd.byname
- テーブルは UNIX パスワードデータベースです。キーはログイン名です。 結果は passwd(5) 形式のパスワードファイルのエントリです。
- unix:group.byname
- テーブルは UNIX グループデータベースです。キーはグループ名です。 結果は group(5) 形式のグループファイルのエントリです。
他の検索テーブルの種類も Postfix の構築方法によっては使えるかもしれません。 Postfix 配布物の中には、検索テーブルのサポートが動的に Postfix にリンクされる ため、リストが動的に拡張できるものもあります。