Postfix Frequently Asked Questions

(リンクが一部切れているものもありますが、あしからず御了承ください)
Up one level | Postfix FAQ

目次

設定例

Sendmail との非互換性

メールの中継

リモート配送

ローカル (非バーチャル) 配送

メーリングリスト

バーチャルドメイン

アドレスの書き換え

コンテンツフィルタリング

他の配送方法: UUCP, FAX, etc.

Postfix のコンパイルとインストール

スタンドアロンマシン

インターネットに直接アクセスできるスタンドアロンマシンでは、Postfix は設定の変更なしに動くでしょう。少なくとも、それが Postfix のソース コードをダウンロードした時に、インストールされる状態です。マシンが ファイアウォールのあるイントラネット内にあったり、短時間ダイアル アップで接続されるのであれば、関連するセクションを参照して下さい。

ワークステーションとサーバ

このセクションは、ワークステーション・サーバ環境について記載します。 全てのシステムはメールを user@domain として送信します。全てのシステム は user@hostname 宛のメールを受け取ります。サーバは user@domain 宛の メールも受け取ります。

Postfix は全てのパラメータがまともなデフォルト値を持つため、ここ では上書きする物のみを示します。特に、Postfix は自分と同じドメイン (とサブドメイン)のクライアントとそのクラス A, B, または C ネット ワークへのメールのみを中継します。とても遅い/速いネット/ マシンが あれば、 master.cf (inetd.conf といくぶん似ています) をチューン する必要があります。

ワークステーション: 

    /etc/postfix/main.cf:
        myorigin = $mydomain

サーバ: 

    /etc/postfix/main.cf:
        myorigin = $mydomain
        mydestination = $myhostname, localhost.$mydomain, $mydomain

このような環境で、メールスプールディレクトリが NFS で共有されているか ユーザがメールボックスに POP でアクセスするか、ユーザが自分のワーク ステーションでメールを受けるかのどれかでしょう。後者の場合、それぞれ のユーザはメールをそれぞれのワークステーションに転送するようにサーバに エイリアスを持ちます:

Server: 

    /etc/aliases:
        joe:    joe@joes.workstation
        jane:   jane@janes.workstation

エイリアスデータベースが /etc/aliases にないシステムもあります。 あなたのシステムでの場所を探すには、postconf alias_maps コマンドを実行します。

Null クライアント

Null クライアントはメールの送信のみできるマシンです。ネットワーク からはメールを受け取らず、ローカルへの配送も全くおこないません。 Null クライアントでは、メールボックスへのアクセスは典型的には POP または NFS を使います。

次の例では、メールは user@domain として送信され、全てのメールは ローカルドメインを受け持つメールサーバに転送されます。 

    /etc/postfix/main.cf:
        myorigin = $mydomain
        relayhost = $mydomain

    /etc/postfix/master.cf:
        Comment out the SMTP server entry
        Comment out the local delivery agent entry

メールは全て user@nullclient ではなく user@domain として送信される ため、user@nullclient 宛のメールアドレスに対するメールサーバの特別な 設定は必要ありません。

イントラネットでの Postfix の利用

 ファイアウォール内のネットワークのホストで Postfix を設定する最も 簡単な方法は、全てのメールをイントラネットメールゲートウェイに 送り、メールゲートウェイが転送に気をつけるようにするものです。

ファイアウォール上での Postfix の利用

 注意: この文章は Postfix のバージョンの日付が 19991115 と それ以降でのみ使えます。Postfix のバージョンを調べるには、 postconf mail_version コマンドを実行します。

ファイアウォールマシン上の Postfix を、my.domain 宛のメールを 内部のゲートウェイマシンに転送し、*.my.domain 宛のメールを 拒否するように設定する方法は？　問題は標準の relay_domains メール中継制限では my.domain を指定すると *.my.domain へのメールも 許してしまうことです。

ダイアルアップマシンでの Postfix の利用

 このセクションは多くの時間接続が切れているダイアルアップ接続に 当てはまります。常時接続のダイアルアップ接続は、代わりに ワークステーションとサーバ セクションを 見てください。

自分自身のホスト名を持っておらず (動的 IP 割り当て)、必ず user@your-isp.com としてメールを送るのであれば、次のセクションの user@domain としてメールを送る際に、 あるユーザはローカルに配送したい も検討すべきです。

Postfix で "sendmail -v" コマンドが使えません

 sendmail -v が実際のメール配送をしないと苦情をいう人が いるかも知れません。

Postfix のような分散されたメールシステムでは、実装するのは困難です。 Sendmail とは違い、Postfix のメール配送プロセスはどれもユーザによる 制御下では動きません。代わりに Postfix はユーザプロセスに親子関係の ないデーモンプロセスがメールを配送します。これは非常にさまざまな、 環境変数やシグナルハンドラ、その他 UNIX の親プロセスから子プロセスへ 渡すプロセスの性質による、潜在的セキュリティ問題をなくします。

Postfix はお互いにサブシステムを隔離するために複数のプロセスを 使います。配送エージェントがユーザプロセスと直接やりとりするのは Postfix を普通のメーラよりも安全にしようとしてきた努力をふいにして しまいます。

Postfix が "delayed mail" 警告を送りません

Sendmail を使っていた時は、4時間後にメールの配送が遅れているというメールが 常に送信者に戻ってきました。

Postfix が "delayed mail" 通知を4時間後に送るようにするには、次のように 指定します: 

    /etc/postfix/main.cf:
	delay_warning_time = 4

Postfix ではメールの遅延通知はデフォルトではおこないません - 常に大量のメールを受け取ることになってしまうので。

Postfix がメールを複製します

 Postfix がメッセージを複製してしまうことに苦情をいう人がいるかも しれません。これはあるメッセージが同じユーザに届く複数のアドレスに 送られると常におこります。例えばこのような場合です:

これが「正しい」動作であるということを主張さえする人もいるでしょう。 おそらくむしろ期待や慣れの問題でしょう。

これは Postfix を遅くすることでのみ「修正できます」。上の例では、 Postfix は配送を始める前に、まず完全に全ての配送リストを展開する必要が あります。設計では Postfix は異なる配送先へのメールは並列に配送し、 ローカルも例外ではありません。これが Postfix が sendmail よりも速い理由です。

Postfix が配送リストの全てのメンバーにメールを送信します

 Postfix が送信者も含めた配送リストの全てのメンバにメールを送信することに 苦情をいう人もいるでしょう。デフォルトでは sendmail は送信者を配送リストから 削除します。Sendmail は "metoo" フラグが明示的にオンになっている時のみ 送信者にメールを送ります。

Wietse は Postfix の実装が「正しい」動作だと信じており、sendmail の デフォルトの動作は sendmail がエイリアスループを避けるのにかなり みすぼらしいアルゴリズムを使っていた時の暗い部分の名残ではないかと 疑っています。

助けて！ Postfix がオープンリレーになった

あるリレーチェックソフトによると、Postfix が任意の非ローカル配送先 宛のメールを受け入れています。 

    >>> MAIL FROM:<someone@some.where>
    <<< 250 Ok
    >>> RCPT TO:<test@some.other.site@some.site>
    <<< 250 Ok
    >>> DATA
    <<< 354 End data with <CR><LF>.<CR><LF>
    >>> (message body)
    <<< 250 Ok: queued as A958F5A15

慌ててはいけません！ Postfix のバージョン 19991227 またはそれ以降に 更新して下さい。使っている Postfix のバージョンを知るには、 postconf mail_version コマンドを実行します。

それ以前のバージョンの Postfix では、

  1. 良いが混乱を招く: some.site のプライマリ MX ホストの Postfix は test@some.other.site@some.site を受け入れてから、 test@some.other.site を知らないローカルのユーザ名としてバウンス します。
  2. 良い: some.site のプライマリ MX ホストの Postfix はその他の test%some.other.site@some.site や some.other.site!test@some.site のようなソースルートアドレスを拒否します。
  3. ループホール: some.site のバックアップ MX ホストの Postfix は test@some.other.site@some.site や test%some.other.site@some.site のようなソースルートアドレスを some.site のプライマリ MX ホストに 転送します。プライマリ MX ホストのメーラの設定によっては、プライマリ MX ホストがインターネットにメールをスパムするかも知れません。

Postfix の新しいバージョンでは、

  1. some.site のプライマリ MX ホストの Postfix は test@some.other.site@some.site を test%some.other.site@some.site と同様に拒否します。これは上の 1 で述べた混乱を終わらせます。
  2. some.site のバックアップ MX ホストの Postfix は test@some.other.site@some.site を含むソースルートアドレスを拒否 します。これは上の 3 で述べたループホールを閉じます。

正確には、Postfix の UCE 制限が次の条件下でソースルートアドレスの 転送を拒否します:

しかし、プライマリ MX ホストの Postfix は今でも、信頼するクライアント から受け取った物であれば以前と同様にソースルートアドレスを転送します。

信頼する SMTP クライアントを通したソースルートリレーに対する保護を保証 したいのであれば、正規表現制限を他の SMTPD 受信者制限に先だって指定 します: 

    /etc/postfix/main.cf:
        smtpd_recipient_restrictions = 
	    regexp:/etc/postfix/regexp_access
	    ...other restrictions...

    /etc/postfix/regexp_access:
        /[%!@].*[%!@]/ 550 Sender specified routing is not supported here.

これを全ての MX ホストに導入します。

モバイルユーザ宛のメールの中継をしたい

あるマシンで Postfix をセットアップしましたが、これを通して メールを中継できるインターネットユーザのグループを選びたいのです。 IP アドレス (すなわち 動的 IP の人々の 256 ブロック) またはホスト名 (whatever.dialup.isp.com) のどちらかを中継のベースにしたいです。

最も好ましい方法は、ユーザに古いプレーン SMTP ではなく、ある認証 プロトコルを通してメールを送信してもらうことです。

次に良い方法は古いプレーン SMTP を使い、例えば "please login via POP before using SMTP" スキームでユーザを先に認証する方法です。 この場合、DRAC のような Postfix ではないソフトウェアがクライアントの IP アドレス 情報を持つ Postfix 互換のアクセステーブルを保守します: 

    /etc/postfix/main.cf:
        smtpd_recipient_restrictions =
            permit_mynetworks
            check_client_access hash:/etc/postfix/client_access
            check_relay_domains

    /etc/postfix/client_access:
        4.3.2.1         OK
        5.4.3.2         987654321

システムが db ファイルの代わりに dbm ファイルを 使っているのであれば、hash の代わりに dbm を指定します。 Postfix がどのマップタイプをサポートしているかを知るには、 postconf -m コマンドを使います。

あまり好ましくない方法は、クライアントの IP アドレス (例えば、 256 ブロック) や DNS ホスト名 (例えば whatever.pop.isp.com) に基づく ものです。IP/DNS ベースのリレーアクセス制御を使うのであれば、同じ ISP の顧客が誰もあなたのマシンにスパムを向けないことを祈りなさい。 そうでなければ、あなたはインターネットワイドのブラックリストに名前を 連ねるでしょう。

最も好ましくないのは送信者アドレスに基づく方法です。あなたの サイトからメールを受け取ったことがある人がだますのは、つまらないほど 簡単です。もし送信者アドレスアクセス制御を使っていれば、あなたの ユーザのアドレスをスパマーが見つけないことを祈りなさい。 

    /etc/postfix/main.cf:
        smtpd_recipient_restrictions =
            permit_mynetworks
            check_client_access hash:/etc/postfix/client_access
            check_sender_access hash:/etc/postfix/sender_access
            check_relay_domains

    /etc/postfix/client_access:
        11.22.33                OK
        dialup.isp.com          OK

    /etc/postfix/sender_access:
        joe@my.domain           OK
        blow@my.domain          OK

どのユーザがサイト外にメールを送信できるかを制限したい

あるユーザはインターネットにメールを送信できて、それ以外はできないように するには、どのように Postfix を設定するのですか？　アクセスできない ユーザには一般にバウンスメッセージを受け取らせたい。このようなアクセス 制限が必要かどうかは議論しないで下さい。私の決定ではないので。

Postfix はユーザごとの制限をサポートしています。制限は SMTP サーバにより 実装されています。こうして、ポリシーを破ろうとしたユーザは、SMTP サーバによりメールが拒否されます。このように: 

550 <user@remote>: Access denied

この実装は2つの検索テーブルを使います。一つにはどのユーザがどこにメールを 送ることができるかを定義し、もう一つにはどの配送先がローカルかを 定義します。これをあるユーザだけは外部の配送先にメールの送信を許され、 大半は制限されるようにスキームを変更することは読者に演習として残します。

この例では DB/DBM ファイルを想定していますが、これは LDAP や SQL でも 可能です。 

    /etc/postfix/main.cf:
        smtpd_recipient_restrictions =
            hash:/etc/postfix/restricted_senders
            ...other stuff...

        restriction_classes = local_only
        local_only = check_sender_access hash:/etc/postfix/local_domains, reject

    /etc/postfix/restricted_senders:
        foo@domain      local_only
        bar@domain      local_only

    /etc/postfix/local_domains:
        this.domain     OK      (matches this.domain and subdomains)
        that.domain     OK      (matches that.domain and subdomains)

システムが db ファイルの代わりに dbm ファイルを 使っているのであれば、hash の代わりに dbm を指定します。 Postfix がどのマップタイプをサポートしているかを知るには、 postconf -m コマンドを使います。

restriction_classes 変数は Postfix が chroot jail に入る前に /etc/postfix/local_domains.db を開けるようにするために存在します。 つまり、単なる実装の産物です。

このスキームはユーザを認証しないため、いくつかの方法でバイパスできて しまいます:

メールがいつもタイムアウトやロストコネクションになって送れません

 時々メールが "timed out while sending endof data -- message may be sent more than once" または "lost connection after DATA" といって失敗します。 ネットワークが停止したり、システムがクラッシュします。あなたがこのことで できることはあまりありません。たいていは自然に問題はなくなります。

しかし、いつもメール配送が失敗するのを目撃する場合には、他の問題を 抱えているかも知れません: 壊れたパス MTU 発見プロトコル。

簡単な背景はこのようなものです。SMTP プロトコルでは、HELO, MAIL FROM そして RCPT TO コマンドとその応答はかなり短いものです。Sendmail に 話しかける時には、sendmail が ESMTP コマンドパイプラインを実装できない ため、全てのコマンドと全ての応答は別々のパケットで送られます。

しかしメッセージ本体はいくつかのデータグラムとして送られ、それぞれの データグラムはローカルネットワークの MTU に依存しますが、たいてい 1kbyte またはそれよりいくぶん大きいものです。

いつもタイムアウトでメールが失敗するのであれば、パス MTU 発見を 実装した最近の UNIX マシンを送信機で動かしているのではないかと思います。 これはマシンが LAN 上を送るパケットと同じ大きさのパケットを、 IP DON'T FRAGMENT ビットを立てることで中間のルータがそのネットワークに とってパケットが大き過ぎることを理由にフラグメントさせることを妨げて、 マシンに送らせてしまいます。

メッセージがどのネットワークパスに従うかによって、途中のルータが ICMP MUST FRAGMENT メッセージでパケットが大き過ぎるといって応答するものも あります。通常は送信側のマシンがパケットを細かく分割して再送します。

しかし、これは送信側マシンに近い側のあるルータが、ある種の攻撃から システムを保護しようとする誤った試みで、このような ICMP フィードバックメッセージを破棄してしまうと破綻します。この場合、 ICMP フィードバックメッセージは送信側マシンに到達することはなく、 接続はタイムアウトします。

これは間違った設定のパケットフィルタの後ろにある web サーバで起こる 問題と同じ設定問題です: 小さな画像/ファイルは損なわれずに送られますが、 大きな画像やファイルはサーバが MUST FRAGMENT ICMP フィードバック メッセージを見ないためにタイムアウトします。

回避方法: パス MTU 発見を送信側マシンで使用しないようにします。 メールは出ていきますが、もちろん他のみんなが依然苦しむでしょう。 パス MTU 発見を使用不可にするには？　Solaris には ndd コマンドがあります; 他のシステムは 動いているシステムのカーネル パラメータを制御するための sysctl のような別の方法を使います。

修正: ICMP MUST FRAGMENT メッセージを破棄するルータを見つけ、 責任者に設定を修正するように説得します。

Postfix が全ての MX アドレスを試しません

メール配送時に、Postfix は優先度順に MX アドレスを全て試行し、 SMTP を話す最初のサーバで止めます。

SMTP を話す最初のサーバがクライアントへのグリーティングで「あなたの メールを受け入れるつもりはない」という意味の 5xx 状態コードで接続を 拒否すると、Postfix は諦めてメッセージを送信者にバウンスします。

SMTP を話す最初のサーバがクライアントへのグリーティングで「後で 来て下さい」を意味する 4xx 状態コードで接続を拒否すると、 Postfix は戻って後に配送を遅延します。

Sendmail がしていることで、もちろん sendmail がすること全てが正しいと 我々が知っていると仮定して、Postfix はサーバが 4xx や 5xx で グリーティングした時でも、他の MX アドレスに接触すべきと主張 する人もいるでしょう。

残念ながら、インフラストラクチャをひどい設定にする人がいます。 最も優先度の高い MX サーバを世界から見えるようにしますが、 これは外部からの接続を 5xx または 4xx グリーティングで拒否します。 Sendmail が二番目によい MX サーバへ行くという理由だけで、これらの 人達は全てのメーラがそうすると思っています。

もしこのような設定が問題であれば、下はそれを回避するコントロールになります。 

    /etc/postfix/main.cf:
	smtp_skip_4xx_greeting = yes
	smtp_skip_5xx_greeting = yes

smtp_skip_5xx_greeting はバージョン 20000104 以降の Postfix リリースにあります。使っている Postfix のバージョンを知るには、 postconf mail_version コマンドを使います。

変更をすぐに反映するには、postfix reload コマンドを実行します。

Root のメールが誰にも配送されません

ローカルメールの配送に procmail (または 他のコマンド) を使っていると、Postfix はメールをルートとして配送 しません。代わりに procmail (や他のもの) を nobody として実行します。いつかきっと Wietse は外部コマンドを root で 走らせるほど十分に Postfix を信頼するようになるでしょう。

解決法: (異常な条件を除いて) root としてログインすることを 考えないのと同様に、root でメールを受け取らないようにします。

エイリアスデータベースが /etc/aliases にないシステムもあります。 あなたのシステムでの場所を探すには、postconf alias_maps コマンドを実行します。

Postfix が存在しないローカルユーザ宛のメールを受け取ります

他の場所にある知らないバーチャルユーザへの メールの拒否の仕方を参照して下さい。

このセクションの情報は Postfix バージョン 19991216 またはそれ以降に 当てはまります。使っている Postfix のバージョンを知るには、 postconf mail_version コマンドを使います。

デフォルトでは、Postfix の SMTP サーバはどのローカルユーザが存在 するかは知らず、unknown@your.site 宛のメールを手際良く 受け取ります。理由は、異なるローカル配送エージェントが異なる 形式のユーザデータベースを持っているからです。

もちろん存在しないローカルユーザ宛のメールは結果的に配送できないものと してバウンスされますが、なぜまず始めにこのようなメールを受け取るので しょうか？　local_recipient_maps パラメータで、ローカルアドレスを 持つ全てのテーブルに問い合わせることで、ユーザが存在するか見つける 方法を Postfix の SMTP サーバに 教えることもできます。

例えば、デフォルトの Postfix ローカル配送エージェントを /etc/postfix/master.cf で使っているのであれば、次のように 指定します: 

    /etc/postfix/main.cf:
	local_recipient_maps = $relocated_maps $alias_maps, unix:passwd.byname

しかし、Postfix の SMTP サーバを chroot させて動かしていると、 chroot jail の中 (通常は /var/spool/postfix/etc) に パスワードファイルのコピーを必要とするシステムもあります。 これを見つけるにはやってみるしかありません。

デフォルトでは、Postfix の SMTP サーバは Postfix virtual マップについて知っており、 それ以上の設定がなければ unknown@virtual.domain 宛のメールを 拒否します。

user@domain としてメールを送る際に、あるユーザはローカルに配送したい

Maildir 形式のメールボックスをサポートしたい

 Maildir は Daniel Bernstein によって qmail とともに 紹介された、特定の1メッセージ1ファイルの構成です。maildir形式の 配送にするには、例えば、次のように指定します: 

    /etc/postfix/main.cf:
        home_mailbox = Maildir/

どんな相対パス名も / で終わると maildir 配送にします。 home_mailbox の値がユーザのホームディレクトリのパス名に付加 されます。

maildir フォーマットは .forward ファイルを通した 配送でもサポートされています。/file/name/ を配送先として 指定して下さい。最後に / がつくと maildir 配送をします。

システムのローカル配送に procmail を使いたい

 警告: この方法で procmail を使うのであれば、root 宛の メールを実在のユーザに転送する root へのエイリアスを作らなければ いけません。FAQ の "Root のメールが誰にも配送されません" のエントリを参照して下さい。 Postfix は環境変数を使って情報を提供します。中身は検閲されます。 空白を含む、シェルで特別な意味を持つ可能性がある文字はアンダースコアで 置き換えられます。

DOMAIN
受信者アドレスの @ の右側の文字列。
EXTENSION
オプションのアドレス拡張部分。
HOME
受信者のホームディレクトリ。
LOCAL
受信者アドレスの @ の左側の文字列、 例えば $USER+$EXTENSION。
LOGNAME
受信者のユーザ名。
RECIPIENT
受信者アドレス全体、$LOCAL@$DOMAIN。
SHELL
受信者のログインシェル。
USER
受信者のユーザ名。

醜い Delivered-To: ヘッダを取り除きたい

 Postfix がメールに醜い Delivered-To: メッセージヘッダを つけたと苦情をいう人がいるかもしれません。デフォルトでは、 Postfix はこのヘッダを、メールを転送する時とファイル (メールボックス) やコマンドに配送する時に付加します。目的はできるだけ早く、つまりそれが 起こる前にメールの転送ループを止めることです。しかしヘッダは 醜いのは疑いようもありません。

解決法、戦う兆候(?)からDelivered-To: ヘッダをオフにするには:

FAQ の Majordomo での approve コマンドの問題の項目も参照して下さい。

Postfix で majordomo の "approve" コマンドが動きません

 Postfix のローカル配送エージェントはメール転送ループを防ぐために、 Delivered-To: メッセージヘッダを付加します。majordomo メーリングリストでは、モデレータがリストに送られた投函を承認したい時に Delivered-To: が邪魔をします。Postfix システムはメールがループ していると主張します。

今のところ、推奨する回避方法は以下にマッチするあらゆるヘッダを取り除く ように approve スクリプトを編集することです: 

    /delivered-to/i

はい、これはモデレータが自分が何をしているか知っていることを 想定しています。

あまりお勧めしない回避方法は、majordomo のようなコマンドへの配送 時には Delivered-To: を挿入しないことです。 FAQ の 醜い Delivered-To: ヘッダを取り除きたい というエントリを参照して下さい。

メールの内部配送リストを保護したい

内部の email 配送リストを実装したいのです。all@our.domain.com のような もので、これは従業員全てへのエイリアスです。始めはエイリアスマップを 使おうと考えたのですが、"all" が「外部」からアクセス可能になって しまい、これは望みません... :-)
Postfix はアドレス毎のアクセス制御を実装できます。次に続くのは クライアントの IP アドレスをベースにしており、IP スプーフィングを 受けやすいです。 

    /etc/postfix/main.cf:
        smtpd_recipient_restrictions =
            hash:/etc/postfix/access
            ..the usual stuff...

    /etc/postfix/access:
        all     permit_mynetworks,reject

システムが db ファイルの代わりに dbm ファイルを 使っているのであれば、hash の代わりに dbm を指定します。 Postfix がどのマップタイプをサポートしているかを知るには、 postconf -m コマンドを使います。

さて、あなたのマシンが全てのインターネットメールを直接インターネットから 受け取る時にはこれで十分でしょう。もしネットワークがオフィスよりも 少し大きいと、それはうまくいきそうにありません。例えば バックアップ MX ホストが外から来たメールのクライアント IP アドレスを 「ロンダリング」すると、信頼するマシンから来たようにメールが見えるでしょう。

一般的な場合には、二つの検索テーブルが必要です: 一つは保護する必要がある 配送先のリストを持つテーブルで、もう一つは保護した配送先へメールの送信が 許されたドメインのリストを持つテーブルです。

次に続くのは送信者の SMTP エンベロープアドレスをベースにしたもので、 SMTP 送信者のスプーフィングをうけやすいです。 

    /etc/postfix/main.cf:
        smtpd_recipient_restrictions =
            hash:/etc/postfix/protected_destinations
            ..the usual stuff...

        smtpd_restriction_classes = insiders_only
        insiders_only = check_sender_access hash:/etc/postfix/insiders, reject

    /etc/postfix/protected_destinations:
        all@my.domain   insiders_only
        all@my.hostname insiders_only

    /etc/postfix/insiders:
        my.domain       OK
        another.domain  OK

冗長な smtpd_restriction_classes は Postfix が chroot jail に入る 前にどの検索テーブルを開くかを知るために必要です。単なる実装の産物です。

SMTP の送信者アドレスをかたるだけでよいので、このスキームが見つからずに 済むのは比較的簡単です(?)。

内部リストの流量が少なければ、おそらくモデレートする意義が増すでしょう。

Postfix のバーチャルドメインの設定方法

問題:

解決法:

バーチャルドメインの立ち上げ方に関するさらに詳しい情報は、virtual マニュアルページを参照して下さい。

Postfix の virtual マップでコマンドが動きません

コマンドへのメールの配送は、コマンドが正しい権限で実行されなければ ならないため、セキュリティに敏感な操作です。 Postfix のローカル配送エージェントのような、root 特権を持った ソフトウェアだけがコマンドの権限を指定できます。

セキュリティ上の理由から、Postfix は root 特権を使うことを できるだけ避けようとします。特に、Postfix バーチャルマッピングは 特権を持たないデーモンによってなされるため、バーチャルマップにある コマンドを安全に実行できる方法がありません。

解決法: 代わりにローカルのエイリアスを指定します。Postfi のローカル 配送エージェントは正しい権限でコマンドを実行するのに十分な権限を 持っています。

注意: エイリアスデータベースが /etc/aliases にないシステムも あります。あなたのシステムでの場所を探すには、postconf alias_maps コマンドを実行します。

バーチャルドメインをメールボックスで受け取りたい

質問: 元の受信者情報を損なわずに一つのメールボックスで一つのドメイン 宛のメール全てを受け取る方法は？　Postfix の Delivered-To: メールヘッダにはメールボックスのオーナーしかなく、メールが送られた バーチャルアドレスは書いてありません。

回答: あるドメインを一つのメールボックスに配送するのはうんざりする 行為であることにみんな同意すると私は願いたい。SMTP や UUCP を 使ったメールの転送がよりよい選択肢です。不幸にも、SMTP や UUCP は 極めて多い Windows ユーザにとって代替として使えるものではありません。

元のバーチャル受信者情報を Delivered-To: ヘッダに展開することが 可能です。コツは伝統的なインデックスされたファイルの代わりに 正規表現を使ったバーチャルマップを使うことです。

次の例は joe+username@your.domain を含んだ Delivered-To: メッセージヘッダをつけて username@virtual.domain へ配送します。 Postfix はすでにエンベロープ送信者アドレスを Return-Path: ヘッダに つけています。Delivered-To: と Return-Path: ヘッダの中の情報は メールボックス内ドメインの信頼できる実装には十分です。 

    /etc/postfix/main.cf:
	recipient_delimiter = +
	virtual_maps = 
	    ...non-regexp virtual maps...
	    regexp:/etc/postfix/virtual_regexp

    /etc/postfix/virtual_regexp:
	/^virtual\.domain$/		whatever
	/^(.*\)@virtual\.domain$/	joe+$1

注意:

例外つきでアドレスをマスカレードしたい

 外部の組織の人達にはそれぞれの内部ホスト名のついたアドレスよりも user@company.com の形式のアドレスしか見えないことが望まれ ます。これはアドレスマスカレーディングでできます。

アドレスマスカレーディングはメールゲートウェイでのみ使うことを 意図しています。

場合によっては、あるユーザやホストをマスカレードの例外にしたいかも しれません。

通常は、変更を反映するには postfix reload コマンドを実行します。

ウィルススキャンをサポートしたい

 もしオペレーティングシステムやアプリケーションが現在の製品みたいに もろくなくて、本当に想定している通りに動いたら、素晴らしくないですか？ さて、我々はただ一つの問題を同時に解決できます。

現在、Postfix には他のプログラムに全てのメッセージを検査させるための フックはないので、メールが Postfix に入る前か Postfix から出る時、 例えばメールボックスへの配送時にスキャンしなければいけません。

例: 

    /etc/postfix/main.cf:
        mailbox_command = /some/program ...

この例は全てのローカルメールをメールボックスに配送するコマンドを 指定しています。例えば、サンプルの main.cf ファイルを参照 してください。/etc/aliases で実在する人に向けた root のエイリアスを指定しなければいけません。そうしないと、root に送られたメールは期待通りの動作をしません。 

    /etc/postfix/main.cf:
        mailbox_transport = foo

この例はローカルメールボックス配送を /etc/postfix/master.cf で設定された配送方法 foo に委託します。このルートに従うので あれば、パイプメーラのようなものを構築します(?)。master.cf の 例を参照して下さい。

インターネット- UUCP ゲートウェイを設定したい

 これはインターネット上にあり、全てではなく一部の非ローカルメールを UUCP で配送するマシンを設定する方法です。UUCP のみのホストの設定は FAQ エントリの UUCP のみ を参照して下さい。

UUCP をデフォルトの配送方法にしたい

 これは全てのメールを UUCP リンクで中継する方法です。UUCP と SMTP の 間のゲートウェイになるマシンの設定は FAQ エントリの インターネットから UUCP へを参照して下さい。

FAX マシンにメールを送りたい

 以下の情報は Joerg Henne によるものです:

ここでは Postfix と HylaFax で <fax number>@fax.our.domain スキームを使っています。ここで使った設定: 

    /etc/postfix/master.cf:
        fax       unix  -       n       n       -       -       pipe
            flags= user=fax argv=/usr/bin/faxmail -d -n ${user}

    /etc/postfix/transport:
        fax.your.domain   fax:localhost

    /etc/postfix/main.cf:
        transport_maps = hash:/etc/postfix/transport

システムが db ファイルの代わりに dbm ファイルを 使っているのであれば、hash の代わりに dbm を指定します。 Postfix がどのマップタイプをサポートしているかを知るには、 postconf -m コマンドを使います。

注意: fax.your.domain を DNS で広めないように気をつけて下さい...

Undefined symbols: ___dn_expand, ___res_init etc.

 質問: Postfix をビルドした時に、次のようなエラーが出ました: 

    ld: Undefined symbol
       ___dn_expand
       ___res_init
       ___res_search
    *** Error code 1

回答: BIND バージョン 8 のインクルードファイルと違うバージョンの リゾルバライブラリが混在しています。

修正: 正しいインクルードファイルを使います。例: 

    make makefiles CCARGS="-I/usr/include".

Undefined symbols: dbm_pagfno, dbm_dirfno etc.

 質問: Postfix をビルドした時に、次のようなエラーが出ました: 

    Undefined                       first referenced
     symbol                             in file
       dbm_pagfno                          ../lib/libutil.a(dict_dbm.o)
       dbm_dirfno                          ../lib/libutil.a(dict_dbm.o)

回答: /usr/include/ndbm.h を使う代わりに、あなたは Postfix を互換性のないサードパーティファイル、典型的には /usr/local/include/ndbm.h を使ってビルドしています。

修正: サードパーティの ndbm.h インクルードファイルを取り除きます。

サードパーティの DB ライブラリを使いたい

 古い dbm UNIX データベースには、たくさんの情報を蓄えようと する時に、いくつかの制限があります。ハッシュの衝突数が多くなって エントリが単一のディスクブロックで合わなくなると、制限が破綻します。 より新しい db データベースはこのような制限で苦しみません。 これは 4.4BSD や Linux システムの標準です。

Postfix を db をサポートしない UNIX で db とともに ビルドするには、db-1.85 リリースまたは db-1.85 互換インターフェースを 持つ カレントバージョン が必要です。

サードパーティ DB ライブラリを使ってビルドするには、Postfix の トップレベルディレクトリで次のコマンドを使います。 Solaris では、誤ったライブラリをリンクするのを避けるために、 LD_LIBRARY_PATH を unset するコマンドが必要かもしれません。 

    % LD_LIBRARY_PATH=         (Bourne-shell syntax)
    % unsetenv LD_LIBRARY_PATH (C-shell syntax)
    % make tidy
    % make makefiles CCARGS="-DHAS_DB -DPATH_DB_H='<db_185.h>' -I/some/where/include" AUXLIBS=/some/where/libdb.a
    % make

もちろんインクルードディレクトリやオブジェクトライブラリの 実際の場所を指定しなければいけないでしょう。

1つの問題: 古い DB バージョンは /usr/include/ndbm.h と互換 ではない /usr/local/include/ndbm.h ファイルをインストールします。 偽のファイルは取り除くように気をつけて下さい。 FAQ の "Undefined symbols: dbm_pagfno, dbm_dirfno etc" を参照して下さい。

Up one level | Postfix FAQ