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 は自分と同じ サブネットワークからのメールのみを中継します。ネットワークや マシンが非常に低速もしくは高速であれば、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
        local_transport = error:local delivery is disabled

    /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 のバージョン 2.0 以降で使えます。 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 = 4h

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 ライブラリによって保守されています。 上記のメッセージは次のどれかを意味します:


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: ヘッダアドレスが 指定されない場合のデフォルト値にもなります。

修正するには、sendmail コマンドラインでエンベロープ送信者アドレスを 指定します:

sendmail -f user@domain ...

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

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

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

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

FreeBSD 4.2 では、最後の3つのパラメータが /boot/loader.conf からではセットできません。オープンするファイルの制限をセットするには、 root で次のコマンドを実行してください。

# sysctl -w kern.maxfiles=16384
# sysctl -w kern.maxfilesperproc=16384

FreeBSD 4.2 では、kernel 設定ファイルで異なる maxusers をして kernel を再コンパイルすることによってのみ、kern.maxproc をセットすることができます。


数百の 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

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

数百のプロセスを走らせるためには、プロセス毎のオープンファイル制限を 調整する必要があるかも知れません。 Solaris FAQ によると、Solaris 2.4 またはそれ以降では /etc/system に 次の行を加えます:

* set hard limit on file descriptors
set rlim_fd_max = 4096
* set soft limit on file descriptors
set rlim_fd_cur = 2048

数千の Postfix 配送エージェントを走らせる

千以上の配送エージェントを使う Postfix を走らせるためには、 FD_SETSIZE 定数を適切な値にしてソフトウェアを再コンパイル する必要があります。

% make tidy
% make makefiles "CCARGS=-DFD_SETSIZE=2048"
% make

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

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

問題は以下のうちの一つかもしれません。


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

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

回答:

1) より多くの SMTP サーバプロセスを走らせるように、Postfix を設定する 必要があります。master.cf ファイルの smtpd エントリを 編集してプロセス数制限を調節するか、main.cf ファイルの default_process_limit 設定を増やします。更新を有効にするには、 postfix reload コマンドを実行してください。

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

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 サーバを 動かしていて、いくつかの設定ファイルが足りないか、情報が間違って いるのでしょう。"postfix check" コマンドを実行すると、どのファイルの 情報が間違っているか報告されます。例:

warning: /var/spool/postfix/etc/resolv.conf and /etc/resolv.conf differ
warning: /var/spool/postfix/etc/localtime and /etc/localtime differ

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

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

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

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

    /etc/postfix/client_access:
        4.3.2.1         OK
        5.4.3.2         987654321

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

注意: ソフトウェアの中には 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
            reject_unauth_destination

    /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_recipient_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 コマンドを使います。

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

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


Postfix をリモートサイトの MX ホストとして設定したい

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

    DNS:
        the.backed-up.domain.tld        IN      MX 100 your.machine.tld

    /etc/postfix/main.cf:
        relay_domains = $mydestination the.backed-up.domain.tld
        smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination

the.backed-up.domain.tld を MYDESTINATION にリストアップしないでください。

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

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

    /etc/postfix/transport:
        the.backed-up.domain.tld       relay:[their.mail.host.tld]

システムが 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
        type=MX: 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 は最近まで ESMTP コマンドパイプラインを実装していなかったため、 古いバージョンの Sendmail に話しかける時には、全てのコマンドと 全ての応答は別々のパケットで送られます。

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

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

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

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

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

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

回避方法: 受信側マシンで、小さい MTU を設定します。例えば、 PPPoE (PPP over Ethernet) を使う人はたいてい ethernet のデフォルトの 1500 よりも少し小さな MTU を選ばなければいけません。

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


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

メール配送時に、Postfix は優先度順に MX アドレスを全て試行し、 SMTP を話す最初のサーバで止めます。しかし、いったん SMTP グリーティングを受け取ると、配送が失敗しても Postfix は次の MX ホストに移ろうとはしません。

これは Postfix が SMTP 接続キャッシングを実装するときに 最終的に解決されます。


"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 になっています。

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

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

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

注意: 最近のバージョンの procmailbiff 通知を 発行します。完全に biff を黙らせるには procmail 設定ファイルも更新する必要があるでしょう。

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


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

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

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

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

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


Postfix が "User unknown in local recipient table" といってメールを拒否します

Postfix 2.0 では、ローカルユーザやアドレスを持つテーブルを全て local_recipient_maps パラメータにリストアップすることで、 Postfix SMTP サーバに存在するローカルユーザを知らせることを 求められます。使っている Postfix のバージョンを知るには、 postconf mail_version コマンドを使います。

local_recipient_maps 設定のデフォルトは、デフォルトの Postfix local 配送エージェントを使うことを想定しています:

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

master.cf で Postfix SMTP サーバを chroot して走らせるように しているのであれば、proxy: 部分が必要です。作者による 配布物については、Postfix はどのデーモンも chroot しません。

ローカル受信者テーブルは受信者アドレス (user@domain) および 受信者名 (アドレスから domain を引いたもの) で検索されます。 Postfix は検索結果の見え方を気にしないので、Postfix が理解する どのフォーマットのデータベースでも使うことができます。

Postfix が不正にローカルメールを拒否するのを止めるには:

local_recipient_maps 機能を無効にするには、次のように指定します:

    /etc/postfix/main.cf:
        local_recipient_maps =

この設定では、Postfix SMTP サーバは知らないローカル受信者宛の メールを拒否しません。


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
SENDER
完全な送信者アドレス。
SHELL
受信者のログインシェル。
USER
受信者のユーザ名。

"warning: cannot access UNIX password database" が意味するのは?

このメッセージは、例えば Postfix SMTP サーバが UNIX パスワード データベースにアクセスできないときにログに記録されます。


醜い 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 が MAIL FROM / RCPT TO "| 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
            reject_unauth_destination

    /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 が "User unknown in virtual alias table" といってメールを拒否します

回答: virtual_alias_domains パラメータで指定されたテーブルに バーチャルドメイン名をリストアップしていますが、受信者名が virtual_alias_maps で指定されたテーブルにリストアップされて いません。

Postfix virtual(8) メールボックス配送 エージェントを使って配送したいのであれば、代わりに virtual_mailbox_domains パラメータで指定されたテーブルに バーチャルドメイン名をリストアップします。


Postfix が "User unknown in virtual mailbox table" といってメールを拒否します

回答: virtual_mailbox_domains パラメータで指定されたテーブルに バーチャルドメイン名をリストアップしていますが、受信者名が virtual_mailbox_maps で指定されたテーブルにリストアップされて いません。

それぞれのユーザがローカルまたはリモートの実在するアドレスに エイリアスされる、Postfix の virtual(5) エイリアスドメインとして配送したいのであれば、代わりに virtual_alias_domains パラメータで指定されたテーブルに バーチャルドメイン名をリストアップします。


Postfix が知らないバーチャルユーザ 宛のメールを拒否しません

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

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

解決策:

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

簡単な回答: メールをローカルの Postfix エイリアスに向け直すような "突き抜け" バーチャルエイリアスを設定します。

    /etc/postfix/main.cf:
        virtual_alias_maps = hash:/etc/postfix/virtual

    /etc/postfix/virtual:
        listname@virtual.tld            listname
        owner-listname@virtual.tld      owner-listname
        listname-request@virtual.tld    listname-request

    /etc/aliases:
        listname: "|whatever"
        owner-listname: user@domain
        listname-request: "|whatever"

これはバーチャルアドレス listname@virtual.tld など宛の メールをローカルアドレス listname@your.domain.tld などに 向け直します。そしてこれらのローカルアドレス宛のメールは Postfix local 配送エージェントによって外部コマンドやファイルなどに配送されます。

長い回答:

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

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


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

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

回答: Postfix は元の受信者アドレスを X-Original-To: メッセージヘッダに記録します。


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

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

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

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

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


"Error: too many hops" が意味するのは?

短い回答: このメッセージはメールがループしているかもしれないと いうことを意味します。Postfix コンテンツフィルタを使うようにしてから これを見るようになったのであれば、メールが繰り返しフィルタに かかるような間違いを犯しています。これは content_filter=header_checks=body_checks= を適切に使うことで 直せます。

長い回答: このメッセージには Received: メッセージヘッダが多すぎます。 Received ヘッダは Postfix (などの MTA) がメッセージを受信したときに 毎回加えられます。Received: メッセージヘッダが多いということは メールがループしていることを示します。

サイドコメント: Eメールは IP フォワーディングループを避けるのに 使われるのとは対照的なテクニックを使います。IP では送信者が IP ヘッダのフィールドに TTL (time to live, 有効期間) を設定します。 このフィールドはルータ毎に減らされます。TTL がゼロになると パケットは破棄され ICMP エラーメッセージが送信者に返されます。


Using UUCP over TCP

この問題は「一つのメールボックス内のドメイン」解法に関して 誰かが質問するといつもあがってくるものです。手始めの情報として、 以下に挙げたガイドを参照してください。

インターネット- 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

master.cf ファイルの 1 というプロセス制限は同時に複数の 要求を扱えない fax ソフトウェアで必要です。その他には影響ありません。

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

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

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


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

postsuper コマンドに Postfix メッセージキューファイルを削除する オプションがあります。mailq 出力から得られるであろうキュー id、 ABCDEF を持つメッセージを削除するには、次のように使います:

# postsuper -d ABCDEF

大量のファイルを消すには、次のように使います

# postsuper -d - < filename-with-queue-ids

通常は Postfix システムが動いている最中にこれをおこなっても 安全です。しかし、間違ったキューファイルを削除してしまう可能性が わずかにあります。状況は次のようになります:


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

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

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

以下の文章は他のマシンやバックアップからのキューファイルの リストアの、異なる2つの方法を記述しています。

方法 1: Postfix キューが空で、Postfix release 20010525 以降を 動かしている場合

方法 2: Postfix キューが空でなかったり、Postfix release が 20010525 より前のものを動かしている場合


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 オプションや同等なものをつけて マウントすることです。


Too many connections

このメッセージは MYSQL サーバにより出されたものです。扱える接続数を 増やす必要があります。覚えておくべきこと: virtualcanonical マップは全ての smtpd および cleanup プロセスによりアクセスされます。

write queue file: No such file or directory

write queue file: Unknown error 4294967289

メッセージが message_size_limit 設定を越えた場合に、 ReiserFS は誤ったエラーコードを報告します。結果として、Postfix SMTP サーバは "file too large" ではなく "queue file write error" を SMTP クライアントに報告します。クライアントは期限が来るまで 同じ E メールを何回も送り続けます。
Up one level | Postfix FAQ