Postfix
SMTP リレーおよびアクセス制御Postfix
SMTP リレーおよびアクセス制御Postfix SMTP サーバはネットワークからのメールを受信するので、ジャンク Eメールやウィルスのような大きな悪い世界に晒されています。このドキュメントは Postfix が受け取る SMTP メールを制御するビルトインの手法および外部手法、 避けるべき間違い、そして設定をテストする方法を紹介します。
このドキュメントがカバーしている話題:
はるか昔、インターネットは友好的な環境でした。メールサーバは誰かの 代わりにどの配送先へも喜んで転送していました。今日のインターネットでは、 スパマーが任意のシステムからメールを転送するのにサーバを悪用し、 悪用されたシステムはアンチスパマーブラックリストに載ってしまいます。 例えば、http://www.mail-abuse.org/ やその他のウェブサイトの情報を見てください。
デフォルトでは、Postfix はメールのリレーに対して適度に制限するという アプローチを取っています。Postfix は信頼するネットワークからのメールや リレー配送先として認めるように設定されたドメインに対してのみメールを リレーします。デフォルトのポリシーの記述は postconf(5) マニュアルページの smtpd_recipient_restrictions パラメータや、そこで参照している情報を見てください。
ほとんどの Postfix SMTP サーバアクセス制御はジャンクEメールを止める ことを目的としています。
プロトコル指向: SMTP サーバアクセス制御には SMTP プロトコルに 関して非常に厳密に従うことによってメールをブロックするものがあります; これらはまずい実装や下手な設定のジャンクメールソフトウェアや、標準に 従わない SMTP クライアントを自身に実装したEメールワームを捕らえます。 スパマーやワームの作者が RFC ドキュメントを読むことを学んできているため、 プロトコル指向のアクセス制御は、次第に役に立たなくなってきています。
ブラックリスト指向: SMTP サーバアクセス制御には、ブラックリストに オープンメールリレーやオープンウェブプロキシ、危険にさらされたり犯罪者の リモートコントロール下に置かれたホームコンピュータのような悪いサイトと わかっているものを問い合わせるものがあります。これらのブラックリストの 効果は、リストがどれだけ完全かとどれほど最新のものかによります。
閾値指向: SMTP サーバアクセス制御にはクライアントにより多くの仕事を させたり (greylisting) セカンドオピニオンを求める (SPF や送信者/受信者検証) ことでレベルを上げるものがあります。greylisting や SPF ポリシーは外部で 実装されるものであり、SMTPD_POLICY_README ドキュメントの範疇です。送信者/受信者アドレス検証は ADDRESS_VERIFICATION_README ドキュメントの主題です。
残念ながら、全てジャンクメール制御には正当なメールを拒否してしまう 可能性があります。このことは様々なタイプのユーザがたくさんいるサイトでは 問題になるでしょう。どんなジャンクEメールが入ってくるのも許せないユーザが いる一方で、 1通でも正当なEメールメッセージがブロックされてしまうと世界が 終末をむかえるというユーザがいるでしょう。全てのユーザに "正しい" 単一の ポリシーがあるわけではないので、Postfix はユーザごとに異なる SMTP アクセス制御をサポートしています。これは RESTRICTION_CLASS_README ドキュメントに記述されています。
次のセクションに書かれているクライアントやユーザごとに設定可能な制限 以外に、 Postfix は全ての SMTP メールに適用される制限をいくつか実装して います。
ビルトイン header_checks および body_checks コンテンツ 制限、これは BUILTIN_FILTER_README ドキュメントに 記述されています。Postfix がメールを受信している間で、 incoming キュー に 保存される前に検査がおこなわれます。
キューに入る前の外部コンテンツ制限、これは SMTPD_PROXY_README ドキュメントに 書かれています。 receives mail, before it is stored in the incoming queue.
クライアントが MAIL FROM や ETRN コマンドを送る前に、HELO もしくは EHLO コマンドが送られることの要求。これはメールを送る自家製の アプリケーションで問題を起こすかもしれません。そのため、デフォルトでは この要求は無効になっています ("smtpd_helo_required = no")。
MAIL FROM や RCPT TO コマンドにおける不正な文法を認めません。 これはメールを送る自家製アプリケーションや古い PC メールクライアントで 問題を起こすかもしれません。そのため、デフォルトではこの要求は無効になって います ("strict_rfc821_envelopes = no")。
RFC 822 アドレス文法を認めません (例: "MAIL FROM: the dude <dude@example.com>").
<> で囲まれていないアドレスを認めません (例: "MAIL FROM: dude@example.com").
存在しない送信者アドレスからのメールの拒否。出口でこのような フィルタリングをおこなうとワームや他の悪意あるソフトウェアを遅くするのに 役立ちますが、返信できないアドレスでメールを送る自家製ソフトウェアで 問題を起こすかもしれません。そのため、デフォルトではこの要求は無効になって います ("smtpd_reject_unlisted_sender = no")。
存在しない受信者アドレス宛メールの拒否。入り口でこのような フィルタリングをおこなうと、配送できない MAILER-DAEMON メッセージが キューにたまらないようにするのに役立ちます。この要求はデフォルトで 有効になっています ("smtpd_reject_unlisted_recipient = yes")。
Postfix では SMTP 通信の各ステージごとにアクセス制限のリストを指定する ことができます。個々の制限は postconf(5) マニュアルページに書かれています。
以下は簡単な制限の例です:
/etc/postfix/main.cf:
# 信頼しているネットワークからの接続のみを許可します。
smtpd_client_restrictions = permit_mynetworks, reject
# ホスト名を知らないメールシステムとは話しません。
# Postfix < 2.3では reject_unknown_hostname を指定してください。
smtpd_helo_restrictions = reject_unknown_helo_hostname
# 存在しないドメインからのメールは受け付けません。
smtpd_sender_restrictions = reject_unknown_sender_domain
# ホワイトリスティング: ローカルクライアントはどの配送先でも指定でき、
# それ以外はできません。
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination
# 早口すぎるクライアントをブロックします。
smtpd_data_restrictions = reject_unauth_pipelining
# ポリシーサービスを呼び出してメール容量のクォータを強制します。
smtpd_end_of_data_restrictions = check_policy_service unix:private/policy
それぞれの制限リストは、制限の結果が PERMIT や REJECT、DEFER (後で 試してください) になるまで、左から右へと評価されます。リストの最後は PERMIT という結果と等価です。PERMIT 制限を REJECT 制限の前に置くことで、 特定のクライアントやユーザに対して例外処理することができます。これを ホワイトリスティングといいます; 上の最後の例では、ローカルネットワーク からのメールは許可されますが、それ以外は任意の配送先へのメールは拒否 されます。
以下の表はそれぞれの SMTP アクセス制限リストの目的をまとめています。 リストは全て、全く同じ文法を使います; 評価されるときと REJECT や DEFER と いう結果の影響が異なるだけです。
制限リスト名 状態 REJECT や DEFER の影響 smtpd_client_restrictions オプション 全てのクライアントコマンドを拒否します smtpd_helo_restrictions オプション HELO/EHLO 情報を拒否します smtpd_sender_restrictions オプション MAIL FROM 情報を拒否します smtpd_recipient_restrictions Required RCPT TO 情報を拒否します smtpd_data_restrictions オプション DATA コマンドを拒否します smtpd_end_of_data_restrictions Optional END-OF-DATA コマンドを拒否します smtpd_etrn_restrictions オプション ETRN コマンドを拒否します
初期のバージョンの Postfix は SMTP アクセス制限リストを出来るだけ早く 評価していました。クライアント制限リストは Postfix が SMTP クライアントに "220 $myhostname..." グリーティングバナーを送る前に評価し、helo 制限リストは Postfix が HELO (EHLO) コマンドに応答する前に、送信者制限リストは Postfix が MAIL FROM コマンドに応答する前に、というように評価していました。この方法は 使うのが難しいということがわかってきました。
現在のバージョンの Postfix はクライアントや helo、送信者制限リストの 評価を RCPT TO または ETRN コマンドまで遅らせます。この振る舞いは smtpd_delay_reject パラメータによって制御されます。それでも制限リストは (クライアント、helo、 etrn) または (クライアント、helo、送信者、受信者、data、end-of-data) 制限という、適切な順序で評価されます。制限リスト (例: クライアント) が REJECT または DEFER と評価されると、他の制限リスト (例: helo、送信者など) は 飛ばされます。
smtpd_delay_reject が 導入された頃、Postfix はクライアントや helo、送信者、受信者、etrn コマンドの 情報を組み合わせた、混合制限リストをサポートするようにも変わりました。
制限の評価を遅らせたり、制限を混ぜることでの利点:
SMTP クライアントには SMTP セッションの初期段階で否定応答が 返されることを予期していないものがあります。RCPT TO 応答まで悪い知らせが 遅らせれば、クライアントは期待通り立ち去っていき、タイムアウトするまで ハングしていたりさらにはエンドレスな接続 - 拒否 - 接続ループに入ったり しません。
Postfix はより役に立つ情報をログに記録できます。例えば、Postfix が クライアント名やアドレスを拒否して RCPT TO コマンドまでアクションを 遅らせると、送信者や受信者のアドレスをログに記録することができます。 これはクライアントホスト名や IP アドレスだけが記録されて誰のメールが ブロックされたかわからないというよりも便利です。
複雑なホワイトリスティングポリシーには制限の混在が必要です。 例えば、非ローカルクライアントからのメールにおけるローカル送信者アドレスを 拒否するためには、クライアント情報の制限と送信者情報の制限を同じ制限リストの 中で混ぜることが可能である必要があります。このような機能がないと、 ユーザごとのアクセス制限の多くを表現するのは不可能になってしまいます。
ここまでで、smtpd クライアント、helo、送信者または受信者の制限が RCPT TO や ETRN コマンドまで遅らされるときに、なぜ必要なのかわからない かもしれませんね。アクセス制限を「全て」 smtpd_recipient_restrictions リストに置くことを薦める人たちもいます。残念ながら、これはアクセスを 過度に許可する設定にしてしまうかもしれません。どうしてそうなるのでしょう？
smtpd_recipient_restrictions 機能の目的は Postfix が RCPT TO コマンドへの対応方法を制御します。 制限リストが REJECT や DEFER と評価されると、受信者アドレスは拒否されます; これには何も驚くことはありません。結果が PERMIT であると、受信者アドレスは 受け入れられます。ここに驚くことがあり得ます。
これは PERMIT という結果が過度にアクセスを許可してしまう例です:
1 /etc/postfix/main.cf: 2 smtpd_recipient_restrictions = 3 permit_mynetworks 4 check_helo_access hash:/etc/postfix/helo_access 5 reject_unknown_helo_hostname 6 reject_unauth_destination 7 8 /etc/postfix/helo_access: 9 localhost.localdomain PERMIT
5行目は HELO コマンドで正しいホスト名を指定しないホストからのメールを 拒否します Postfix < 2.3では reject_unknown_hostname を 指定します)。4行目と9行目は自分を "HELO localhost.localdomain" と告げる マシンからのメールを受け入れる例外を作ります。
この設定の問題は、smtpd_recipient_restrictions が 自分自身を "localhost.localdomain" と主張するホスト「全て」を PERMIT と 評価してしまうことで、そのような全てのホストに対して Postfix をオープン リレーにしてしまいます。
smtpd_recipient_restrictions で このような驚きを避けるには、受信者ではない制限を reject_unauth_destination 制限の前ではなく「後に」置かなければいけません。上の例では、HELO に基づく 制限 reject_unauth_destination の 「後に」置くべきであり、もしくは副作用のない smtpd_helo_restrictions 以下に置けばよりよいでしょう。
Postfix には SMTP アクセスルールをテストするのに役立つ機能がいくつか あります:
これは SMTP サーバ REJECT アクションを DEFER (後で試してください) アクションに 変える、安全ネットです。これはメールをキューにとどめておきますが、 そうしないとメールは送信者に返されてしまいます。5xx SMTP 応答コードを 全て 4xx に変えることで Postfix SMTP サーバがメールを恒久的に拒否しない ようにするために、main.cf ファイルで "soft_bounce = yes" を指定して ください。
これは SMTP サーバ REJECT アクションを警告に変える、別の安全ネットです。 コマンドを拒否する代わりに、Postfix は拒否しようとしたものをログに記録 します。実際にメールを拒否せずにテストしたい SMTP アクセス制限リストの 制限の前に、"warn_if_reject" を指定します。
この Postfix 2.1 の機能で、許可された SMTP クライアントは他のシステムのふりをすることができます。そうすることで、 実際に近い SMTP アクセスルールテストができます。アクセスルールのテストで 他のシステムのふりをする方法の例は XCLIENT_README ドキュメントの最後にあります。