Postfix Frequently Asked Questions Postfix Frequently Asked Questions
Postfix でうまく使えるソフトウェアの例:
Postfix は全てのパラメータがまともなデフォルト値を持つため、以下の
文章では上書きする物のみを示します。特に、Postfix は自分と同じ
サブネットワークからのメールのみを中継します。ネットワークや
マシンが非常に低速もしくは高速であれば、master.cf (inetd.conf と
いくぶん似ています) をチューンする必要があります。
ワークステーション:
サーバ:
このような環境で、メールスプールディレクトリが NFS で共有されているか、
ユーザがメールボックスに POP でアクセスするか、ユーザが自分のワーク
ステーションでメールを受けるかのいずれかでしょう。後者の場合、それぞれ
のユーザはメールをそれぞれのワークステーションに転送するようにサーバに
エイリアスを持ちます:
Server:
エイリアスデータベースが /etc/aliases にないシステムもあります。
あなたのシステムでの場所を探すには、postconf alias_maps
コマンドを実行します。
次の例では、メールは user@domain として送信され、全てのメールは
ローカルドメインを受け持つメールサーバに転送されます。
メールは全て user@nullclient ではなく user@domain として送信される
ため、user@nullclient 宛のメールアドレスに対するメールサーバの特別な
設定は必要ありません。
これはあなたの組織がローカルドメイン用に内部 MX レコードを構築して
いることを想定しています。
あなたのイントラネットが MX レコードを内部で使用していなければ、
イントラネットメールゲートウェイ自身を指定する必要があります:
あなたのイントラネットが DNS を内部で使用していなければ、同様に
DNS 検索も止める必要があります:
インターネットドメインへのデフォルトのルーティング情報をtransport テーブルで指定し、transport テーブル検索をおこないます。
重要: main.cf に relayhost を指定しないでください。
内部の配送先宛のメールも relayhost に渡されてしまいます。
システムが db の代わりに dbm ファイルを使って
いれば、dbm:/etc/postfix/transport を指定します。Postfix が
どのマップ形式をサポートしているかを見るには、postconf -m
コマンドを使います。
transport テーブルを編集したら、毎回
postmap /etc/postfix/transport コマンドを実行して下さい。
ファイアウォールマシン上の Postfix を、my.domain 宛のメールを
内部のゲートウェイマシンに転送し、*.my.domain 宛のメールを
拒否するように設定する方法は？ 問題は標準の relay_domains メール中継制限では
my.domain を指定すると *.my.domain へのメールも
許してしまうことです。
ローカルシステムがあらゆる場所にメールを送れ、リモートシステムが
user@domain.com だけにメールを送れるように、明示的に
smtpd_recipient_restrictions
と mynetworks の設定をします。
(スパマーからの配送できないメールでキューが埋め尽くされないように
するために) 存在するユーザを指定してください。
受信者情報を維持するのが実用的でなければ、
local_recipient_maps = を指定します。
システムが db の代わりに dbm ファイルを使って
いれば、dbm:/etc/postfix/transport を指定します。Postfix が
どのマップ形式をサポートしているかを見るには、postconf -m
コマンドを使います。
Postfix 警告およびエラーメッセージ
設定例
Sendmail との非互換性
数百の Postfix プロセスを走らせる
Postfix のパフォーマンス
ネットワーク経由でのメール受信
メールの中継
リモート配送
ローカル (非バーチャル) 配送
メーリングリスト
バーチャルドメイン
アドレスの書き換え
コンテンツフィルタリング
他の配送方法: UUCP, FAX, etc.
Postfix キューのメンテナンス
Postfix のコンパイルとインストール
特定のオペレーティングシステムでの問題
Compaq での問題
IRIX での問題
POP や IMAP の問題
Postfix はメール配送システムです。メールを読むための POP や IMAP
といったサービスは Postfix は実装していません。Postfix のような
ソフトウェアと協力できる POP/IMAP の実装がいくつかあります。
スタンドアロンマシン
インターネットに直接アクセスできるスタンドアロンマシンでは、Postfix
は設定の変更なしにすぐに動くはずです。少なくとも、それが Postfix の
ソースコードをダウンロードした時のインストールされる状態です。
マシンがファイアウォールのあるイントラネット内にあったり、短時間だけ
ダイアルアップで接続されるのであれば、関連するセクションを
参照して下さい。
ワークステーションとサーバ
このセクションでは、ワークステーション・サーバ環境について記述します。
ここでは全てのシステムはメールを user@domain として送信し、
user@hostname 宛のメールを受け取るものとします。サーバは
user@domain 宛のメールも受け取ります。
/etc/postfix/main.cf:
myorigin = $mydomain
/etc/postfix/main.cf:
myorigin = $mydomain
mydestination = $myhostname, localhost.$mydomain, $mydomain
/etc/aliases:
joe: joe@joes.workstation
jane: jane@janes.workstation
Null クライアント
Null クライアントはメールの送信のみできるマシンです。ネットワーク
からはメールを受け取らず、ローカルへの配送も全くおこないません。
Null クライアントでは、メールボックスへのアクセスは典型的には
POP または NFS を使います。
/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
イントラネットでの Postfix の利用
ファイアウォール内のネットワークのホストで Postfix を設定する最も
簡単な方法は、全てのメールをイントラネットメールゲートウェイに
送り、メールゲートウェイに転送を任せるようにするものです。
/etc/postfix/main.cf:
myorigin = $mydomain
/etc/postfix/main.cf:
relayhost = $mydomain
/etc/postfix/main.cf:
relayhost = host.my.domain
/etc/postfix/main.cf:
disable_dns_lookups = yes
/etc/postfix/transport:
my.domain :
.my.domain :
* smtp:gateway.my.domain
/etc/postfix/main.cf:
transport_maps = hash:/etc/postfix/transport
ファイアウォール上での Postfix の利用
注意: この文章は Postfix のバージョン 2.0 以降で使えます。
Postfix のバージョンを調べるには、postconf mail_version
コマンドを実行します。
/etc/postfix/main.cf:
myorigin = domain.com
mydestination = domain.com
local_recipient_maps = hash:/etc/postfix/recipients
transport_maps = hash:/etc/postfix/transport
mynetworks = 12.34.56.0/24
smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination
local_transport = error:local mail delivery is disabled on this machine
/etc/postfix/transport:
domain.com smtp:inside-gateway.domain.com forwards user@domain.com
/etc/postfix/master.cf:
local 配送エージェントをコメントアウト
ダイアルアップマシンでの Postfix の利用
このセクションは多くの時間接続が切れているダイアルアップ接続に
当てはまります。常時接続のダイアルアップ接続は、代わりに ワークステーションとサーバ セクションを
見てください。
自分自身のホスト名を持っておらず (動的 IP 割り当て)、必ず user@your-isp.com としてメールを送るのであれば、次のセクションの user@domain としてメールを送る際に、 あるユーザはローカルに配送したい も検討すべきです。
マシンがほとんどの時間接続されていないのであれば、Postfix がメールを 到達が難しい場所へ配送する機会はあまり多くありません。メールを 常時接続されたマシンへ送るのがよいでしょう。
/etc/postfix/main.cf:
relayhost = smtprelay.someprovider.com
通常、Postfix は都合が良い時に外行きのメールを配送しようとします。 マシンがオンデマンドダイアルアップ IP を使っていれば、あなたが新しい メールを送信したり、Postfix が遅延メールを配送しようと試みるたびに システムは電話の呼び出しをします。このようなコールがなされるのを 防ぐには、自動 SMTP メール配送を禁止します。
/etc/postfix/main.cf:
defer_transports = smtp (オンデマンドダイアルアップ IP を使うシステムのみ)
ほとんどの時間切り離された LAN を通して Postfix を使ってメールを配送 したい人もいるでしょう。このような状況下では、メール配送は Postfix の SMTP クライアントが標準に準拠するために送信先および受信元の DNS 検索を しようとする際に遅延に苦しめられるでしょう。このような遅延を防ぐには、 全ての SMTP クライアントの DNS 検索を使わないようにします。
/etc/postfix/main.cf:
disable_dns_lookups = yes (ほとんどの時間切り離された LAN を通した配送のみ)
DNS 検索を使わない場合、relayhost として IP アドレス または一つまたはそれ以上に解決されるホスト名のどちらかを指定しなければ いけません (DNS 検索を使用不可にすると、Postfix は MX 検索を 行ないません)。
次のコマンドを PPP または SLIP ダイアルアップスクリプトに加えます:
sendmail コマンドの正確な場所はシステムに依存します。UNIX の 一部のバージョンでは /usr/lib/sendmail を使って下さい。
キューがフラッシュされたかどうかを見るには、このようなシェルを使います:
#!/bin/sh
# Start deliveries.
/usr/sbin/sendmail -q
# Allow deliveries to start.
sleep 10
# Loop until all messages have been tried at least once.
while mailq | grep '^[^ ]*\*' >/dev/null
do
sleep 10
done
メールの自動配送 を使用しないので あれば、新たにポストされたメールをキューから出すために、 ダイアルアップ接続が確立している間、時々上のコマンドを実行する 必要があります。
Postfix のような分散されたメールシステムでは、実装するのは困難です。 Sendmail とは違い、Postfix のメール配送プロセスはどれもユーザによる 制御下では動きません。代わりに Postfix はユーザプロセスに親子関係の ないデーモンプロセスがメールを配送します。これは非常にさまざまな、 環境変数やシグナルハンドラ、その他 UNIX の親プロセスから子プロセスへ 渡すプロセスの性質による、潜在的セキュリティ問題をなくします。
Postfix はお互いにサブシステムを隔離するために複数のプロセスを 使います。配送エージェントがユーザプロセスと直接やりとりするのは Postfix を普通のメーラよりも安全にしようとしてきた努力をふいにして しまいます。
Sendmail を使っていた時は、4時間後にメールの配送が遅れているという メールが常に送信者に戻ってきました。
Postfix が "delayed mail" 通知を4時間後に送るようにするには、次のように 指定します:
/etc/postfix/main.cf:
delay_warning_time = 4h
Postfix ではメールの遅延通知はデフォルトではおこないません - 常に大量のメールを受け取ることになってしまうので。
これが「正しい」動作であると主張する人さえいます。おそらくは 期待や慣れの問題でしょう。
これは Postfix を遅くすることでのみ「修正できます」。上の例では、 Postfix は配送を始める前に、まず完全に全ての配送リストを展開する必要が あります。設計では Postfix は異なる配送先へのメールは並列に配送し、 ローカルも例外ではありません。これが Postfix が sendmail よりも速い 理由です。
Wietse は Postfix の実装が「正しい」動作だと信じており、sendmail の デフォルトの動作は sendmail がエイリアスループを避けるのに あいまいなアルゴリズムを使っていた時の暗い部分の名残ではないかと 疑っています。
しかし、Postfix の作為的な実装による結果、owner-foo エイリアスは エイリアス展開が終わった後のみにしか効果がありません。
コマンドやファイルへの配送を含む、エイリアス展開中に起こった配送問題は 元のエンベロープの送信者アドレスに報告されます。
理由は、送信者アドレスが置き換えられていることを知らない Postfix キューマネージャによりバウンスが送られるためです。
この制限は Postfix ローカル配送エージェントが配送できないメールを 取り扱う方法を変えることで修正されるでしょう。
問題を修正するには、 root で次のコマンドを実行して下さい:
# newaliases
これは Postfix が期待する形式の aliases.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 システムは異なる名前を 使うかも知れません。通常のマイレージなどの免責事項が適用されます (訳注: 環境によってコマンド名などが違うので、各自の状況に応じて 対応して下さいの意)。
# /etc/rc.d/init.d/linuxconf stop && rpm --erase linuxconf
そして、/etc/rc.config で PERMISSIONS_SECURITY の最後に local があるか 確かめます。例:/usr/sbin/sendmail root.root 755
CHECK_PERMISSIONS=set PERMISSION_SECURITY="secure local"
エンベロープ送信者アドレスは、メッセージで From: ヘッダアドレスが 指定されない場合のデフォルト値にもなります。
修正するには、sendmail コマンドラインでエンベロープ送信者アドレスを 指定します:
sendmail -f user@domain ...
次のカーネルパラメータをブート時に設定するには、次の行を /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 をセットすることができます。
次の情報はカーネルのバージョンに依存します。
/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
* set hard limit on file descriptors set rlim_fd_max = 4096 * set soft limit on file descriptors set rlim_fd_cur = 2048
% make tidy % make makefiles "CCARGS=-DFD_SETSIZE=2048" % make
メールが incoming キューにたくさんたまっていても、Postfix は外行きの SMTP 配送を少ししか実行しません。なぜもっと SMTP クライアントを動かさないのでしょう？
問題は以下のうちの一つかもしれません。
/etc/postfix/main.cf:
transport_maps = hash:/etc/postfix/transport
deadbeats_destination_concurrency_limit = 50
/etc/postfix/transport:
hotmail.com deadbeats:
yahoo.com deadbeats:
/etc/postfix/master.cf:
deadbeats unix - - n - - smtp
-o smtp_connect_timeout=5 -o smtp_helo_timeout=5
/etc/postfix/main.cf:
mydestination = my.own.host.name
relay_domains = my.corp.domain
relay_transport = relay
/etc/postfix/master.cf:
relay unix - - n - - smtp
-o smtp_connect_timeout=2 -o smtp_helo_timeout=2
より速いディスクを使うか、ロギングやメールキュー、メールボックスに 別のディスクドライブを使うことで問題を解決します。
現在のところの解決策は、一つのマシンに複数の 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) 遅延なく応答が返ります。
回答:
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 アドレスで取ります。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 ディレクトリ内のファイルを見て下さい。
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 を開けるようにするために 存在します。つまり、単なる実装の産物です。
このスキームはユーザを認証しないため、いくつかの方法でバイパスできて しまいます:
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
ある他のドメインのプライマリ 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 コマンドを使います。
リモートアドレスのメールサーバに接続すると、次のようになります:
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 はうまくいきます。
いくつかの異なる問題があり得ます。
しかし、いつもメール配送が失敗するのを目撃する場合には、他の問題を 抱えているかも知れません: 壊れたパス MTU 発見プロトコル。もしくは 壊れた PIX ファイアウォールかも知れません。
バグ 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
しかしメッセージ本体はいくつかのデータグラムとして送られ、それぞれの データグラムはローカルネットワークの 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 が SMTP 接続キャッシングを実装するときに 最終的に解決されます。
chroot 操作はシステムへの侵入者に対する重要な壁を作ります。
2つの解法があります:
"unknown mail transport error" の原因を見つけるには、次のコマンドを タイプします:
egrep '(warning|fatal|panic):' /var/log/maillog | lessfatal や panic のラベルがついたメッセージには特に 注意を払って下さい。これらは Postfix が幸せに動くために取り組まれる 必要がある、破壊的な失敗を記述しています。fatal のラベルが 付けられた問題は、設定ファイルやファイルの権限などを調整することで、 あなたが修正します。panic のラベルが付けられた問題は Postfix の作者が Postfix のソースコードを変更することで修正します。
解決策: (異常な条件を除いて) root としてログインすることを 考えないのと同様に、root でメールを受け取らないようにします。
/etc/aliases:
root: you
エイリアスデータベースが /etc/aliases にないシステムもあります。 あなたのシステムでの場所を探すには、postconf alias_maps コマンドを実行します。
その Postfix 警告メッセージは comsat ネットワークサービスが off になっていて、新着メール通知が失敗したことを意味しています。
Postfix 配送エージェントの comsat クライアントコードを 使用不可にするには、次のように指定します:
/etc/postfix/main.cf:
biff = no
注意: 最近のバージョンの procmail も biff 通知を 発行します。完全に biff を黙らせるには procmail 設定ファイルも更新する必要があるでしょう。
comsat ネットワークサービスを使用可能にするには、 inetd.conf ファイル内の対応するエントリのコメントを外します。
この警告メッセージは NIS (Network Information Service) が有効になって いないことを意味します。全く問題ありません。Postfix が前もってこのことを 知るのはかなり困難です。
Postfix local 配送エージェントの NIS クライアントコードを無効に するには、main.cf ファイルの対応するセクションを更新し、 エイリアスファイルの形式によって次のどれか一つを指定します:
/etc/postfix/main.cf:
alias_maps = $alias_database
これは、ローカルのエイリアスデータベースが定義されていれば、 Postfix がそれだけを使うように強制します。
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 サーバは知らないローカル受信者宛の メールを拒否しません。
/etc/postfix/main.cf:
myorigin = domain.tld
/etc/postfix/main.cf:
virtual_alias_maps = hash:/etc/postfix/virtual
/etc/postfix/virtual:
root root@localhost
postmaster postmaster@localhost
システムが db ファイルの代わりに dbm ファイルを 使っているのであれば、hash の代わりに dbm を指定します。 Postfix がどのマップタイプをサポートしているかを知るには、 postconf -m コマンドを使います。
変更を反映するには、postfix reload コマンドを実行します。
/etc/postfix/main.cf:
home_mailbox = Maildir/
どんな相対パス名も / で終わると maildir 配送にします。 home_mailbox の値がユーザのホームディレクトリのパス名に付加 されます。
maildir フォーマットは .forward ファイルを通した 配送でもサポートされています。/file/name/ を配送先として 指定して下さい。最後に / がつくと maildir 配送をします。
/etc/postfix/main.cf:
mailbox_command = /path/to/procmail
/etc/postfix/main.cf:
mailbox_command = /path/to/procmail -a $EXTENSION
できることなら、 $ や "、IFS、&& のようなシェルのメタ文字やビルドインを使うのは避けて下さい。 Postfix が負荷の大きなシェルプロセスを使わざるを得なくなります。 しかし、procmail はブタであり、シェルを回避して得られるものはあまり ありません。
- DOMAIN
- 受信者アドレスの @ の右側の文字列。
- EXTENSION
- オプションのアドレス拡張部分。
- HOME
- 受信者のホームディレクトリ。
- LOCAL
- 受信者アドレスの @ の左側の文字列、 例えば $USER+$EXTENSION。
- LOGNAME
- 受信者のユーザ名。
- RECIPIENT
- 受信者アドレス全体、$LOCAL@$DOMAIN。
- SENDER
- 完全な送信者アドレス。
- SHELL
- 受信者のログインシェル。
- USER
- 受信者のユーザ名。
/etc/postfix/main.cf:
local_recipient_maps = proxy:unix:passwd.byname $alias_maps ...
解決策、戦いの兆候から Delivered-To: ヘッダをオフにするまで:
/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 ファイルを 参照して下さい。
FAQ の Majordomo での approve コマンドの問題の項目も参照して下さい。
今のところ、推奨する回避方法は以下にマッチするあらゆるヘッダを取り除く ように approve スクリプトを編集することです:
/delivered-to/i
はい、これはモデレータが自分が何をしているか知っていることを 想定しています。
あまりお勧めしない回避方法は、majordomo のようなコマンドへの配送 時には Delivered-To: を挿入しないことです。 FAQ の 醜い Delivered-To: ヘッダを取り除きたい というエントリを参照して下さい。
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 virtual(8) メールボックス配送 エージェントを使って配送したいのであれば、代わりに virtual_mailbox_domains パラメータで指定されたテーブルに バーチャルドメイン名をリストアップします。
それぞれのユーザがローカルまたはリモートの実在するアドレスに エイリアスされる、Postfix の virtual(5) エイリアスドメインとして配送したいのであれば、代わりに virtual_alias_domains パラメータで指定されたテーブルに バーチャルドメイン名をリストアップします。
簡単な回答: メールをローカルの 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 は元の受信者アドレスを X-Original-To: メッセージヘッダに記録します。
アドレスマスカレーディングはメールゲートウェイでのみ使うことを 意図しています。
/etc/postfix/main.cf:
masquerade_domains = $mydomain
ゲートウェイは、アドレスマスカレードをしようとする前に全てのアドレスを FQDN 形式にするために、 append_dot_mydomain と append_at_myorigin をオンにすべきであることに注意して下さい。
場合によっては、あるユーザやホストをマスカレードの例外にしたいかも しれません。
/etc/postfix/main.cf:
masquerade_exceptions = root
/etc/postfix/main.cf:
masquerade_domains = somehost.my.domain otherhost.my.domain $mydomain
上の順番が重要であることに注意して下さい: somehost.my.domain のような例外は $mydomain の先に記述しなければいけません。
この方法で例外扱いしたい特定のホストのメールが始めに user@my.domain として生成されると、これを例外にすることが 難しいのはいうまでもありません。
長い回答: このメッセージには Received: メッセージヘッダが多すぎます。 Received ヘッダは Postfix (などの MTA) がメッセージを受信したときに 毎回加えられます。Received: メッセージヘッダが多いということは メールがループしていることを示します。
サイドコメント: Eメールは IP フォワーディングループを避けるのに 使われるのとは対照的なテクニックを使います。IP では送信者が IP ヘッダのフィールドに TTL (time to live, 有効期間) を設定します。 このフィールドはルータ毎に減らされます。TTL がゼロになると パケットは破棄され ICMP エラーメッセージが送信者に返されます。
/etc/postfix/transport:
some.domain uucp:uucp-host
.some.domain uucp:uucp-host
詳細は transport マニュアルページを 参照して下さい。
/etc/postfix/main.cf:
transport_maps = hash:/etc/postfix/transport
システムが db ファイルの代わりに dbm ファイルを 使っているのであれば、hash の代わりに dbm を指定します。 Postfix がどのマップタイプをサポートしているかを知るには、 postconf -m コマンドを使います。
/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 コマンドは シェルの助けなしに実行されるため、シェルのメタ文字に関する問題は ありません。
/etc/postfix/main.cf:
relay_domains = some.domain $mydestination ...
詳細は relay_domains 設定 パラメータの記述を参照して下さい。
変更を反映するには、postfix reload コマンドを実行します。
/etc/postfix/main.cf:
relayhost = uucp-gateway
default_transport = 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
master.cf ファイルの 1 というプロセス制限は同時に複数の 要求を扱えない fax ソフトウェアで必要です。その他には影響ありません。
fax_destination_recipient_limit エントリ (by Simon, Mr. Simix) は複数の送信先をコマンドラインで指定できない FAX ソフトウェアの 場合に必要です。他への影響はありません。
システムが db ファイルの代わりに dbm ファイルを 使っているのであれば、hash の代わりに dbm を指定します。 Postfix がどのマップタイプをサポートしているかを知るには、 postconf -m コマンドを使います。
注意: fax.your.domain を DNS で広めないように気をつけて下さい :-)
# postsuper -d ABCDEF
大量のファイルを消すには、次のように使います
# postsuper -d - < filename-with-queue-ids
通常は Postfix システムが動いている最中にこれをおこなっても 安全です。しかし、間違ったキューファイルを削除してしまう可能性が わずかにあります。状況は次のようになります:
Postfix はキューファイル名をその inode 番号と日時のマイクロ秒部分から 名付けます。こうして、キューファイルに他の inode 番号に基づく名前が ついていると、わずかながらファイル名が別のキューファイルとぶつかる 可能性があります。
以下の文章は他のマシンやバックアップからのキューファイルの リストアの、異なる2つの方法を記述しています。
# postfix stop
# mailq
# cd /var/spool/postfix ...restore maildrop, incoming, active, deferred, defer, bounce here...
# postsuper
# postfix stop
# cd /var/spool/postfix/maildrop ...restore incoming, active, deferred here...
# find incoming active deferred -type f -exec mv '{}' . ';'
# rm -rf incoming active deferred
# postfix start
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 ファイルを参照して下さい。
gcc を使わなければならないのであれば、 http://www.isc.org/ にある BIND のソースコードの inet_ntoa() ルーチンを使う回避が可能です。
Postfix はメッセージを受け取ったことを示すためにキューファイルに 実行ビットをセットします。キューファイルが実行ビットを持たない限り、 Postfix は「メールはまだ受信中」として無視します。
拡張セキュリティが有効になっていると、Compaq Tru64 UNIX は スーパーユーザ以外が実行ビットをキューファイルに立てようとするのを 認めないという機能を持ちます。不幸にも、Postfix はそのような 試みが失敗したことを知らされず、メールがブラックホールに消えたように 見えてしまいます。
Postfix は実行ビット以外のビットを使うように変更できますが、それは 同様に他のシステムで失敗するかも知れません。他の可能性はスーパーユーザ 以外でも実行ビットをファイルに立てることを許可し、Postfix キュー ファイルシステムを noexec オプションや同等なものをつけて マウントすることです。