Postfix Frequently Asked Questions

• Postfix は Berkeley DB バージョン X 用のファイルを #include したのに対し、Berkeley DB バージョン Y のオブジェクト ライブラリをリンクしてコンパイルされました。ここで、X と Y は違うバージョンの Berkeley DB ライブラリです。

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

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

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

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

解決法

• Rask Ingemann Lambertsen の解決法は特に効果的です :-)

  # /etc/rc.d/init.d/linuxconf stop && rpm --erase linuxconf 
  

• Matthias Andree によると、SuSe へのバンドエイド修正は /etc/permissions.local に次の行を加えます:

  /usr/sbin/sendmail root.root 755
  

  そして、/etc/rc.config で PERMISSIONS_SECURITY の最後に local があるか 確かめます。例:

  CHECK_PERMISSIONS=set
  PERMISSION_SECURITY="secure local"
  

カーネルパラメータをブート時に設定するには、次の行を /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

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

/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 キューにたくさんたまっていても、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

私の 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 の前か後、どちらに使うかを指定します。

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

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

助けて！ 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

• check_relay_domains: 配送先がローカルでなく、クライアントのホスト名が relay_domains にマッチしなかった時に拒否します。
• permit_auth_destination: 配送先がローカルでない時にスキップします。
• reject_unauth_destination: 配送先がローカルでない時に拒否します。
• permit_mx_backup: 配送先がローカルでない時に拒否します。
• その他の UCE 制限 (例えば SMTPD アクセスマップ) は送信者による ルーティング情報には関係ありません。

しかし、プライマリ 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 ホストに導入します。

次に良い方法は古いプレーン 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

    /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

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

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

    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 はうまくいきます。

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

• まず第一に、ホスト名の nslookup の結果は見当違いかもしれません。 Postfix はまず MX レコードの検索を要求します。よって、nslookup テストはまず MX レコードの問い合わせで始めるべきです。 DNS サーバによっては、壊れていて、存在しない MX レコードの問い合わせに 対し応答しないものもあります。

• Postfix master.cf ファイルをチェックして下さい。SMTP クライアントが chroot されて走っている場合、Postfix キュー ディレクトリの中にいくつかのファイルが必要です。配布ソースの examples サブディレクトリに例があります。

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

Cisco PIX "fixup protocol smtp" バグ

バグ 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

しかしメッセージ本体はいくつかのデータグラムとして送られ、それぞれの データグラムはローカルネットワークの 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 メッセージを破棄するルータを見つけ、 責任者に設定を修正するように説得します。

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

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

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

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

• 実在するユーザに向けた root のメールエイリアスを作ります。

  /etc/aliases:
      root:       you
  

• エイリアスデータベースの更新後は毎回 newaliases コマンドを 実行します。

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

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

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

このセクションの情報は 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.name としてメールを送るには、どのドメイン名がが ドメインを持たないアドレスに付加されるかを指定します:

  /etc/postfix/main.cf:
      myorigin = domain.name
  

• root や postmaster のような、一部のユーザをローカルで 受け取るには、デフォルトでない配送先を持つバーチャル検索テーブルを 指定します:

  /etc/postfix/main.cf:
      virtual_maps = hash:/etc/postfix/virtual
  
  /etc/postfix/virtual:
      root        root@localhost
      postmaster  postmaster@localhost
  

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

• virtual テーブルを編集したら、毎回 postmap /etc/postfix/virtual コマンドを実行して下さい。

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

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

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

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

• 全てのメールボックス配送を procmail が行なうように指定します。 例えば:

      /etc/postfix/main.cf:
          mailbox_command = /path/to/procmail
  
      /etc/postfix/main.cf:
          mailbox_command = /path/to/procmail -a $EXTENSION
  

  できることなら、 $ や "、IFS、&& のようなシェルのメタ文字やビルドインを使うのは避けて下さい。 Postfix が負荷の大きなシェルプロセスを使わざるを得なくなります。 しかし、procmail はブタであり、シェルを回避して得られるものはあまり ありません。

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

DOMAIN

受信者アドレスの @ の右側の文字列。

EXTENSION

オプションのアドレス拡張部分。

HOME

受信者のホームディレクトリ。

LOCAL

受信者アドレスの @ の左側の文字列、 例えば $USER+$EXTENSION。

LOGNAME

受信者のユーザ名。

RECIPIENT

受信者アドレス全体、$LOCAL@$DOMAIN。

SHELL

受信者のログインシェル。

USER

受信者のユーザ名。

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

• 幸い、多くのメールユーザエージェントはユーザ毎またはシステム全体に わたる、Delivered-To: ヘッダを伏せるように設定できる設定ファイル (例えば ~/.mailrc や /usr/lib/Mail.rc) を持っています。

• メーリングリストでは、リスト発信者が外行きのメールに現れるべきでは ない「秘密の」エイリアスを使う時に、Delivered-To: は得られて しまいます。お勧めの解決法は、正規表現ベースのフィルタを SMTP ポートに 使うことです。

      /etc/postfix/main.cf:
  	smtpd_recipient_restrictions = 
  	    ... regexp:/etc/postfix/access_regexp ...
  	smtpd_recipient_restrictions = 
  	    ... pcre:/etc/postfix/access_regexp ...
  
      /etc/postfix/access_regexp:
  	/^(.*)-outgoing@(.*)/   554 Use $1@$2 instead
  

  POSIX 正規表現サポート (regexp) は最近の UNIX システムではデフォルトで 使えます。Perl 互換正規表現サポート (pcre) はオプションです; Postfix ソースディレクトリのトップにある PCRE_README ファイルを 参照して下さい。

• prepend_delivered_header 設定パラメータは Delivered-To: が付加される時を制御します。デフォルトの設定は command, file, forward (翻訳: コマンドへの配送、ファイルへの配送、 そしてメールの転送時に Delivered-To: を付加します) です。 メール転送時に Delivered-To: をオフにするのはお勧めできません。

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

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

    /delivered-to/i

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

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

    /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

メッセージヘッダの中身に関しては、header checks 制限に関する ドキュメントも参照してください。これらの制限はコマンド・ファイルを 宛先とする攻撃に対する保護に使われます。例えば、Errors-To: や Return-Receipt_To: メッセージヘッダなど。

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

    /etc/postfix/access:
        all     permit_mynetworks,reject

    /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

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

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

長めの回答を続けます。

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

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

    /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@my.domain から来たように 見せるには、次のように指定します:

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

  ゲートウェイは、アドレスマスカレードをしようとする前に全てのアドレスを FQDN 形式にするために、 append_dot_mydomain と append_at_myorigin をオンにすべきであることに注意して下さい。

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

• ある users、例えば root をマスカレードの例外にするには、 次のように指定します:

      /etc/postfix/main.cf:
          masquerade_exceptions = root
  

• ある hosts をマスカレードの例外にするには、 masquerade_domains をこのように書きます:

      /etc/postfix/main.cf:
          masquerade_domains = somehost.my.domain otherhost.my.domain $mydomain
  

  上の順番が重要であることに注意して下さい: somehost.my.domain のような例外は $mydomain の先に記述しなければいけません。

  この方法で例外扱いしたい特定のホストのメールが始めに user@my.domain として生成されると、これを例外にすることが 難しいのはいうまでもありません。

現在、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 を通して到達したメールから送信者アドレスを抜き出して Postfix の sendmail コマンドにメールを提供する rmail プログラムが 必要です。ほとんどの UNIX システムには rmail ユーティリティが ついてきます。困ったら Postfix のソースコードの auxiliary ディレクトリにバンドルされたものを試してみて下さい。いつか Postfix は独自の rmail コマンドを持つかも知れません。

• 例えば some.domain 宛のメールを UUCP で uucp-host という名前のホストに配送するには、次のように指定します:

      /etc/postfix/transport:
          some.domain     uucp:uucp-host
          .some.domain    uucp:uucp-host
  

  詳細は transport マニュアルページを 参照して下さい。

• transport テーブルを編集したら、毎回 postmap /etc/postfix/transport コマンドを実行して下さい。

• transport テーブルの検索を使います:

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

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

• メールの配送方法を UUCP を使った配送と定義します:

      /etc/postfix/master.cf:
          uucp      unix  -       n       n       -       -       pipe
            flags=F user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
  

  これは uux コマンドを走らせ、next-hop ホスト名 (uucp-host) と受信者をコマンドを実行する前に置き換えます。uux コマンドは シェルの助けなしに実行されるため、シェルのメタ文字に関する問題は ありません。

• some.domain をあなたのサイトがメールを転送するドメインの リストに加えます。

      /etc/postfix/main.cf:
          relay_domains = some.domain $mydestination ...
  

  詳細は relay_domains 設定 パラメータの記述を参照して下さい。

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

• transport テーブルは必要ありません。

• 全てのリモートメールを uucp メール配送を通して UUCP ゲートウェイホスト、uucp-gateway へ送るには、次のように 指定します:

      /etc/postfix/main.cf:
          relayhost = uucp-gateway
          default_transport = uucp
  

• メールの配送方法を UUCP を使った配送と定義します:

      /etc/postfix/master.cf:
          uucp      unix  -       n       n       -       -       pipe
            flags=F user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
  

  これは uux コマンドを走らせ、next-hop ホスト名 (uucp-host) と受信者をコマンドを実行する前に置き換えます。uux コマンドは シェルの助けなしに実行されるため、シェルのメタ文字に関する問題は ありません。

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

ここでは 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 で広めないように気をつけて下さい...

    # 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 はキューファイル名をその 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

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

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

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

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

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

    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 インクルードファイルを取り除きます。

Postfix を db をサポートしない UNIX で db とともに ビルドするには、www.sleepycat.com にある Berkeley DB ソースコードを使うことができます。 Postfix を Sleepycat の Berkeley DB とともにコンパイルする方法の説明は Postfix 配布ソースコードにある DB_README ファイルを参照して下さい。

質問:

クリーンなディスクに 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() ルーチンを使う回避が可能です。