Postfix アドレス検証 Howto


警告 警告 警告

このドキュメントに書かれている送信者/受信者アドレス検証機能は流量が少ない サイトにのみ適しています。負荷が高いとパフォーマンスが悪くなり、プロバイダに よってはサイトをブラックリストに載せてしまうかもしれません。詳細は以下の "制限" セクションを参照してください。

Postfix アドレス検証ができること

アドレス検証はアドレスが配送可能であることを検証するまで Postfix SMTP サーバが送信者 (MAIL FROM) または受信者 (RCPT TO) アドレスをブロック できるようにする機能です。

このテクニックには、応答できない送信者アドレスを持つジャンクメールを拒否 するという明らかな用途があります。

またこのテクニックは、例えば有効な受信者アドレス全てのリストを持たない メール中継ホストで、配送できない受信者に対するメールをブロックするのにも 便利です。これにより配送できないジャンクメールがキューに入らず、Postfix が MAILER-DAEMON メッセージを送り返そうとリソースを無駄にしなくても済みます。

この機能は Postfix バージョン 2.1 以降で使えます。

このドキュメントがカバーしている話題:

アドレス検証の働き方

送信者もしくは受信者アドレスは、実際にはメールを送らずにそのアドレスに 最も近い MTA を探査することで検証されます。最も近い MTA は Postfix 自身かも しれませんし、リモート MTA かもしれません (SMTP の中断)。プローブメッセージは 通常のメールに似ていますが、配送や遅延、バウンスされることはありません; プローブメッセージは常に捨てられます。

インターネット -> Postfix
SMTP
サーバ
<-> Postfix
verify
サーバ
<-> アドレス
検証
データベース
|
プローブ
メッセージ
v
^
配送
状態
|
Postfix
キュー
-> Postfix
配送
エージェント

Postfix アドレス検証が有効になっていると、通常のメールは最初、アドレスが 検証される最大6秒というほんの短い間待たされます。一旦アドレス状態がわかると、 状態はキャッシュされて Postfix はすぐに応答します。

検証に時間がかかりすぎると、Postfix SMTP サーバは送信者または受信者 アドレスを 450 応答で遅延します。普通のメールクライアントはしばらく遅延を おいて再び接続します。アドレス検証の遅延は main.cf の address_verify_poll_count および address_verify_poll_delay パラメータで設定可能です。詳細は postconf(5) を 参照してください。

アドレス検証の制限

受信者アドレスの検証

前に述べたように、受信者アドレス検証は、全ての有効な受信者アドレスのリストを 持たないメールリレーホストで配送できない受信者宛のメールをブロックするのに 便利です。これはメールキューが MAILER-DAEMON メッセージで埋め尽くされないように するのに役立つでしょう。

受信者アドレス検証は比較的単純で、意外なことはありません。受信者検証に 失敗すると、Postfix はその受信者アドレス宛のメールを拒否します。受信者検証に 成功すると、Postfix はその受信者アドレス宛のメールを受け付けます。

/etc/postfix/main.cf:
    smtpd_recipient_restrictions = 
        permit_mynetworks
        reject_unauth_destination
        ...
        reject_unknown_recipient_domain
        reject_unverified_recipient
        ...

"reject_unknown_recipient_domain" 制限は存在しないドメイン宛のメールを 拒否します。これを "reject_unverified_recipient" の前に置くことで、不必要な検証メッセージを生成することによるオーバーヘッドが 避けられます。

unverified_recipient_reject_code パラメータ (デフォルト 450) には、受信者アドレスがバウンスするとわかって いるときに Postfix がどのように応答するかを指定します。Postfix の判断を 信頼するのであれば、この設定を 550 に変えてください。

頻繁に騙られるドメインからのメールの送信者アドレスの検証

騙られたEメールによく現れる特定のドメインに対して送信者アドレス検証を 有効にするのは比較的安全です。

/etc/postfix/main.cf:
    smtpd_sender_restrictions = hash:/etc/postfix/sender_access
    unverified_sender_reject_code = 550
    # 注意1: 以下の "キャッシング"セクションをよく読んでください!
    # 注意2: ここでは hash ファイルを避け、代わりに btree を使ってください。
    address_verify_map = btree:/var/mta/verify
 
/etc/postfix/sender_access:
    aol.com     reject_unverified_sender
    hotmail.com reject_unverified_sender
    bigfoot.com reject_unverified_sender
    ... etcetera ...

よく騙られる MAIL FROM ドメインのリストは http://www.monkeys.com/anti-spam/filtering/sender-domain-validate.in にあります。

注意: まずはあなた自身のドメイン全てに対する送信者アドレス検証を有効に するのがよいでしょう。

メール全ての送信者アドレスの検証

残念ながら、送信者アドレス検証はEメール全てに対しては簡単に有効に できません - 設定が間違ったシステムからの正規のメールを失ってしまうかも しれません。まず間違いなく特定のアドレス、もしくはドメイン全体に対して ホワイトリストを設定する必要があるでしょう。

送信者アドレス検証のメールへの影響を知るには、どのメールがブロック されることになるかを知るために "warn_if_reject reject_unverified_sender" を指定します:

/etc/postfix/main.cf:
    smtpd_sender_restrictions = 
        permit_mynetworks
        ... 
        check_sender_access hash:/etc/postfix/sender_access
        reject_unknown_sender_domain
        warn_if_reject reject_unverified_sender 
        ...
    # 注意1: 以下の "キャッシング" セクションをよく読んでください!
    # 注意2: ここでは hash ファイルを避け、代わりに btree を使ってください。
    address_verify_map = btree:/var/mta/verify

実際にメールを拒否し始める前に、アドレス検証結果のキャッシュを集めて おくのもよいでしょう。

sender_access 制限には OK とわかっているドメインやアドレスをホワイト リストにリストアップしておく必要があります。Postfix は検証に失敗しても、 よいとわかっているアドレスをダメとマークはしませんが、用心するに越したことは ありません。

注意: securityfocus.com などのように、それぞれの投稿に対して異なる送信者 アドレス (VERP) を使っているメーリングリストを運営しているサイトをホワイト リストにリストアップしておく必要があるでしょう。そのようなアドレスはアドレス 検証キャッシュをすぐに汚染し、不必要な送信者検証プローブを生成することに なります。

/etc/postfix/sender_access
    securityfocus.com OK
    ...

"reject_unknown_sender_domain" 制限は存在しないドメインからのメールをブロックします。これを "reject_unverified_sender" の前に置くことで、不必要なプローブメッセージを生成するオーバーヘッドが 避けられます。

unverified_sender_reject_code パラメータ (デフォルト 450) には、送信者アドレスがバウンスするとわかって いるときに Postfix がどのように応答するかを指定します。Postfix の判断を 信頼するのであれば、この設定を 550 に変えてください。

アドレス検証データベース

注意: デフォルトでは、アドレス検証情報は永続的なファイルには保管 されません。main.cf でファイルを指定しなければいけません (以下参照)。 永続的な保管はファイルシステムで使える以上のディスクスペースが必要に なるかもしれないため、デフォルトでは無効になっています。

アドレス検証情報は Postfix verify デーモンによってキャッシュされます。 Postfix には肯定的および否定的な結果のキャッシュを制御する一連のパラメータが あります。詳細はverify(8) マニュアルページを 参照してください。

address_verify_map (注意: 単数) 設定パラメータにはオプションで送信者アドレス検証結果の 永続的データベースを指定します。ファイルを指定しないと、アドレス検証情報は 全て "postfix reload" または "postfix stop" の後で失われます。

/var ファイルシステムに十分な空きがあれば、以下を試してください:

/etc/postfix/main.cf:
    # 注意: ここでは hash ファイルを避け、代わりに btree を使ってください。
    address_verify_map = btree:/var/mta/verify

注意: スペースを使い果たすようなファイルシステムにはこのファイルを 置かないでください。アドレス検証テーブルが壊れると、世界は終末に至り、 次のセクションにかかれているように「あなたが手動で」事態を修復しなければ いけません。それまでの間、SMTP でメールを受け取れなくなります。

verify(8) デーモンプロセスは、データベースが なければ新たに作成し、chroot 監獄に入ったり root 権限を落とす前にファイルを オープン/作成します。

アドレス検証データベースの管理

verify(8) マニュアルページには、キャッシュ されて残る情報が更新されるまでの期間や、"更新されずに" 残っている情報の 期限が切れるまでの期間を制御するパラメータが記述されています。Postfix は、 肯定的な結果 (アドレスが受け付けられる) と否定的な結果 (アドレスが拒否される) に対しての制御が異なります。

現在は、アドレス検証データベースを管理するツールは提供されていません。 ファイルが大きくなりすぎたりファイルが壊れたら、手動でファイルをリネームしたり 削除して "postfix reload" を実行することができます。そうすることで、新しい verify デーモンプロセスが新しいデータベースを作れるようになります。

アドレス検証プローブのルーティング制御

デフォルトでは、Postfix は通常のメールと同じルートでアドレス検証プローブ メッセージを送ります。これはたいてい最も適切な結果になるためです。ローカル アドレスを自分自身の SMTP ポートに接続して検証するのはよいことではありません; 単に様々なメーラループ警告を呼び起こすだけです。自分のマシンが最適な MX ホストになっている配送先にも同じことが当てはまります: 隠しドメイン、 バーチャルドメインなど。

しかし、メールが直接インターネットに送られず、代わりの relayhost に送られるような、 複雑なインフラストラクチャを持つサイトがあります。Postfix は直接リモートの 配送先にアクセスできるときにしかリモートのインターネットアドレスが 検証できないので、これは問題になります。

そのため、Postfix はアドレス検証プローブメッセージを配送する際の ルーティングパラメータを上書きすることができます。

はじめに、 address_verify_relayhost パラメータで relayhost 設定を上書き でき、 address_verify_transport_maps パラメータで transport_maps 設定を上書きできます。

次に、アドレスクラスは以下の表に示すように、それぞれのアドレス検証版の メッセージ配送 transport に与えられます。アドレスクラスは ADDRESS_CLASS_README ファイルで 定義されています。

ドメインリスト 通常の transport 検証用 transport
mydestination local_transport address_verify_local_transport
virtual_alias_domains (非該当) (非該当)
virtual_mailbox_domains virtual_transport address_verify_virtual_transport
relay_domains relay_transport address_verify_relay_transport
(非該当) default_transport address_verify_default_transport

デフォルトでは、アドレスプローブの配送を制御するパラメータは通常のメール 配送を制御するパラメータと同じ値を持っています。

プローブルーティングを強制する例

アドレス検証プローブに対しては relayhost 設定を上書きし、それ以外は そのまま残しておくというのが典型的な筋書きです:

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

ネットワークアドレス変換器 (nat) の背後にあるサイトは正しいホスト名情報を 送る別の SMTP クライアントを使わなければいけないかもしれません:

/etc/postfix/main.cf:
    relayhost = $mydomain
    address_verify_relayhost =
    address_verify_default_transport = direct_smtp

/etc/postfix/master.cf:
    direct_smtp .. .. .. ..  .. .. .. .. .. smtp
        -o smtp_helo_name=nat.box.tld

プローブルーティングの強制における制限

プローブメッセージが通常のメールと同じ道をたどらないと不整合が起こる可能性が あります。たとえば、通常のルートをたどればメッセージが受け付けられるが、 同定するプローブメッセージがルートを強制された場合に拒否されることがあります。 逆もあり得ますが、それほど多くはありません。