Recipient address verification may cause an increased load on down-stream servers in the case of a dictionary attack or a flood of backscatter bounces. Sender address verification may cause your -site to be blacklisted by some providers. See also the "Limitations" section below for more.
Some sites may blacklist you when you are probing them +
Some sites may denylist you when you are probing them too often (a probe is an SMTP session that does not deliver mail), or when you are probing them too often for a non-existent address. This is one reason why you should use sender address verification @@ -413,12 +413,12 @@ you can see what mail would be blocked:
This is also a good way to populate your cache with address verification results before you start to actually reject mail.
-The sender_access restriction is needed to whitelist domains +
The sender_access restriction is needed to allowlist domains or addresses that are known to be OK. Although Postfix will not mark a known-to-be-good address as bad after a probe fails, it is better to be safe than sorry.
-NOTE: You will have to whitelist sites such as securityfocus.com +
NOTE: You will have to allowlist sites such as securityfocus.com and other sites that operate mailing lists that use a different sender address for each posting (VERP). Such addresses pollute the address verification cache quickly, and generate unnecessary diff --git a/postfix/html/OVERVIEW.html b/postfix/html/OVERVIEW.html index 0319e8af8..ba25fdc7b 100644 --- a/postfix/html/OVERVIEW.html +++ b/postfix/html/OVERVIEW.html @@ -737,14 +737,14 @@ those numbers were 92% and 95%, respectively. While smtpd(8) processes remain available for legitimate clients.
-postscreen(8) maintains a temporary whitelist for clients that -pass its tests; by allowing whitelisted clients to skip tests, +
postscreen(8) maintains a temporary allowlist for clients that +pass its tests; by allowing allowlisted clients to skip tests, postscreen(8) minimizes its impact on legitimate email traffic.
The postscreen(8) server is available with Postfix 2.8 and later. To keep the implementation simple, postscreen(8) delegates -DNS white/blacklist lookups to dnsblog(8) server processes, and +DNS allow/denylist lookups to dnsblog(8) server processes, and delegates TLS encryption/decryption to tlsproxy(8) server processes. This delegation is invisible to the remote SMTP client, and is not shown in the diagram below.
diff --git a/postfix/html/POSTSCREEN_README.html b/postfix/html/POSTSCREEN_README.html index 18ec8eda6..b169740b2 100644 --- a/postfix/html/POSTSCREEN_README.html +++ b/postfix/html/POSTSCREEN_README.html @@ -36,8 +36,8 @@ requires client authentication. Alternatively, a site could set up a dedicated, non-postscreen, "port 25" server that provides submission service and client authentication, but no MX service. -postscreen(8) maintains a temporary whitelist for clients that -pass its tests; by allowing whitelisted clients to skip tests, +
postscreen(8) maintains a temporary allowlist for clients that +pass its tests; by allowing allowlisted clients to skip tests, postscreen(8) minimizes its impact on legitimate email traffic.
@@ -110,11 +110,11 @@ spending most of its resources not receiving email. decision based on a single measurement. This is necessary because many zombies try to fly under the radar and avoid spamming the same site repeatedly. Once postscreen(8) decides that a client is -not-a-zombie, it whitelists the client temporarily to avoid further +not-a-zombie, it allowlists the client temporarily to avoid further delays for legitimate mail.Zombies have challenges too: they have only a limited amount -of time to deliver spam before their IP address becomes blacklisted. +of time to deliver spam before their IP address becomes denylisted. 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 @@ -122,7 +122,7 @@ mail even when the server tells them to go away.
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 +IP address is denylisted. Second, postscreen(8) looks for protocol compromises that are made to speed up delivery. These are good indicators for making is-a-zombie decisions based on single measurements.
@@ -138,8 +138,8 @@ and that is the problem that postscreen(8) is foFor each connection from an SMTP client, postscreen(8) performs a number of tests in the order as described below. Some tests introduce a delay of -a few seconds. postscreen(8) maintains a temporary whitelist for -clients that pass its tests; by allowing whitelisted clients to +a few seconds. postscreen(8) maintains a temporary allowlist for +clients that pass its tests; by allowing allowlisted clients to skip tests, postscreen(8) minimizes its impact on legitimate email traffic.
@@ -158,25 +158,25 @@ overhead for legitimate clients.Before engaging in SMTP-level tests. postscreen(8) queries a -number of local black and whitelists. These tests speed up the +number of local deny and allowlists. These tests speed up the handling of known clients.
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.
+one would specify something that allowlists local networks, followed +by a CIDR table for selective allow- and denylisting.Example:
@@ -187,7 +187,7 @@ by a CIDR table for selective white- and blacklisting. /etc/postfix/postscreen_access.cidr: # Rules are evaluated in the order as specified. - # Blacklist 192.168.* except 192.168.0.1. + # Denylist 192.168.* except 192.168.0.1. 192.168.0.1 permit 192.168.0.0/16 reject @@ -203,7 +203,7 @@ details. WHITELISTED [address]:port -The whitelist action is not configurable: immediately hand off the +
The allowlist action is not configurable: immediately hand off the connection to a Postfix SMTP server process.
When the SMTP client address matches a "reject" action, @@ -218,21 +218,21 @@ connection to a Postfix SMTP server process.
that is taken next. See "When tests fail before the 220 SMTP server greeting" below. -The postscreen(8) daemon maintains a temporary -whitelist for SMTP client IP addresses that have passed all +allowlist 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 +specifies the location of the temporary allowlist. The +temporary allowlist is not used for SMTP client addresses that appear on the permanent access list.
-By default the temporary whitelist is not shared with other +
By default the temporary allowlist is not shared with other postscreen(8) daemons. See Sharing -the temporary whitelist below for alternatives.
+the temporary allowlist below for alternatives.When the SMTP client address appears on the temporary -whitelist, postscreen(8) logs this with the client address and port +allowlist, postscreen(8) logs this with the client address and port number as:
@@ -241,19 +241,19 @@ number as: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 +excluded from further tests until its temporary allowlist entry expires, as controlled with the postscreen_*_ttl parameters. Expired entries are silently renewed if possible.
MX Policy test
When the remote SMTP client is not on the static access list -or temporary whitelist, postscreen(8) can implement a number of -whitelist tests, before it grants the client a temporary whitelist +or temporary allowlist, postscreen(8) can implement a number of +allowlist tests, before it grants the client a temporary allowlist status that allows it to talk to a Postfix SMTP server process.
When postscreen(8) is configured to monitor all primary and -backup MX addresses, it can refuse to whitelist clients that connect +backup MX addresses, it can refuse to allowlist clients that connect to a backup MX address only (an old spammer trick to take advantage of backup MX hosts with weaker anti-spam policies than primary MX hosts).
@@ -274,7 +274,7 @@ files and "refresh" the network protocol stack. (this step is needed when you have specified inet_interfaces in main.cf). -
Then, configure postscreen(8) to deny the temporary whitelist +
Then, configure postscreen(8) to deny the temporary allowlist status on the backup MX address(es). An example for Wietse's server is:
@@ -283,13 +283,13 @@ server is: postscreen_whitelist_interfaces = !168.100.189.8 static:all -Translation: allow clients to obtain the temporary whitelist +
Translation: allow clients to obtain the temporary allowlist status on all server IP addresses except 168.100.189.8, which is a backup MX address.
-When a non-whitelisted client connects the backup MX address, +
When a non-allowlisted client connects the backup MX address, postscreen(8) logs this with the client address and port number as:
@@ -299,9 +299,9 @@ backup MX address.Translation: the client at [address]:port connected to -the backup MX address 168.100.189.8 while it was not whitelisted. -The client will not be granted the temporary whitelist status, even -if passes all the whitelist tests described below.
+the backup MX address 168.100.189.8 while it was not allowlisted. +The client will not be granted the temporary allowlist status, even +if passes all the allowlist tests described below.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" +adds the client to the temporary allowlist 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).
@@ -320,7 +320,7 @@ for the short postscreen_greet_w/etc/postfix/main.cf: - # Exclude broken clients by whitelisting. Clients in mynetworks - # should always be whitelisted. + # Exclude broken clients by allowlisting. Clients in mynetworks + # should always be allowlisted. postscreen_access_list = permit_mynetworks, cidr:/etc/postfix/postscreen_access.cidr @@ -359,7 +359,7 @@ an empty teaser banner:/etc/postfix/main.cf: - # Disable the teaser banner (try whitelisting first if you can). + # Disable the teaser banner (try allowlisting first if you can). postscreen_greet_banner =@@ -382,11 +382,11 @@ and \n for newline). is taken next. See "When tests fail before the 220 SMTP server greeting" below. -DNS White/blacklist test
+DNS Allow/denylist test
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). +factors (positive weights for denylisting, negative for allowlisting). These servers will be queried in parallel with the reverse client IP address. This test is disabled by default.
@@ -416,7 +416,7 @@ before the 220 SMTP server greeting
When the client address matches the permanent blacklist, or +
When the client address matches the permanent denylist, 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.
@@ -736,7 +736,7 @@ parameters control these limits.When a new SMTP client passes all tests (i.e. it is not whitelisted +
When a new SMTP client passes all tests (i.e. it is not allowlisted via some mechanism), postscreen(8) logs this as:
@@ -745,8 +745,8 @@ via some mechanism), postscreen(8) logs this as: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 +creates a temporary allowlist entry that excludes the client IP +address from further tests until the temporary allowlist entry expires, as controlled with the postscreen_*_ttl parameters.
When no "deep protocol tests" are @@ -783,7 +783,7 @@ mail
/etc/postfix/main.cf: - # Exclude broken clients by whitelisting. Clients in mynetworks - # should always be whitelisted. + # Exclude broken clients by allowlisting. Clients in mynetworks + # should always be allowlisted. postscreen_access_list = permit_mynetworks, cidr:/etc/postfix/postscreen_access.cidr @@ -921,8 +921,8 @@ work reliably on all systems.postscreen(8) TLS configuration
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 +that aren't allowlisted, including clients that need to renew their +temporary allowlist 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 @@ -976,7 +976,7 @@ Postfix SMTP servers dramatically.
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. +zombies that haven't yet been denylisted.
You can also enable "deep protocol tests", but these are more intrusive than the pregreet or DNSBL @@ -984,7 +984,7 @@ tests.
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 +allowlist 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 @@ -1000,12 +1000,12 @@ tests
Unfortunately, some senders will retry requests from different -IP addresses, and may never get whitelisted. For this reason, +IP addresses, and may never get allowlisted. For this reason, Wietse stopped using "deep protocol tests" on his own internet-facing mail server.
-There is also support for permanent blacklisting and -whitelisting; see the description of the postscreen_access_list +
There is also support for permanent denylisting and +allowlisting; see the description of the postscreen_access_list parameter for details.
@@ -1070,15 +1070,15 @@ may follow. -By default, the temporary whitelist is not shared between +
By default, the temporary allowlist is not shared between multiple postscreen(8) daemons. To enable sharing, choose one of the following options:
A non-persistent memcache: temporary whitelist can be shared +
A non-persistent memcache: temporary allowlist can be shared between postscreen(8) daemons on the same host or different hosts. Disable cache cleanup (postscreen_cache_cleanup_interval = 0) in all postscreen(8) daemons because memcache: has no @@ -1086,7 +1086,7 @@ of the following options:
persistent backup). This requires Postfix 2.9 or later.- # Example 1: non-persistent memcache: whitelist. + # Example 1: non-persistent memcache: allowlist. /etc/postfix/main.cf: postscreen_cache_map = memcache:/etc/postfix/postscreen_cache postscreen_cache_cleanup_interval = 0 @@ -1097,7 +1097,7 @@ of the following options:
- A persistent lmdb: temporary whitelist can be shared between + A persistent lmdb: temporary allowlist can be shared between postscreen(8) daemons that run under the same master(8) daemon, or under different master(8) daemons on the same host. Disable cache cleanup (postscreen_cache_cleanup_interval = 0) in all @@ -1105,28 +1105,28 @@ of the following options:
cleanup. This requires Postfix 2.11 or later.- # Example 2: persistent lmdb: whitelist. + # Example 2: persistent lmdb: allowlist. /etc/postfix/main.cf: postscreen_cache_map = lmdb:$data_directory/postscreen_cache # See note 1 below. # postscreen_cache_cleanup_interval = 0-
Other kinds of persistent temporary whitelist can be shared +
Other kinds of persistent temporary allowlist can be shared only between postscreen(8) daemons that run under the same - master(8) daemon. In this case, temporary whitelist access must + master(8) daemon. In this case, temporary allowlist access must be shared through the proxymap(8) daemon. This requires Postfix 2.9 or later.
- # Example 3: proxied btree: whitelist. + # Example 3: proxied btree: allowlist. /etc/postfix/main.cf: postscreen_cache_map = proxy:btree:/var/lib/postfix/postscreen_cache # See note 1 below. # postscreen_cache_cleanup_interval = 0 - # Example 4: proxied btree: whitelist with memcache: accelerator. + # Example 4: proxied btree: allowlist with memcache: accelerator. /etc/postfix/main.cf: postscreen_cache_map = memcache:/etc/postfix/postscreen_cache proxy_write_maps = @@ -1189,4 +1189,3 @@ POP, IMAP, NNTP, and FTP over TLS.