Postfix Postscreen HowtoPostfix Postscreen Howto[訳注: Postfix 2.8.2 に同梱の POSTSCREEN_README の翻訳]
The Postfix postscreen(8) server performs triage on multiple inbound SMTP connections at the same time. While a single postscreen(8) process keeps zombies away from Postfix SMTP server processes, more Postfix SMTP server processes remain available for legitimate clients.
Postfix の postscreen(8) サーバは同時にやってくる複数の SMTP 接続を選別する。単一の postscreen(8) プロセスは、Postfix の SMTP サーバプロセスにゾンビが近付かないようにしながら、まっとうなクライアントは利用できるようにしておく。
postscreen(8) should not be used on SMTP ports that receive mail from end-user clients (MUAs). In a typical deployment, postscreen(8) is used on the "port 25" service, while MUA clients submit mail via the submission service.
postscreen(8) はエンドユーザの使うメーラー(MUA)からメールを受けとる SMTP ポートでは使うべきではない。典型的な構成では、postscreen(8) は「ポート 25」のサービスで使われ、MUA は submission サービスでメールを送信する。
postscreen(8) is part of a multi-layer defense.
postscreen(8) は多段防御の一部である。
As the first layer, postscreen(8) blocks connections from zombies and other spambots that are responsible for about 90% of all spam. It is implemented as a single process to make this defense as cheap as possible.
まず最初に、postscreen(8) が spam 全体のおよそ9割の原因となっているゾンビや他の spambot からの接続をブロックする。この防御をできるだけ低いコストでおこなうため、単一プロセスでの実装になっている。
The second layer implements more complex SMTP-level access checks with Postfix SMTP servers, policy daemons, and Milter applications.
次段では Postfix SMTP サーバ、ポリシーデーモン[訳注: これのこと]、Milter アプリケーションによる、より複雑な SMTP レベルでのアクセス制御をおこなう。
The third layer performs light-weight content inspection with the Postfix built-in header_checks and body_checks. This can block unacceptable attachments such as executable programs, and worms or viruses with easy-to-recognize signatures.
3段目では Postfix 内蔵の header_checks および body_checks による軽いコンテンツチェックがおこなわれる。ここでは、実行プログラムや、シグネチャーを簡単に認識できるワームやウィルスといった、受け取りたくない添付ファイルをブロックできる。
The fourth layer provides heavy-weight content inspection with external content filters. Typical examples are Amavisd-new, SpamAssassin, and Milter applications.
4段目には外部のコンテンツフィルタを使った思いコンテンツチェックを用意する。Amavisd-new や SpamAssasasin、Milter アプリケーションが典型的な例である。
Each layer reduces the spam volume. The general strategy is to use the less expensive defenses first, and to use the more expensive defenses for the spam that remains.
それぞれの段で spam の量を減らす。一般的な戦略は、コストのより低い防御を先に使い、残った spam にコストの高い防御を使うということである。
Topics in this document:
この文書の話題:
Most email is spam, and most spam is sent out by zombies (malware on compromised end-user computers). Wietse expects that the zombie problem will get worse before things improve, if ever. Without a tool like postscreen(8) that keeps the zombies away, Postfix would be spending most of its resources not receiving email.
ほとんどの電子メールは spam であり、ほとんどの spam はゾンビ（エンドユーザのコンピューターに寄生するマルウェア）から送信される。事態が改善することもあるかもしれないが、その前に悪化していくだろうと Wietse [訳注: postfix の作者]は予想している。postscreen(8) のようなゾンビよけツールがなければ、Postfix はそのリソースをメールの受信以外のことに浪費することになるだろう。
The main challenge for postscreen(8) is to make an is-it-a-zombie decision based on a single measurement. This is necessary because many zombies avoid spamming the same site repeatedly, in an attempt to fly under the radar. Once postscreen(8) decides that a client is not-a-zombie, it whitelists the client temporarily to avoid further delays for legitimate mail.
postscreen(8) がやろうとするのは、1回の測定でゾンビかどうかの判定をおこなうことである[訳注: 最初の1通は受け取って、それが spam だったら以後は受け取らないようにするのではなく、最初から受け取らないようにするということ]。これが必要なのは、多くのゾンビは目立たないように同じサイトに何度も繰り返し spam 送信したりしないためである。postscreen(8) は、クライアントがゾンビではないと判定したら以後まっとうなメールが遅延しないよう一時的ホワイトリストに追加する。
Zombies have challenges too: they have only a limited amount of time to deliver spam before their IP address becomes blacklisted. To speed up spam deliveries, zombies make compromises in their SMTP protocol implementation. For example, they speak before their turn, or they ignore responses from SMTP servers and continue sending mail even when the server tells them to go away.
ゾンビも戦っている: 自分の IP アドレスがブラックリストに載る前に spam を送信できるのは限られた時間しかない。spam 配送を高速化するため、ゾンビは SMTP プロトコルをフル実装していない。たとえば、自分が SMTP コマンドを投げていい場面でないのにコマンドを喋ったり、SMTP サーバが拒否してるのに応答を無視してメール送信を続けたりする。
postscreen(8) uses a variety of measurements to recognize zombies. First, postscreen(8) determines if the remote SMTP client IP address is blacklisted. Second, postscreen(8) looks for protocol compromises that are made to speed up delivery. These are good indicators for making is-it-a-zombie decisions based on single measurements.
postscreen(8) は、ゾンビを見つけるためにさまさまな手法を使う。まず、postscreen(8) はリモート SMTP クライアントの IP アドレスがブラックリストに載っているか判定する。次に、postscreen(8) は配送を高速化するためにプロトコルを正しくない使い方をしているかどうか調べる。これらは、ひとつの測定でゾンビかどうかの決定するのによい指標となる。
postscreen(8) does not inspect message content. Message content can vary from one delivery to the next, especially with clients that (also) send legitimate email. Content is not a good indicator for making is-it-a-zombie decisions based on single measurements, and that is the problem that postscreen(8) is focused on.
postscreen(8) はメッセージの中身は検査しない。メッセージは、とくにまっとうなメールを（も）送るクライアントでは、1通ごとに中身が大きく異なりうる。メッセージの中身はひとつの測定でのゾンビかどうかの決定する指標としてはよくない。そこが postscreen(8) が主眼を置く問題である。
The postscreen(8) triage process involves a number of tests, in the order as described below. Some tests introduce a delay of a few seconds. Once a client passes a test, its IP address is whitelisted from 24 hours for simple tests, to 1 week for complex tests. Whitelisting minimizes the impact of postscreen(8)'s tests on legitimate mail clients.
postscreen(8) による選別過程にはいくつものテストがあり、以下に挙げる順番でおこなわれる。いくつかのテストでは数秒の遅延が発生する。クライアントがテストにパスすると、その IP アドレスは簡単なテストでは24時間、複雑なテストでは1週間の間、ホワイトリストに記録される。ホワイトリストを使うことで、postscreen(8) のテストがまっとうなメールクライアントに与える影響を最小限に留める。
After logging its findings, postscreen(8) by default hands off all connections to a Postfix SMTP server process. This mode is useful for non-destructive testing.
postscreen(8) は、見つけたことをログに残した後で、デフォルトではすべての接続を Postfix SMTP サーバプロセスに受け渡す。このモードは非破壊的[訳注: 一時エラーなどが発生しない]にテストするため有用である。
In a typical production setting, postscreen(8) is configured to reject mail from clients that fail one or more tests, after logging the helo, sender and recipient information.
典型的な本番環境では、ひとつないしはそれ以上のテストにひっかかったクライアントからのメールを HELO、送受信者の情報をログに記録した後で拒否するように postscreen(8) を設定する。
Note: postscreen(8) is not an SMTP proxy; this is intentional. The purpose is to keep zombies away from Postfix, with minimal overhead for legitimate clients.
注: postscreen(8) は SMTP プロクシではない。これは意図してそのようにしてある。その目的は、ゾンビをよけながら、まっとうなクライアントを最小のオーバーヘッドで受け入れることである。[訳注: プロクシだと接続の数だけ smtpd プロセスが生成されてしまってリソースを浪費するため。設計思想上、単一プロセスである必要がある。]
Before engaging in SMTP-level tests. postscreen(8) queries a number of local black and whitelists. These tests speed up the handling of known clients.
SMTP レベルのテストに入る前。postscreen(8) はいくつかのローカルのブラックリスト/ホワイトリストをを調べる。これらのテストにより既知のクライアントの扱いが速くなる。
The postscreen_access_list parameter (default: permit_mynetworks) specifies a permanent access list for SMTP client IP addresses. Typically one would specify something that whitelists local networks, followed by a CIDR table for selective white- and blacklisting.
postscreen_access_list パラメータ（デフォルト: permit_mynetworks）は SMTP クライアントの IP アドレスの恒久的なアクセスリストを指定する。典型的には、ローカルネットワークをホワイトリスト登録し、続けて選択的なホワイトリスト/ブラックリストのために CIDR テーブルを指定することになるだろう。
Example:
例:
/etc/postfix/main.cf:
postscreen_access_list = permit_mynetworks,
cidr:/etc/postfix/postscreen_access.cidr
/etc/postfix/postscreen_access.cidr:
# Rules are evaluated in the order as specified.
# Blacklist 192.168.* except 192.168.0.1.
192.168.0.1 permit
192.168.0.0/16 reject
See the postscreen_access_list manpage documentation for more details.
詳細は postscreen_access_list manpage の記述を参照のこと。
When the SMTP client address matches a "permit" action, postscreen(8) logs this with the client address and port number as:
SMTP クライアントのアドレスが "permit" アクションにマッチすると、postscreen(8) はクライアントのアドレスとポート番号を以下のように記録する:
WHITELISTED [address]:port
The whitelist action is not configurable: immediately hand off the connection to a Postfix SMTP server process.
ホワイトリストの挙動は設定で変更できない: ただちに Postfix SMTP サーバプロセスに接続が渡される。
When the SMTP client address matches a "reject" action, postscreen(8) logs this with the client address and port number as:
SMTP クライアントのアドレスが "reject" アクションにマッチすると、postscreen(8) はクライアントのアドレスとポート番号を以下のように記録する:
BLACKLISTED [address]:port
The postscreen_blacklist_action parameter specifies the action that is taken next. See "When tests fail before the 220 SMTP server greeting" below.
postscreen_blacklist_action パラメータは次に取るべきアクションを指定する。下記の "When tests fail before the 220 SMTP server greeting" を参照せよ。
The postscreen(8) daemon maintains a temporary whitelist for SMTP client IP addresses that have passed all the tests described below. The postscreen_cache_map parameter specifies the location of the temporary whitelist. The temporary whitelist is not used for SMTP client addresses that appear on the permanent blacklist or whitelist.
postscreen(8) デーモンは以下で説明するテストをすべてをパスした SMTP クライアントの IP アドレスの一時的なホワイトリストを保持する。postscreen_cache_map パラメータは一時的ホワイトリストの場所を指定する。一時的ホワイトリストは恒久的ブラックリスト/ホワイトリストにあらわれる SMTP クライアントのアドレスには使われない。
When the SMTP client address appears on the temporary whitelist, postscreen(8) logs this with the client address and port number as:
SMTP クライアントのアドレスが一時的ホワイトリストにあった場合、postscreen(8) はクライアントのアドレスとポート番号を以下のように記録する:
PASS OLD [address]:port
The action is not configurable: immediately hand off the connection to a Postfix SMTP server process. The client is excluded from further tests until its temporary whitelist entry expires, as controlled with the postscreen_*_ttl parameters. Expired entries are silently renewed if possible.
動作は設定で変更できない: ただちに Postfix SMTP サーバプロセスに接続が渡される。postscreen_*_ttl パラメータで制御される一時的ホワイトリストの期限がくるまで、このクライアントに対してこれ以上のテストはおこなわない。期限切れエントリは可能なら静かに更新される。
The postscreen_greet_wait parameter specifies a short time interval before the "220 text..." server greeting, where postscreen(8) can run a number of tests in parallel.
postscreen_greet_wait パラメータはサーバが "220 text..." というグリーティングを出す前に挿入する待ち時間を指定する。postscreen(8) はこの間にいくつかのテストを並行しておこなうことができる。
When a good client passes these tests, and no "deep protocol tests" are configured, postscreen(8) adds the client to the temporary whitelist and hands off the "live" connection to a Postfix SMTP server process. The client can then continue as if postscreen(8) never even existed (except of course for the short postscreen_greet_wait delay).
これらのテストにパスしたよいクライアントで、かつ "deep protocol tests" が設定されていなければ、postscreen(8) はクライアントを一時的ホワイトリストに追加して「生きた」接続を Postfix SMTP サーバプロセスに受け渡す。クライアントはまるで postscreen(8) が存在しなかったかのように処理を続けることができる（もちろん、postscreen_greet_wait による短い待ち時間は除く）。
The SMTP protocol is a classic example of a protocol where the server speaks before the client. postscreen(8) detects zombies that are in a hurry and that speak before their turn. This test is enabled by default.
SMTP プロトコルはクライアントが喋る前にサーバが喋るプロトコルの古典的な例である。postscreen(8) はあわてて自分の順番になる前に喋るゾンビを検知する。このテストはデフォルトで有効になっている。
The postscreen_greet_banner parameter specifies the text portion of a "220-text..." teaser banner (default: $smtpd_banner). Note that this becomes the first part of a multi-line server greeting. The postscreen(8) daemon sends this before the postscreen_greet_wait timer is started. The purpose of the teaser banner is to confuse zombies so that they speak before their turn. It has no effect on SMTP clients that correctly implement the protocol.
postscreen_greet_banner パラメータは "220-text..." というバナーの text の部分を指定する（デフォルト: $smtpd_banner）。なお、これは複数行のサーバグリーティングの最初の1行である。postscreen(8) デーモンはこれを postscreen_greet_wait のタイマーがスタートする前に送信する。自分の順番ではないのに喋ろうとするゾンビを混乱させるのがこのバナーの目的である。プロトコルを正しく実装した SMTP クライアントであれば影響を受けない。
[訳注: SMTP サーバからの応答は1行で返されることが多いが、プロトコル上は複数行による応答が認められている。応答が継続する場合は "220-text" のようにステータスコードの次にハイフンが入る。"220 text" のようにステータスコードの次が空白文字ならば応答終端。サーバの ESMTP 拡張機能の実装状況を EHLO の応答として返すときに複数行応答が使われることが多いが、接続して最初のグリーティングバナーを複数行で出しても、プロトコル上はまったく問題ない。しかし、ゾンビはこのような複数行グリーティングが返ってくることを想定していないものが多く、複数行グリーティングの最初の1行を受けとった時点でグリーティング完了と勘違いしてコマンドの発行を開始してしまうものがある（それどころか最初の1行すら見ずに喋りはじめるゾンビも数多く存在する）。わざと複数行グリーティングをおこなって実装の貧弱なクライアントを検知するのが pregreet test である。]
To avoid problems with poorly-implemented SMTP engines in network appliances or network testing tools, either exclude them from all tests with the postscreen_access_list feature or else specify an empty teaser banner:
SMTP エンジンの実装が貧弱なアプライアンス箱やネットワークテストツールなどで問題が起きないようにするには、postscreen_access_list の機能ですべてのテストを除外するか、あるいはバナーを空に設定すればよい:
/etc/postfix/main.cf:
# Exclude broken clients by whitelisting. Clients in mynetworks
# should always be whitelisted.
# ホワイトリストによるぶっこわれクライアントの除外。
# mynetworks にあるクライアントは常にホワイトリストされているべきである。
postscreen_access_list = permit_mynetworks,
cidr:/etc/postfix/postscreen_access.cidr
/etc/postfix/postscreen_access.cidr:
192.168.254.0/24 permit
/etc/postfix/main.cf:
# Disable the teaser banner (try whitelisting first if you can). バナー抑止（可能ならまずホワイトリストを試すべし）
postscreen_greet_banner =
When an SMTP client sends a command before the postscreen_greet_wait time has elapsed, postscreen(8) logs this as:
SMTP クライアントが postscreen_greet_wait の時間が経過する前にコマンドを送ってくると、 postscreen(8) は以下のようなログを残す:
PREGREET count after time from [address]:port text...
Translation: the client at [address]:port sent count bytes before its turn to speak. This happened time seconds after the postscreen_greet_wait timer was started. The text is what the client sent (truncated to 100 bytes, and with non-printable characters replaced with C-style escapes such as \r for carriage-return and \n for newline).
意味: [address]:port のクライアントが自分の順番になる前に count バイト送ってきた。これは postscreen_greet_wait のタイマーが開始されてから time 秒後に起きた。 クライアントが送ってきた文字列は text である（100バイトを越える長さは縮められる。また、非印字文字は CR を \r で、LF を \n というような C の書式でエスケープして置き換えられる）。
The postscreen_greet_action parameter specifies the action that is taken next. See "When tests fail before the 220 SMTP server greeting" below.
postscreen_greet_action パラメータは次に取るべきアクションを指定する。下記の "When tests fail before the 220 SMTP server greeting" を参照せよ。
The postscreen_dnsbl_sites parameter (default: empty) specifies a list of DNS blocklist servers with optional filters and weight factors (positive weights for blacklisting, negative for whitelisting). These servers will be queried in parallel with the reverse client IP address. This test is disabled by default.
postscreen_dnsbl_sites パラメータ（デフォルト: 空）は DNSBL サーバのリスト指定する。オプションでフィルタと重み（正の値ならブラックリスト、負の値ならホワイトリスト）も指定可。指定されたサーバにクライアント IP アドレスの逆引きを並列で問い合わせる。このテストはデフォルトでは無効になっている。
CAUTION: when postscreen rejects mail, its SMTP reply contains the DNSBL domain name. Use the postscreen_dnsbl_reply_map feature to hide "password" information in DNSBL domain names.
注意: postscreen がメールを拒否するときの SMTP の応答には DNSBL のドメイン名が含まれる。DNSBL のドメイン名に含まれる「秘密」情報を隠すには postscreen_dnsbl_reply_map 機能を使うべし。[訳注: 契約した相手にだけドメイン名を教える商用の DNSBL というのも存在する。それを考慮したものと思われる。]
When the postscreen_greet_wait time has elapsed, and the combined DNSBL score is equal to or greater than the postscreen_dnsbl_threshold parameter value, postscreen(8) logs this as:
postscreen_greet_wait の時間が経過し、全体の DNSBL スコアが postscreen_dnsbl_threshold 以上の値であれば、postscreen(8) は次のようなログを残す:
DNSBL rank count for [address]:port
Translation: the SMTP client at [address]:port has a combined DNSBL score of count.
意味: [address]'port の SMTP クライアントの DNSBL スコアは count だった。
The postscreen_dnsbl_action parameter specifies the action that is taken when the combined DNSBL score is equal to or greater than the threshold. See "When tests fail before the 220 SMTP server greeting" below.
postscreen_dnsbl_action パラメータは DNSBL スコアが閾値以上だったときに取るべきアクションを指定する。下記の "When tests fail before the 220 SMTP server greeting" を参照せよ。
When the client address matches the permanent blacklist, or when the client fails the pregreet or DNSBL tests, the action is specified with postscreen_blacklist_action, postscreen_greet_action, or postscreen_dnsbl_action, respectively.
クライアントのアドレスが恒久的ブラックリストにマッチするか、クライアントが pregreet ないしは DNSBL テストに失敗すると、それぞれ postscreen_blacklist_action、postscreen_greet_action、postscreen_dnsbl_action で指定されたアクションが実行される。
In this phase of the protocol, postscreen(8) implements a number of "deep protocol" tests. These tests use an SMTP protocol engine that is built into the postscreen(8) server.
このフェイズでは postscreen(8) はいくつかの "deep protocol" テストをおこなう。これらのテストは postscreen(8) サーバに内蔵の SMTP プロトコルエンジンでおこなう。
Important note: deep protocol tests are disabled by default. They are more intrusive than the pregreet and DNSBL tests, and they have limitations as discussed next.
重要な注記: deep protocol テストはデフォルトでは無効になっている。これらは pregreet テストや DNSBL テストよりもプロトコルに深く立ち入り、かつ、次で議論されるような制限がある。
When a good client passes the deep protocol tests, postscreen(8) adds the client to the temporary whitelist but it cannot hand off the "live" connection to a Postfix SMTP server process in the middle of the session. Instead, postscreen(8) defers mail delivery attempts with a 4XX status, logs the helo/sender/recipient information, and waits for the client to disconnect.
よいクライアントが deep protocol テストをパスすると、postscreen(8) はクライアントを一時的ホワイトリストに追加するが、「生きた」接続をセッションの途中で SMTP サーバプロセスに受け渡すことはできない。かわりに、postscreen(8) は 4XX のステータスでメール配送試行を遅延し、HELO および送受信者情報をログに記録してクライアントの切断を待つ。
The next time the client connects it will be allowed to talk to a Postfix SMTP server process to deliver its mail. To minimize the impact of this limitation, postscreen(8) gives deep protocol tests a relatively long expiration time.
同じクライアントが再度接続してくると、メールを配送するため Postfix SMTP サーバプロセスと話すことができるようになる。この制限による影響をできるだけ小さくするため、postscreen(8) は deep protocol test では一時的ホワイトリストの期限は比較的長めになっている。
postscreen(8)'s built-in SMTP engine does not implement the AUTH, XCLIENT, and XFORWARD features. AUTH support may be added in a future version. In the mean time, if you need to make these services available on port 25, then do not enable the tests after the 220 server greeting.
postscreen(8) の内蔵 SMTP エンジンは AUTH、XCLIENT、XFORWARD の機能を実装していない。将来のバージョンでは AUTH のサポートは追加されるだろう。それまでの間は、これらのサービスが25番ポートで必要とされるのであれば、220 サーバグリーティング後テストを有効にしてはならない。[訳注: XCLIENT と XFORWARD はどちらも postfix の独自拡張機能。いずれも閉じたネットワーク内で使われることを想定したもので、ゾンビが直接アクセスしてくるような外部ネットワークに晒される環境では通常使わない]
End-user clients should connect directly to the submission service, so that they never have to deal with postscreen(8)'s tests.
エンドユーザのクライアントは postscreen(8) のテストがおこなわれないよう、直接 submission サービスに接続するべきである。
By default, SMTP is a half-duplex protocol: the sender and receiver send one command and one response at a time. Unlike the Postfix SMTP server, postscreen(8) does not announce support for ESMTP command pipelining. Therefore, clients are not allowed to send multiple commands. postscreen(8)'s deep protocol test for this is disabled by default.
デフォルトでは、SMTP は半二重なプロトコルである: 送信側と受信側が1回でコマンドをひとつ送り、応答をひとつ受け取る。Postfix SMTP サーバとは異なり、postscreen(8) は ESMTP の command pipelining 対応をアナウンスしない。そのため、クライアントが複数のコマンドを送ることは許されない。postscreen(8) の deep protocol test ではこれはデフォルトでは無効になっている。
With "postscreen_pipelining_enable = yes", postscreen(8) detects zombies that send multiple commands, instead of sending one command and waiting for the server to reply.
"postscreen_pipelining_enable = yes" にすると、postscreen(8) はサーバからの応答を待ってひとつずつコマンドを送るのではなく、同時に複数のコマンドを送ってくるゾンビを検知するようになる。
This test is opportunistically enabled when postscreen(8) has to use the built-in SMTP engine anyway. This is to make postscreen(8) logging more informative.
このテストは、postscreen(8) が内蔵 SMTP エンジンをどうしても使わないといけないときだけに限って有効になる[訳注: グリーティング前テストでどう対応すべきか決定された後では、有効にする設定であってもテストはおこなわない、という意味だと思う、たぶん]。そのため、postscreen(8) はより詳しいログを出す。
When a client sends multiple commands, postscreen(8) logs this as:
クライアントが複数のコマンドを送ってくると、postscreen(8) は以下のようなログを記録する。
COMMAND PIPELINING from [address]:port after command
Translation: the SMTP client at [address]:port sent multiple SMTP commands, instead of sending one command and then waiting for the server to reply. This happened after the client sent command. Postfix 2.8 does not log the input that was sent too early.
意味: [address:port] の SMTP クライアントはコマンドをひとつ送ってからサーバからの応答を待つのではなく複数のコマンドを送ってきた。これはクライアントが command を送った後で起きた。Postfix 2.8 は早く送りすぎた入力は記録しない。
The postscreen_pipelining_action parameter specifies the action that is taken next. See "When tests fail after the 220 SMTP server greeting" below.
postscreen_pipelining_action パラメータは次に取るべきアクションを指定する。下記の "When tests fail after the 220 SMTP server greeting" を参照せよ。
Some spambots send their mail through open proxies. A symptom of this is the usage of commands such as CONNECT and other non-SMTP commands. Just like the Postfix SMTP server's smtpd_forbidden_commands feature, postscreen(8) has an equivalent postscreen_forbidden_commands feature to block these clients. postscreen(8)'s deep protocol test for this is disabled by default.
spambots によってはオープンプロクシからメールを送ってくるものもある。CONNECT やその他 SMTP にはないコマンドが使われるのはこれのあらわれである[訳注: CONNECT は HTTTP プロクシ越しに HTTPS なサイトにアクセスするときに使われるメソッド]。Postfix SMTP server の smtpd_forbidden_commands 機能とちょうど同じように、こういったクライアントをブロックするために postscreen(8) はそれと同等の postscreen_forbidden_commands 機能を持っている。postscreen(8) の deep protocol test ではこれはデフォルトでは無効になっている。
With "postscreen_non_smtp_command_enable = yes", postscreen(8) detects zombies that send commands specified with the postscreen_forbidden_commands parameter. This also detects commands with the syntax of a message header label. The latter is a symptom that the client is sending message content after ignoring all the responses from postscreen(8) that reject mail.
"postscreen_non_smtp_command_enable = yes" にすると、postscreen(8) は postscreen_forbidden_commands パラメータに指定されたコマンドを送ってきたゾンビを検知するようになる。これはまたメッセージヘッダラベルの文法によるコマンド[訳注: SMTP の MAIL FROM: じゃなくてメッセージヘッダの From: のような形式]も検知する。後者は postscreen(8) がメールを拒否する応答をすべて無視した後にメッセージ本文を送ろうとするクライアントで見られる。
This test is opportunistically enabled when postscreen(8) has to use the built-in SMTP engine anyway. This is to make postscreen(8) logging more informative.
このテストは、postscreen(8) が内蔵 SMTP エンジンをどうしても使わないといけないときだけに限って有効になる。そのため、postscreen(8) はより詳しいログを出す。
When a client sends non-SMTP commands, postscreen(8) logs this as:
クライアントが非 SMTP コマンドを送ってくると、postscreen(8) は以下のようなログを残す:
NON-SMTP COMMAND from [address]:port command
Translation: the SMTP client at [address]:port sent a command that matches the postscreen_forbidden_commands parameter, or that has the syntax of a message header label.
意味: [address:port] の SMTP クライアントが postscreen_forbidden_commands パラメータにマッチする、あるいはメッセージヘッダラベルの文法にマッチする command というコマンドを送ってきた。
The postscreen_non_smtp_command_action parameter specifies the action that is taken next. See "When tests fail after the 220 SMTP server greeting" below.
postscreen_non_smtp_command_action パラメータは次に取るべきアクションを指定する。下記の "When tests fail after the 220 SMTP server greeting" を参照せよ。
SMTP is a line-oriented protocol: lines have a limited length, and are terminated with <CR><LF>. Lines ending in a "bare" <LF>, that is newline not preceded by carriage return, are not allowed in SMTP. postscreen(8)'s deep protocol test for this is disabled by default.
SMTP は行指向のプロトコルである: それぞれの行の長さは制限されており、<CR><LF> で終端する。「裸の」<LF> で終わる行、すなわち <CR> が直前にない改行は SMTP では許されていない。 postscreen(8) の deep protocol test はこれはデフォルトでは無効になっている。
With "postscreen_bare_newline_enable = yes", postscreen(8) detects clients that send lines ending in bare newline characters.
"postscreen_bare_newline_enable = yes" にすると、postscreen(8) は裸の改行文字で終わる行を送ってきたクライアントを検知する。
This test is opportunistically enabled when postscreen(8) has to use the built-in SMTP engine anyway. This is to make postscreen(8) logging more informative.
このテストは、postscreen(8) が内蔵 SMTP エンジンをどうしても使わないといけないときだけに限って有効になる。そのため、postscreen(8) はより詳しいログを出す。
When a client sends bare newline characters, postscreen(8) logs this as:
クライアントが裸の改行文字を送ってくると、postscreen(8) は以下のようなログを残す:
BARE NEWLINE from [address]:port
Translation: the SMTP client at [address]:port sent a bare newline character, that is newline not preceded by carriage return.
意味: [address:port] の SMTP クライアントは裸の改行文字、すなわち <CR> のない <LF> を送ってきた。
The postscreen_bare_newline_action parameter specifies the action that is taken next. See "When tests fail after the 220 SMTP server greeting" below.
postscreen_bare_newline_action パラメータは次に取るべきアクションを指定する。下記の "When tests fail after the 220 SMTP server greeting" を参照せよ。
When the client fails the pipelining, non-SMTP command or bare newline tests, the action is specified with postscreen_pipelining_action, postscreen_non_smtp_command_action or postscreen_bare_newline_action, respectively.
クライアントが pipelining、非 SMTP コマンド、bare newline テストに失敗すると、それぞれ postscreen_pipelining_action、postscreen_non_smtp_command_action、postscreen_bare_newline_action で指定されたアクションが実行される。
When an SMTP client hangs up unexpectedly during any tests, postscreen(8) logs this as:
テスト中に不意に SMTP クライアントとの接続が切れると、postscreen(8) は以下のようなログを残す:
HANGUP after time from [address]:port in test name
Translation: the SMTP client at [address]:port disconnected unexpectedly, time seconds after the start of the test named test name.
意味: [address:port] の SMTP クライアントは test name のテストがはじまってから time 秒後に不意に切断した。
The following errors are reported by the built-in SMTP engine. This engine never accepts mail, therefore it has per-session limits on the number of commands and on the session length.
内蔵 SMTP エンジンから次のようなエラーが報告される。このエンジンはメールを受け付けることはなく、そのためセッションごとにコマンド数とセッションの長さに上限がある。
COMMAND TIME LIMIT from [address]:port
Translation: the SMTP client at [address]:port reached the per-command time limit as specified with the postscreen_command_time_limit parameter. The session is terminated immediately.
意味: [address:port] の SMTP クライアントは postscreen_command_time_limit パラメータで指定されるコマンドごとの時間上限に達した。セッションはただちに終了される。
COMMAND COUNT LIMIT from [address]:port
Translation: the SMTP client at [address]:port reached the per-session command count limit as specified with the postscreen_command_count_limit parameter. The session is terminated immediately.
意味: [address:port] の SMTP クライアントは postscreen_command_count_limit パラメータで指定されるセッションごとのコマンド数上限に達した。セッションはただちに終了される。
COMMAND LENGTH LIMIT from [address]:port
Translation: the SMTP client at [address]:port reached the per-command length limit, as specified with the line_length_limit parameter. The session is terminated immediately.
意味: [address:port] の SMTP クライアントは line_length_limit パラメータで指定されるコマンドごとの長さ制限に達した。セッションはただちに終了される。
When an SMTP client makes too many connections at the same time, or when all postscreen(8) ports are busy, postscreen(8) rejects the connection with a 421 status code and logs:
SMTP クライアントが同時に大量の接続をしてきたとき、あるいはすべての postscreen(8) のポートが使用中のとき、postscreen(8) は 421 のステータスコードで接続を拒否して以下のようなログを記録する:
NOQUEUE: reject: CONNECT from [address]:port: too many connections
NOQUEUE: reject: CONNECT from [address]:port: all server ports busy
The postscreen_client_connection_count_limit and postscreen_pre_queue_limit parameters control these limits.
postscreen_client_connection_count_limit と postscreen_pre_queue_limit パラメータでこの上限を制御する。
When a new SMTP client passes all tests (i.e. it is not whitelisted via some mechanism), postscreen(8) logs this as:
新しい SMTP クライアントがすべてのテストにパスすると（つまり恒久的/一時的ホワイトリストに載っていないということ）、postscreen(8) は以下のようなログを記録する:
PASS NEW [address]:port
Where [address]:port are the client IP address and port. Then, postscreen(8) creates a temporary whitelist entry that excludes the client IP address from further tests until the temporary whitelist entry expires, as controlled with the postscreen_*_ttl parameters.
ここで、[address]:port はクライアントの IP アドレスとポート番号である。そして、postscreen(8) は一時的ホワイトリストに登録して、postscreen_*_ttl パラメータで指定される一時的ホワイトリストの期限が有効なうちは同じクライアント IP アドレスをまたテストをしないようにする。
When no "deep protocol tests" are configured, postscreen(8) hands off the "live" connection to a Postfix SMTP server process. The client can then continue as if postscreen(8) never even existed (except for the short postscreen_greet_wait delay).
"deep protocol tests" をしないよう設定してあるとき、 postscreen(8) は「生きた」接続を Postfix SMTP サーバプロセスに受け渡す。クライアントは postscreen(8) がまるで存在しなかったかのように送信処理を続けることができる（postscreen_greet_wait による短い遅延以外は）。
When any "deep protocol tests" are configured, postscreen(8) cannot hand off the "live" connection to a Postfix SMTP server process in the middle of the session. Instead, postscreen(8) defers mail delivery attempts with a 4XX status, logs the helo/sender/recipient information, and waits for the client to disconnect. The next time the client connects it will be allowed to talk to a Postfix SMTP server process to deliver its mail. postscreen(8) mitigates the impact of this limitation by giving deep protocol tests a long expiration time.
いずれかの "deep protocol tests" をおこなうよう設定してあると、postscreen(8) は「生きた」接続をセッションの途中で Postfix SMTP サーバプロセスに受け渡すことができない。かわりに、postscreen(8) はメール配送を 4XX のステータスで遅延させ、ログに HELO および送受信者情報を記録し、このクライアントが切断するのを待つ。このクライアントが次回接続してきたときには、メール送信のため Postfix SMTP サーバプロセスと喋ることができるようになっているだろう。期限切れまでの時間を長くすることで、postscreen(8) は deep protocol tests によるこの制限の影響を緩和させる。
postscreen(8) has been tested on FreeBSD [4-8], Linux 2.[4-6] and Solaris 9 systems.
postscreen(8) は FreeBSD [4-8]、Linux 2.[4-6]、Solaris 9 システムでテストされている。
To enable the postscreen(8) service and log client information without blocking mail:
postscreen(8) サービスを有効にして、メールをブロックすることなくクライアント情報をログに残すには:
Make sure that local clients and systems with non-standard SMTP implementations are excluded from any postscreen(8) tests. The default is to exclude all clients in mynetworks. To exclude additional clients, for example, third-party performance monitoring tools (these tend to have broken SMTP implementations):
SMTP 実装が標準に準拠していないローカルのクライアントとシステムが postscreen(8) のテストから除外されるようになっていることを確認する。デフォルトでは mynetworks に含まれるすべてのクライアントが除外される。たとえばサードパーティーのパフォーマンス監視ツール（これらは壊れた SMTP 実装になっている傾向がある）のように、ほかにも除外すべきクライアントがあれば:
/etc/postfix/main.cf: # Exclude broken clients by whitelisting. Clients in mynetworks # should always be whitelisted. # ホワイトリストで壊れたクライアントを除外する # mynetworks のクライアントは常にホワイトリストに入れておくべきである postscreen_access_list = permit_mynetworks, cidr:/etc/postfix/postscreen_access.cidr /etc/postfix/postscreen_access.cidr: 192.168.254.0/24 permit
Comment out the "smtp inet ... smtpd" service in master.cf, including any "-o parameter=value" entries that follow.
master.cf の "smtp inet ... smtpd" サービスを、後に続く "-o parameter=value" のエントリがあればそれごとコメントアウトする。
/etc/postfix/master.cf: #smtp inet n - n - - smtpd # -o parameter=value ...
Uncomment the new "smtpd pass ... smtpd" service in master.cf, and duplicate any "-o parameter=value" entries from the smtpd service that was commented out in the previous step.
master.cf の新しい "smtpd pass ... smtpd" サービスの行をコメントをはずして有効にする。前のステップでコメントアウトした smtpd サービスに "-o parameter=value" のエントリがあったらコピーしておく。
/etc/postfix/master.cf: smtpd pass - - n - - smtpd -o parameter=value ...
Uncomment the new "smtp inet ... postscreen" service in master.cf.
master.cf の新しい "smtp inet ... postscreen" サービスのコメントをはずして有効にする。
/etc/postfix/master.cf: smtp inet n - n - 1 postscreen
Uncomment the new "tlsproxy unix ... tlsproxy" service in master.cf. This service implements STARTTLS support for postscreen(8).
master.cf の新しい "tlsproxy unix ... tlsproxy" サービスのコメントをはずして有効にする。このサービスは postscreen(8) に STARTTLS のサポートを実装する。
/etc/postfix/master.cf: tlsproxy unix - - n - 0 tlsproxy
Uncomment the new "dnsblog unix ... dnsblog" service in master.cf. This service does DNSBL lookups for postscreen(8) and logs results.
master.cf の新しい "dnsblog unix ... dnsblog" サービスのコメントをはずして有効にする。このサービスは postscreen(8) のために DNSBL 検索をおこない、結果をログに記録する。
/etc/postfix/master.cf: dnsblog unix - - n - 0 dnsblog
To enable DNSBL lookups, list some DNS blocklist sites in main.cf, separated by whitespace. Different sites can have different weights. For example:
DNSBL 検索を有効にするには[訳注: オプションなのでやらなくても可]、main.cf で DNS ブロックリストのサイトを空白で区切って列挙する。サイトごとに異なる重みを与えることができる。例:
/etc/postfix/main.cf: postscreen_dnsbl_threshold = 2 postscreen_dnsbl_sites = zen.spamhaus.org*2 bl.spamcop.net*1 b.barracudacentral.org*1
Note: if your DNSBL queries have a "secret" in the domain name, you must censor this information from the postscreen(8) SMTP replies. For example:
注: もし DNSBL 問い合わせがドメイン名に「秘密の文字列」を含むなら、この情報を postscreen(8) の SMTP 応答から隠すようにしなければならない。例:
/etc/postfix/main.cf: postscreen_dnsbl_reply_map = texthash:/etc/postfix/dnsbl_reply
/etc/postfix/dnsbl_reply:
# Secret DNSBL name Name in postscreen(8) replies
# 秘密の DNSBL 名 postscreen(8) が答える名前
secret.zen.spamhaus.org zen.spamhaus.org
The texthash: format is similar to hash: except that there is no need to run postmap(1) before the file can be used, and that it does not detect changes after the file is read. It is new with Postfix version 2.8.
texthash: 形式は hash: に似ているが、そのファイルを使う前に postmap(1) が必要なく、ファイルが読み込まれた後は内容が変更されても検知されないという違いがある。Postfix のバージョン 2.8 で導入された。
Read the new configuration with "postfix reload".
"postfix reload" で新しい設定を読み込ませる。
Notes:
注:
Some postscreen(8) configuration parameters implement stress-dependent behavior. This is supported only when the default value is stress-dependent (that is, it looks like ${stress?X}${stress:Y}). Other parameters always evaluate as if the stress value is the empty string.
postscreen(8) の設定パラメータは負荷によって挙動を変えることができる。これはデフォルト値が負荷依存になっている（すなわち、${stress?X}${stress:Y} のようになっている）場合のみサポートされる。それ以外のパラメータでは常に負荷値は空文字列だったものとして評価される。
See "Tests before the 220 SMTP server greeting" for details about the logging from these postscreen(8) tests.
これらの postscreen(8) テストでのログ内容の詳細については "Tests before the 220 SMTP server greeting" を参照せよ。
If you run Postfix 2.6 or earlier you must stop and start the master daemon ("postfix stop; postfix start"). This is needed because the Postfix "pass" master service type did not work reliably on all systems.
もし Postfix 2.6 以前を使っているのであれば、master デーモンを停止してから起動しなければならない("postfix stop; postfix start")。これは Postfix の "pass" master サービスタイプががすべてのシステムで不安定であるために必要になる。
postscreen(8) TLS support is available for remote SMTP clients that aren't whitelisted, including clients that need to renew their temporary whitelist status. When a remote SMTP client requests TLS service, postscreen(8) invisibly hands off the connection to a tlsproxy(8) process. Then, tlsproxy(8) encrypts and decrypts the traffic between postscreen(8) and the remote SMTP client. One tlsproxy(8) process can handle multiple SMTP sessions. The number of tlsproxy(8) processes slowly increases with server load, but it should always be much smaller than the number of postscreen(8) TLS sessions.
postscreen(8) の TLS サポートは一時的ホワイトリストのステータスを更新する必要のあるクライアントを含むホワイトリストに載っていないリモートの SMTP クライアントで利用できる。リモートの SMTP クライアントが TLS サービスを要求すると、postscreen(8) は目につかない形で接続を tlsproxy(8) に受け渡す。その後、tlsproxy(8) は postscreen(8) とリモート SMTP クライアントとの間のトラフィックを暗号化/復号する。ひとつの tlsproxy(8) プロセスで複数の SMTP セッションを扱うことができる。tlsproxy(8) プロセスの数はサーバの負荷とともにゆっくり上昇するが、postscreen(8) の TLS セッションの数よりも常にはるかに少なくなるはずである。
TLS support for postscreen(8) and tlsproxy(8) uses the same parameters as with smtpd(8). We recommend that you keep the relevant configuration parameters in main.cf. If you must specify "-o smtpd_mumble=value" parameter overrides in master.cf for a postscreen-protected smtpd(8) service, then you should specify those same parameter overrides for the postscreen(8) and tlsproxy(8) services.
postscreen(8) と tlsproxy(8) の TLS サポートは smtpd(8) と同じパラメータを使う。相当する main.cf の設定パラメータと同じにしておくことを推奨する。もしも postscreen で保護された smtpd(8) のために master.cf で "-o smtpd_hogehoge=value" を上書きしなければならないなら、postscreen(8) と tlsproxy(8) でも同じパラメータを上書き指定するべきである。
For compatibility with smtpd(8), postscreen(8) implements the soft_bounce safety feature. This causes Postfix to reject mail with a "try again" reply code.
smtpd(8) との互換性のため、postscreen(8) は soft_bounce の安全機能を実装している。これにより、Postfix がメールを拒否するときに「後で試せ」という応答を返せるようになる。
To turn this on for all of Postfix, specify "soft_bounce = yes" in main.cf.
Postfix 全体でこれを有効にするには、main.cf で "soft_bounce = yes" を指定する。
To turn this on for postscreen(8) only, append "-o soft_bounce=yes" (note: NO SPACES around '=') to the postscreen entry in master.cf.
postscreen(8) だけでこれを有効にするには、master.cf の postscreen エントリに "-o soft_bounce=yes" を追加する（注: '=' の前後にスペースは入らない）。
Execute "postfix reload" to make the change effective.
変更を有効にするために "postfix reload" を実行する。
After testing, do not forget to remove the soft_bounce feature, otherwise senders won't receive their non-delivery notification until many days later.
テストした後、soft_bounce の機能を消すのを忘れないように。そうしないと、送信者は非配送通知[訳注: いわゆるバウンス、エラーメール、メーラーだえもんさんからのお手紙]を受け取るのが何日も後になってしまうだろう。
To use the postscreen(8) service to block mail, edit main.cf and specify one or more of:
メールをブロックするために postscreen(8) サービスを使うには、main.cf でひとつ以上の値を編集する。
"postscreen_dnsbl_action = enforce", to reject clients that are on DNS blocklists, and to log the helo/sender/recipient information. With good DNSBLs this reduces the amount of load on Postfix SMTP servers dramatically.
DNS ブロックリストでクライアントを拒否して HELO および送受信者情報をログに残すには "postscreen_dnsbl_action = enforce" にする。よい DNSBL であれば Postfix SMTP サーバの負荷は劇的に下がる。[訳注: ひどい DNSBL だと必要なメールも拒否することになるので十分に注意が必要]
"postscreen_greet_action = enforce", to reject clients that talk before their turn, and to log the helo/sender/recipient information. This stops over half of all known-to-be illegitimate connections to Wietse's mail server. It is backup protection for zombies that haven't yet been blacklisted.
自分の順番になる前に喋りだすクライアントを拒否して HELO および送受信者情報をログに残すには、"postscreen_greet_action = enforce" にする。これは Wietese のメールサーバへの不正な接続であるとわかっているもののうち半分以上を止める。まだブラックリストに載っていないゾンビに対する予備の防御になる。
You can also enable "deep protocol tests", but these are more intrusive than the pregreet or DNSBL tests.
"deep protocol tests" を有効にしてもよい。しかし、これらは pregreet や DNSBL テストよりも深く立ち入る。
When a good client passes the "deep protocol tests", postscreen(8) adds the client to the temporary whitelist but it cannot hand off the "live" connection to a Postfix SMTP server process in the middle of the session. Instead, postscreen(8) defers mail delivery attempts with a 4XX status, logs the helo/sender/recipient information, and waits for the client to disconnect.
よいクライアントが "deep protocol tests" をパスすると、postscreen(8) はクライアントを一時的ホワイトリストに追加するが、セッションの途中で Postfix SMTP サーバプロセスに「生きた」接続を受け渡すことはできない。かわりに、postscreen(8) はメール配送を 4XX のステータスで遅延させて、HELO および送受信者情報をログに残し、クライアントが切断するのを待つ。
When the good client comes back in a later session, it is allowed to talk directly to a Postfix SMTP server. See "after_220 Tests after the 220 SMTP server greeting above for limitations with AUTH and other features that clients may need.
よいクライアントが後でまたやってくると、クライアントは Postfix SMTP サーバと直接喋れるようになる。AUTH その他クライアントが必要になるであろう機能の制限については上述の "after_220 Tests after the 220 SMTP server greeting を参照せよ。
An unexpected benefit from "deep protocol tests" is that some "good" clients don't return after the 4XX reply; these clients were not so good after all. Wietse enables "deep protocol tests" on his own internet-facing mail server.
"deep protocol tests" の予期せぬ効用は、いくつかの「よい」クライアントが 4XX 応答を返した後で再度やってこないということである。実はこれらはよいクライアントなんかではない。Wietse はインターネットにつながっている自分のメールサーバで "deep protocol tests" を有効にしている。[訳注: greylisting として使えるということ]
There is also support for permanent blacklisting and whitelisting; see the description of the postscreen_access_list parameter for details.
恒久的ブラックリストとホワイトリストも使うことができる。詳しくは postscreen_whitelist_networks パラメータと postscreen_blacklist_networks パラメータの説明を参照のこと。
To turn off postscreen(8) and handle mail directly with Postfix SMTP server processes:
postscreen(8) を使わないようにして Postfix SMTP サーバプロセスが直接メールを扱えるようにするには:
Comment out the "smtp inet ... postscreen" service in master.cf, including any "-o parameter=value" entries that follow.
master.cf の "smtp inet ... postscreen" サービスを、後に続く "-o parameter=value" のエントリがあればそれごとまとめてコメントアウトする。
/etc/postfix/master.cf: #smtp inet n - n - 1 postscreen # -o parameter=value ...
Comment out the "dnsblog unix ... dnsblog" service in master.cf.
master.cf の "dnsblog unix ... dnsblog" サービスをコメントアウトする[訳注: コメントアウトせず放置しておいてもとくに害はない]。
/etc/postfix/master.cf: #dnsblog unix - - n - 0 dnsblog
Comment out the "smtpd pass ... smtpd" service in master.cf, including any "-o parameter=value" entries that follow.
master.cf の "smtpd pass ... smtpd" サービスを、後に続く "-o parameter=value" のエントリがあればそれごとまとめてコメントアウトする。
/etc/postfix/master.cf: #smtpd pass - - n - - smtpd # -o parameter=value ...
Comment out the "tlsproxy unix ... tlsproxy" service in master.cf, including any "-o parameter=value" entries that follow.
master.cf の "tlsproxy unix ... tlsproxy" サービスを、後に続く "-o parameter=value" のエントリがあればそれごとまとめてコメントアウトする。
/etc/postfix/master.cf: #tlsproxy unix - - n - 0 tlsproxy # -o parameter=value ...
Uncomment the "smtp inet ... smtpd" service in master.cf, including any "-o parameter=value" entries that may follow.
master.cf の "smtp inet ... smtpd" サービスを、後に続く "-o parameter=value" のエントリがあればそれごとまとめてコメントをはずして有効にする。
/etc/postfix/master.cf: smtp inet n - n - - smtpd -o parameter=value ...
Read the new configuration with "postfix reload".
"postfix reload" で新しい設定を読み込ませる。
Many ideas in postscreen(8) were explored in earlier work by Michael Tokarev, in OpenBSD spamd, and in MailChannels Traffic Control.
Wietse threw together a crude prototype with pregreet and dnsbl support in June 2009, because he needed something new for a Mailserver conference presentation in July. Ralf Hildebrandt ran this code on several servers to collect real-world statistics. This version used the dnsblog(8) ad-hoc DNS client program.
Wietse needed new material for a LISA conference presentation in November 2010, so he added support for DNSBL weights and filters in August, followed by a major code rewrite, deep protocol tests, helo/sender/recipient logging, and stress-adaptive behavior in September. Ralf Hildebrandt ran this code on several servers to collect real-world statistics. This version still used the embarrassing dnsblog(8) ad-hoc DNS client program.
Wietse added STARTTLS support in December 2010. This makes postscreen(8) usable for sites that require TLS support. The implementation introduces the tlsproxy(8) event-driven TLS proxy that decrypts/encrypts the sessions for multiple SMTP clients.