Postfix アドレス検証 HowtoPostfix アドレス検証 Howtoこのドキュメントに書かれている送信者/受信者アドレス検証機能は流量が少ない サイトにのみ適しています。負荷が高いとパフォーマンスが悪くなり、プロバイダに よってはサイトをブラックリストに載せてしまうかもしれません。詳細は以下の "制限" セクションを参照してください。
アドレス検証はアドレスが配送可能であることを検証するまで 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) を 参照してください。
リモートアドレスを検証する場合、Postfixは検証するアドレスに対して 最も近いMTAを、実際にそのアドレスにメールは送らずに探査します。最も近い MTAがそのアドレスを受け付けると、Postfixは配送可能と見なします。実際には 最も近いMTAが受信者アドレスを受けた「後で」リモートアドレス宛のメールを バウンスするかもしれません。
頻繁に探査しすぎたり (プローブはメールを配送しないSMTPセッション です)、存在しないアドレスに対して頻繁に探査しすぎると、あなたをブラック リストに載せてしまうサイトもあるかもしれません。これが大量のEメールを 受け取るサイトでは、たとえ使うとしても、送信者アドレス検証を慎重に 使うべきであるという理由の一つです。
通常、アドレス検証メッセージは普通のメールと同じ道筋をたどります。 しかし、途中の relayhost; を 経由してインターネットにメールを送るサイトもあります; これではアドレス 検証ができません。メールのルーティングを上書きする方法やこれを おこなわなければいけない場合にあり得る制限は、以下の "アドレス検証プローブのルーティング制御" セクションを参照してください。
検証するアドレスに対して最も近い MTA が探査を拒否すると、拒否の理由 (クライアントの拒否、HELO の拒否、MAIL FROM の拒否など) にかかわらず、 Postfix は配送できないと見なします。こうして、送信者の MTA があなたの マシンからのメールを拒否した場合に Postfix はメールを拒否します。これは よいことです。
残念ながら、YAHOO のような大手のサイトには RCPT TO コマンドに対しては 知らないアドレスを拒否せず、メッセージが送られた後の DATA の終わりで 配送失敗を報告するものがあります。Postfix アドレス検証は、そのような サイトでは働きません。
デフォルトでは、Postfix 検証メッセージは送信者アドレスとして "postmaster@$myorigin" を使います。これは Postfix SMTP サーバがこのアドレス宛のメールを拒否 しないので「安全」です。
これを null アドレスに変えることもできます ("address_verify_sender =")。 これは MAIL FROM: <> を拒否するような間違った設定がなされたサイトでは、 "postmaster@$myorigin" からの探査は 成功するが、null アドレスではアドレス探査が失敗してしまうので「安全では ありません」。
前に述べたように、受信者アドレス検証は、全ての有効な受信者アドレスのリストを 持たないメールリレーホストで配送できない受信者宛のメールをブロックするのに 便利です。これはメールキューが 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
プローブメッセージが通常のメールと同じ道をたどらないと不整合が起こる可能性が あります。たとえば、通常のルートをたどればメッセージが受け付けられるが、 同定するプローブメッセージがルートを強制された場合に拒否されることがあります。 逆もあり得ますが、それほど多くはありません。