Postfix Frequently Asked Questions

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

目次

Postfix 警告およびエラーメッセージ

設定例

Sendmail との非互換性

数百の Postfix プロセスを走らせる

Postfix のパフォーマンス

ネットワーク経由でのメール受信

メールの中継

リモート配送

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

メーリングリスト

バーチャルドメイン

アドレスの書き換え

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

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

Postfix キューのメンテナンス

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

特定のオペレーティングシステムでの問題

Compaq での問題

IRIX での問題


POP や IMAP の問題

Postfix はメール配送システムです。メールを読むための POP や IMAP といったサービスは Postfix は実装していません。Postfix のような ソフトウェアと協力できる POP/IMAP の実装がいくつかあります。

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 が owner-list エイリアスを無視します

通常、ローカルのエイリアス foo に対応するエイリアス owner-foo がある場合、Postfix はメッセージの送信者ではなく owner アドレスに配送エラーを報告します。

しかし、Postfix の作為的な実装による結果、owner-foo エイリアスは エイリアス展開が終わった後のみにしか効果がありません。

コマンドやファイルへの配送を含む、エイリアス展開中に起こった配送問題は 元のエンベロープの送信者アドレスに報告されます。

理由は、送信者アドレスが置き換えられていることを知らない Postfix キューマネージャによりバウンスが送られるためです。

この制限は Postfix ローカル配送エージェントが配送できないメールを 取り扱う方法を変えることで修正されるでしょう。


"fatal: open database /etc/aliases.db" が意味するのは?

DB ファイルは Berkelaey DB ライブラリによって保守されています。 上記のメッセージは次のどれかを意味します:

問題を修正するには、 root で次のコマンドを実行して下さい:

    # newaliases
これは Postfix が期待する形式の aliases.db を作成します。

  • または全く違う問題かも知れません。newaliases を実行した 結果が長さ 0 の aliases.db ファイルであれば、次の問題により苦しめられて います。

    これを修正するには、Berkeley DB ライブラリを適切にインストールします。 例えば、RedHat version 7.0 は Berkeley DB version 3 オブジェクト ライブラリをデフォルトで使用していますが、/usr/include/db.h ファイルはデフォルトではインストールされていません。正しく Postfix を構築するには、db3-devel パッケージをインストールしなければいけません。

    正しくインストールされたシステムでは、<db.h> ファイルを インクルードし、-ldb でリンクすることで同じバージョンの Berkeley DB ライブラリからファイルをアクセスします。


    sendmail が set-uid root ファイルパーミションに なっているか、set-uid root プロセスから走っています

    伝統的に、UNIX の sendmail コマンドは set-uid root パーミションでインストールされます。Sendmail 以外の多くの MTA でさえも set-uid root sendmail コマンドとともに出荷されます。 Postfix ではこれに当てはまりません。Postfix sendmail コマンドは set-uid されないように設計されています。

    不幸なことに、Linux システムには自動的にファイルパーミションを Sendmail の sendmail コマンドに想定された状態に「修復する」 linuxconf という役に立つユーティリティを持つものがあります。 Postfix の sendmail 実行ファイルの set-uid ビットをリセット した時でさえ、うれしいことに linuxconf は再びオンにしてくれます。

    SuSE システムでは、ファイルパーミション修正ユーティリティは SuSEconfig と呼ばれます。他の Linux システムは異なる名前を 使うかも知れません。通常のマイレージなどの免責事項が適用されます (訳注: 環境によってコマンド名などが違うので、各自の状況に応じて 対応して下さいの意)。

    解決法


    sendmail: unable to find out your login name

    このメッセージは UNIX パスワードファイルに存在しないユーザ ID を 持つプロセスからのメールを送信する時にログに記録されます。Postfix はこの情報をエンベロープ送信者アドレスを設定するために使います。

    エンベロープ送信者アドレスは、メッセージで From: ヘッダアドレスが 指定されない場合のデフォルト値にもなります。

    To fix, specify the envelope sender address on the sendmail command line: 修正するには、sendmail コマンドラインでエンベロープ送信者アドレスを 指定します:

    sendmail -f user@domain ...
    

    数百の Postfix プロセスを FreeBSD で走らせる

    Postfix プロセスを何百も走らせると、カーネルは結果的にファイル ハンドルを使い果たします; その後、ソケットを使い果たします。

    カーネルパラメータをブート時に設定するには、次の行を /boot/loader.conf ファイルに追加します (これは FreeBSD 4.x に特有です):

    kern.ipc.maxsockets="5000"
    kern.maxfiles="16384"
    kern.maxfilesperproc="16384"
    kern.ipc.nmbclusters="65536"
    

    カーネルパラメータを実行時に設定するには、次のコマンドを root で 実行して下さい (これは FreeBSD 4.x に特有です):

    # sysctl -w kern.ipc.maxsockets=5000
    # sysctl -w kern.maxfiles=16384
    # sysctl -w kern.maxfilesperproc=16384
    # sysctl -w kern.ipc.nmbclusters=65536
    

    数百の Postfix プロセスを Linux で走らせる

    Postfix のプロセス数を何百にまで増加させると、カーネルは結果的に ファイルハンドルを使い果たします; その後、プロセススロットを 使い果たすでしょう。

    次の情報はカーネルのバージョンに依存します。

    /etc/sysctl.conf を持つ Linux システムでブート時にパラメータを 設定するには、次の行を加えます:

    fs.file-max = 16384
    kernel.threads-max = 2048
    

    実行時にカーネルパラメータを設定するには、次のコマンドを root で実行します:

    # echo 16384 > /proc/sys/fs/file-max
    # echo 2048 > /proc/sys/kernel/threads-max
    

    incoming キューにメールがとどまります

    メールが incoming キューにたくさんたまっていても、Postfix は外行きの SMTP 配送を少ししか実行しません。なぜもっと SMTP クライアントを動かさないのでしょう?

    これはメールを受信することでディスクの I/O が飽和状態になり、 Postfix キューマネージャが要求を処理できる機会を十分に得られないの かもしれません (たくさんの SMTP サーバプロセスがたった一つの キューマネージャとディスクアクセスの競合をします)。

    ディスクを速いものと交換することで解決します。

    私は現在もソフトウェアサイドからそのスケジューリング問題を解決しようと しています。

    現在のところの解決策は、一つのマシンに複数の IP アドレスを設定し、 それぞれの IP アドレス毎に一つずつ Postfix を走らせます。 それぞれの Postfix はキューディレクトリを共有できませんが、 メールボックスディレクトリの共有は可能です。

    単にそれぞれの Postfix をことなる設定ディレクトリで動かします:

        # postfix -c config_directory start
    

    それぞれの main.cf ファイルは扱うべきインターフェースに依存する、 異なる $myhostname の設定を持ちます。

        /my/own/main.cf:
        queue_directory = /my/own/queue/directory
        myhostname = foo1.my.domain
        inet_interfaces = $myhostname
    

    入ってくる SMTP 接続に対する Postfix の応答が遅い

    質問:
    私の Postfix サーバは遅過ぎます。SMTP ポートに telnet で接続 すると (telnet hostname 25)、応答が40秒後に返ります。 その一方で、POP ポートに telnet すると (telnet hostname 110) 遅延なく応答が返ります。

    回答:

    ネームサービスに問題があります。

    Postfix は C ライブラリルーチン gethostbyname() および gethostbyaddr() を SMTP クライアントのホスト名を見つける ためにコールします。これらのライブラリルーチンは、要求を満たすために いくつかのシステム設定ファイルを使います。これらは実際、Postfix の制御外の理由で DNS の呼び出しにたどり着くかもしれません。

    システムによって、これらの制御ファイルは /etc/nsswitch.conf/etc/svcorder/etc/host.conf や他の名前になっています。 これらのファイルは C ライブラリルーチンがローカルの /etc/hosts を DNS の前か後、どちらに使うかを指定します。


    Postfix が SMTP クライアントのログを IP アドレスで取ります

    Postfix サーバが SMTP クライアントの接続のログを解決したホスト名では なく数字の IP アドレスで取ります。nslookup を使うとアドレスは 名前に解決されます。

    セキュリティを上げるために chroot jail の中で Postfix サーバを 動かしていて、いくつかの設定ファイルが足りないのでしょう。 chroot jail の中で動かすには、Postfix SMTP クライアントとサーバは システムの設定ファイルのコピーを Postfix キューディレクトリに必要と します。正確なファイルのリストはシステムにかなり依存しますが、 少なくとも次のものは必要になるでしょう:

        /var/spool/postfix/etc/resolv.conf
        /var/spool/postfix/etc/services
    

    もちろんこれらのディレクトリとファイルは root が所有し、postfix ユーザがアクセスできなければならないので、ディレクトリは モード 0755、ファイルは 0644 である必要があります。

    詳細は Postfix の配布ソースコードにある examples/chroot-setup ディレクトリ内のファイルを見て下さい。


    warning: xxx.xxx.xxx.xxx: address not listed for hostname yyy.yyy.yyy

    Postfix は自身のジャンクメール及びメールリレー制御にホスト名を 使います。これは理論的にはジャンクメール及びメールリレー制御を パスさせるために、誰かが偽の DNS 情報を設定するように動機づけられる 可能性があります。

    Postfix が SMTP クライアントのホスト名を SMTP クライアント IP アドレスで検索する際には、Postfix は SMTP クライアントの IP アドレスが SMTP クライアントのホスト名にリストされているかもチェックします。

    SMTP クライアント IP アドレスが SMTP クライアントホスト名以下に 挙げられていなければ、Postfix は SMTP クライアントのホスト名は SMTP クライアント IP アドレスに属していないと結論づけ、SMTP クライアントホスト名を無視します。この警告はなぜ SMTP クライアントが ジャンクメールもしくはメールリレーチェックで止められたか、又は 止めなかったかをわかるように、ログに記録されます。

    SMTP クライアントの DNS レコードを管理する人にコンタクトし、 それぞれの IP アドレスに PTR レコードが必要であり、この PTR レコードに A レコードがマッチすることが必要であると説明しても よいでしょう。

    一つの IP アドレスが複数の PTR レコードを持ち得るという RFC を 読む人もいますが、それは PTR レコードを今以上に使いにくくします。 いずれにせよ、一つの IP アドレスに複数の名前を持たせることは、 SMTP クライアントのホスト名を見つける問題を悪化するだけです。

    助けて! 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.sitesome.other.site!test@some.site のようなソースルートアドレスを拒否します。
    3. ループホール: some.site のバックアップ MX ホストの Postfix は test@some.other.site@some.sitetest%some.other.site@some.site のようなソースルートアドレスを some.site のプライマリ MX ホストに 転送します。プライマリ MX ホストのメーラの設定によっては、プライマリ MX ホストがインターネットにメールをスパムするかも知れません。

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

    1. some.site のプライマリ MX ホストの Postfix は test@some.other.site@some.sitetest%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 コマンドを使います。

    注意: DRAC のような ソフトウェアには hash ファイルの代わりに btree ファイルを 使うものがあります。その場合、それに応じて上の check_client_access 制限も合わせる必要があるでしょう。

    あまり好ましくない方法は、クライアントの 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 サーバによりメールが拒否されます。このように:

    554 <user@remote>: Access denied
    

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

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

        /etc/postfix/main.cf:
            smtpd_recipient_restrictions =
                check_sender_access hash:/etc/postfix/restricted_senders
                ...other stuff...
    
            smtpd_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 this.domain and subdomains
    

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

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

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


    Postfix をバックアップ MX ホストとして設定したい

    ある他のドメインのセカンダリ MX である場合に必要な設定は次の通りです:

        DNS:
            the.backed-up.domain.name        IN      MX 100 your.machine.name
    
        /etc/postfix/main.cf:
            relay_domains = the.backed-up.domain.name
            smtpd_recipient_restrictions = permit_mynetworks check_relay_domains
    
    

    ある他のドメインのプライマリ MX である場合には次の設定も必要です:

        /etc/postfix/main.cf:
            transport_maps = hash:/etc/postfix/transport
    
        /etc/postfix/transport:
            the.backed-up.domain.name       smtp:[their.mail.host.name]
    

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


    リモートメールが全て「Host not found, try again」といってキューにたまります

    リモートアドレスのメールサーバに接続すると、次のようになります:

        Jul 14 12:45:38 myhostname postfix/qmgr[2246]: 74FBF30501:
        from=<sender@sender.domain> size=309 (queue active)
        Jul 14 12:45:39 myhostname postfix/smtp[2349]: 74FBF30501:
        to=<recip@recip.domain> relay=none, delay=3944, status=deferred (Name
        service error for domain recip.domain: Host not found, try again)
    

    しかし、ホスト名の nslookup はうまくいきます。

    いくつかの異なる問題があり得ます。


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

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

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

    Cisco PIX "fixup protocol smtp" バグ

    バージョン 5.2(4) または 6.0(1) より古いソフトウェアを動かしている Cisco PIX firewall にはバグがあります。

    バグ ID は CSCds90792 です。"fixup protocol smtp" 機能はメールの 最後の "." と "CRLF"が別々のパケットで送られる場合に正しく 扱えません。

    "fixup protocol smtp" が有効になった Cisco PIX に隠されたメーラを 認識する方法は? バージョン 5.1 もしくはそれ以降については、 fixup protocol smtp コマンドは SMTP バナーの文字を "2", "0" および "0 SPACE" 文字を除いてアスタリスクに変えます。

    このようなフィルタに隠されたメーラに接続すると、次のように見えます:

    220 **************************************0******0*********20 ****200**0********
    *0*00
    

    IP path MTU discovery

    簡単な背景はこのようなものです。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 コマンドを実行します。

    "fatal: unknown service: smtp/tcp" が意味するのは?

    Postfix /etc/postfix/master.cf ファイルが Postfix SMTP クライアントが chroot 環境内で走ることを指定しています。しかし、 このモードでの操作に必要なファイルが /var/spool/postfix 以下に インストールされていません。

    chroot 操作はシステムへの侵入者に対する重要な壁を作ります。

    2つの解法があります:


    メール配送が "unknown mail transport error" といって失敗します

    これは egrepless という友達に出会う機会です。 Postfix の進展や失敗を含めた動作は、典型的には /var/log/maillog という名前のログファイルに記録されます。あなたのマシンの Postfix の動作が記録されている場所を見つけるには、/etc/syslog.conf ファイルを調べます。

    "unknown mail transport error" の原因を見つけるには、次のコマンドを タイプします:

    egrep '(warning|fatal|panic):' /var/log/maillog | less
    fatalpanic のラベルがついたメッセージには特に 注意を払って下さい。これらは Postfix が幸せに動くために取り組まれる 必要がある、破壊的な失敗を記述しています。fatal のラベルが 付けられた問題は、設定ファイルやファイルの権限などを調整することで、 あなたが修正します。panic のラベルが付けられた問題は Postfix の作者が Postfix のソースコードを変更することで修正します。

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

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

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

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


    "biff_notify: Connection refused" が意味するのは?

    デフォルトでは、Postfix ローカル配送エージェントはローカルユーザに 新着メールを通知しようとします。この機能は comsat ネットワーク サービスを利用しており、これは多くの UNIX システムでパフォーマンスや セキュリティの問題から off になっています。

    その警告メッセージは comsat ネットワークサービスが off に なっていて、新着メール通知が失敗したことを意味しています。

    Postfix 配送エージェントの comsat クライアントコードを 使用不可にするには、次のように指定します:

    /etc/postfix/main.cf:
        biff = no
    

    comsat ネットワークサービスを使用可能にするには、 inetd.conf ファイル内の対応するエントリのコメントを外します。


    "NIS domain name not set - NIS lookups disabled" が意味するのは?

    この警告メッセージは NIS (Network Information Service) が有効になって いないことを意味します。完全にOKです。Postfix が前もってこのことを 知るのはかなり困難です。

    Postfix local 配送エージェントの NIS クライアントコードを無効に するには、main.cf ファイルの対応するセクションを更新し、 エイリアスファイルの形式によって次のどれか一つを指定します:

    /etc/postfix/main.cf:
        alias_maps = $alias_database
    

    これは、ローカルのエイリアスデータベースが定義されていれば、 Postfix にそれだけを使うことを強制します。


    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 = $alias_maps, unix:passwd.byname
    

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

    デフォルトでは、Postfix の SMTP サーバは Postfix virtual マップについて知っており、 それ以上の設定がなければ known-user@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: ヘッダを取り除きたい というエントリを参照して下さい。


    Postfix が "| command" から/宛のメールを受け取ります

    Postfix では | や / は aliases や .forward ファイル、:include: ファイルに現れる時のみ特別な意味を持ちます。メールアドレスでは 特別な意味を持ちません。

    10年以上前の脆弱なシステムへのメールを受け取らねばならない場合、 潜在的に危険な MAIL FROM や RCPT TO コマンドを拒否する regexp フィルタを慎重に設定します。

        /etc/postfix/main.cf:
            smtpd_sender_restrictions =
                regexp:/etc/postfix/envelope-regexp
                reject_unknown_sender_domain
            smtpd_recipient_restrictions =
                regexp:/etc/postfix/envelope-regexp
                permit_mynetworks
                check_relay_domains
    
        /etc/postfix/envelope-regexp:
            /[/|]/  REJECT
    

    しかし、/ を持つ全てのエンベロープアドレスを拒否してしまうと、 X.400 アドレス構造があらわに残っている単純な X.400 - インターネットアドレスマッピングで問題を引き起こします。

    メッセージヘッダの中身に関しては、header checks 制限に関する ドキュメントも参照してください。これらの制限はコマンド・ファイルを 宛先とする攻撃に対する保護に使われます。例えば、Errors-To: や Return-Receipt_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 が知らないバーチャルユーザ宛のメールを拒否しません

    知らないバーチャルユーザ宛のメールが "mail loops back to myself" といって失敗します

    Postfix がバーチャルドメイン宛のメールを "relay access denied" といって拒否します

    解決法: Postfix スタイルもしくは Sendmail スタイルのバーチャルドメインを 指定します。

    Sendmail 形式のバーチャルドメインは Postfix バージョン 20001118 以前ではサポートされていません。

    注意深く virtual マニュアルページの 指示に従ってください。


    Postfix の virtual マップでコマンドやメーリングリスト、/file/name への配送が動きません

    簡単な回答: Sendmail 形式の
    virtual ドメインを指定し、コマンドやメーリングリスト、/file/name をローカルの aliases ファイルに指定します。

    長めの回答を続けます。

    コマンドは適切な権限で実行されねばならないため、 ファイルやコマンドへのメール配送はセキュリティに敏感な操作です。 Postfix ローカル配送エージェントのように root 権限を持つ ソフトウェアしかコマンドの権限をセットできません。

    セキュリティ上の理由から、Postfix は root 権限の利用を できるだけ避けようとしています。特に Postfix virtual マッピングは 特権を持たないデーモンによりおこなわれるため、virtual マップに 見られるコマンドを実行したり指定されたファイルに配送する安全な 方法がありません。


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

    質問: 元の受信者情報を損なわずに一つのメールボックスで一つのドメイン 宛のメール全てを受け取る方法は? 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
            fax_destination_recipient_limit = 1
    

    fax_destination_recipient_limit エントリ (by Simon, Mr. Simix) は複数の送信先をコマンドラインで指定できない FAX ソフトウェアの 場合に必要です。他への影響はありません。

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

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


    Postfix キューからメッセージを削除したい

    キュー ID が ABCDEF の一つのメッセージを Postfix キューから削除する ためには、Postfix を止める必要はありません。

        # cd /var/spool/postfix
        # find incoming active deferred -name ABCDEF -print | sed 1q | xargs rm
    

    上のコマンドは最高1つのファイルしか消さないので安全です。 同じキューファイル名を持ってしまった新着メールを消してしまう可能性は ありません。

    大量のメールを削除するのであれば、まず Postfix を止めるのが安全です。

        # postfix stop
        # cd /var/spool/postfix
        # find incoming active deferred defer -type f -print |
        fgrep -xf /file/with/queue-ids | xargs rm
        # postfix start
    

    キューファイルを削除している途中で届いた新しいメールを消してしまうかも しれないので、動いている Postfix システムで上記のコマンドを使っては いけません。


    Postfix キューを移動したりリストアしたい

    Postfix キューファイルを単にあるファイルシステム (やバックアップ) から 別のファイルシステムにコピーするのは安全ではありません。 その理由は、キューファイル名は Postfix incoming, active そして deferred キューディレクトリに渡って ユニークでなければならないためです。2つのキューファイルが同じ ファイル(ベース)名を持っていると、ファイルをキューディレクトリ間で 移動する時にキューファイルのうち1つが失われるかもしれません。

    Postfix はキューファイル名をその inode 番号と日時のマイクロ秒部分から 名付けます。こうして、キューファイルに他の inode 番号に基づく名前が ついていると、わずかながらファイル名が別のキューファイルとぶつかる 可能性があります。

    キューファイルをコピーする時にキューファイル名の衝突を避けるには、 かわりに maildrop ディレクトリに incoming、active および deferred キューファイルをリストアします。

    2000年の後期の時点で、Postfix キューは全てハッシュ化 (例えば ファイル ABCDEF は A/B/ABCDEF に保管されます) されたため、 さらにサブディレクトリからファイルを移動する必要があります。

        # postfix stop
        ... restore incoming/active/deferred queue files under the maildrop directory...
        # find incoming active deferred -type f -exec mv '{}' . ';'
        # rm -rf incoming active deferred
        # postfix start
    
    maildrop ディレクトリ以下にリストアしたファイルと衝突するおそれが あるため、この作業中にはローカルで新しいメールを送信しないでください。

    Postfix が起動されると、maildrop ディレクトリからキューファイルが 取り出されて、適切なキューファイル名が与えられます。


    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 とともに ビルドするには、www.sleepycat.com にある Berkeley DB ソースコードを使うことができます。 Postfix を Sleepycat の Berkeley DB とともにコンパイルする方法の説明は Postfix 配布ソースコードにある DB_README ファイルを参照して下さい。


    IRIX における IP から文字列への変換に関する問題

    質問:
    クリーンなディスクに IRIX 6.5.7m を特別なオプションや ソフトウェアをつけずにインストールすると、次の問題でつまづきます; inet_ntoa() 関数がコールされるたびに INADDR_NONE (malformed request?) を返すようにみえます。

    回答:
    gcc と SGI の cc でコンパイルされたシステムライブラリには 非互換性があります。 http://freeware.sgi.com/shared/howto.html にある記述を参照してください。

    gcc を使わなければならないのであれば、 http://www.isc.org/ にある BIND のソースコードの inet_ntoa() ルーチンを使う回避が可能です。


    Compaq メールブラックホール問題

    Compaq Tru64 UNIX の設定によっては、Postfix がメールを受け取っても 何も起こらないことがあります。メールは mailq コマンドでも 現れません。

    Postfix はメッセージを受け取ったことを示すためにキューファイルに 実行ビットをセットします。キューファイルが実行ビットを持たない限り、 Postfix は「メールはまだ受信中」として無視します。

    拡張セキュリティが有効になっていると、Compaq Tru64 UNIX は スーパーユーザ以外が実行ビットをキューファイルに立てようとするのを 認めないという機能を持ちます。不幸にも、Postfix はそのような 試みが失敗したことを知らされず、メールがブラックホールに消えたように 見えてしまいます。

    Postfix は実行ビット以外のビットを使うように変更できますが、それは 同様に他のシステムで失敗するかも知れません。他の可能性はスーパーユーザ 以外でも実行ビットをファイルに立てることを許可し、Postfix キュー ファイルシステムを noexec オプションや同等なものをつけて マウントすることです。


    Up one level | Postfix FAQ