2
0
mirror of https://github.com/vdukhovni/postfix synced 2025-08-29 13:18:12 +00:00

postfix-3.6-20210216

This commit is contained in:
Wietse Venema 2021-02-16 00:00:00 -05:00 committed by Viktor Dukhovni
parent 2a17daa3db
commit 320af90614
55 changed files with 570 additions and 554 deletions

View File

@ -25398,3 +25398,21 @@ Apologies for any names omitted.
Documentation: added a jq example to the postsuper(1) manpage.
File: postsuper/postsuper.c.
20210216
Documentation: replaced white/blacklist with allow/denylist,
except in parameter names and lopging. Those will need a
compatibilty safety net to avoid breaking log analysis tools.
proto/ADDRESS_VERIFICATION_README.html, proto/cidr_table,
proto/OVERVIEW.html, proto/postconf.proto,
proto/POSTSCREEN_README.html, proto/SMTPD_ACCESS_README.html,
proto/SMTPD_POLICY_README.html, proto/STRESS_README.html,
dns/dns_lookup.c, dnsblog/dnsblog.c, global/server_acl.c,
postfix/postfix.c, postscreen/postscreen.c,
postscreen/postscreen_dnsbl.c, postscreen/postscreen_early.c,
postscreen/postscreen.h, postscreen/postscreen_misc.c,
postscreen/postscreen_smtpd.c, postscreen/postscreen_tests.c,
proxymap/proxymap.c, smtpd/smtpd.c, smtpd/smtpd_check.c,
smtpd/smtpd_dnswl.in, smtpd/smtpd_dnswl.ref, tlsproxy/tlsproxy.c,
verify/verify.c.

View File

@ -6,7 +6,7 @@ WWAARRNNIINNGG
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
Sender address verification may cause your site to be denylisted by some
providers. See also the "Limitations" section below for more.
WWhhaatt PPoossttffiixx aaddddrreessss vveerriiffiiccaattiioonn ccaann ddoo ffoorr yyoouu
@ -89,11 +89,11 @@ LLiimmiittaattiioonnss ooff aaddddrreessss vveerriiffi
mail for a remote address can bounce AFTER a preferred MTA accepts the
recipient address, or AFTER a preferred MTA accepts the message content.
* Some sites may blacklist 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 sparingly, if at all, when your site
receives lots of email.
* 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 sparingly, if at all, when your site receives
lots of email.
* Normally, address verification probe messages follow the same path as
regular mail. However, some sites send mail to the Internet via an
@ -260,11 +260,11 @@ 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 or addresses that
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 and other
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 sender verification probes.

View File

@ -367,12 +367,12 @@ queues.
While postscreen(8) keeps the zombies away, more 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)
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
the implementation simple, postscreen(8) delegates 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.

View File

@ -20,8 +20,8 @@ port 587 which 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) minimizes its
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.
postscreen(8) is part of a multi-layer defense.
@ -70,17 +70,17 @@ not receiving email.
The main challenge for postscreen(8) is to make an is-a-zombie 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
decides that a client is 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. To speed up spam deliveries,
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 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.
postscreen(8) determines if the remote SMTP client 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.
@ -95,8 +95,8 @@ GGeenneerraall ooppeerraattiioonn
For 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 skip tests, postscreen(8)
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.
By default, postscreen(8) hands off all connections to a Postfix SMTP server
@ -114,18 +114,18 @@ clients.
QQuuiicckk tteessttss bbeeffoorree eevveerryytthhiinngg eellssee
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.
deny and allowlists. These tests speed up the handling of known clients.
* Permanent white/blacklist test
* Temporary whitelist test
* Permanent allow/denylist test
* Temporary allowlist test
* MX Policy test
PPeerrmmaanneenntt wwhhiittee//bbllaacckklliisstt tteesstt
PPeerrmmaanneenntt aallllooww//ddeennyylliisstt tteesstt
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.
something that allowlists local networks, followed by a CIDR table for
selective allow- and denylisting.
Example:
@ -135,7 +135,7 @@ Example:
/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
@ -146,7 +146,7 @@ with the client address and port number as:
WWHHIITTEELLIISSTTEEDD [address]:port
The whitelist action is not configurable: immediately hand off the connection
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, postscreen(8) logs this
@ -157,36 +157,36 @@ with the client address and port number as:
The postscreen_blacklist_action parameter specifies the action that is taken
next. See "When tests fail before the 220 SMTP server greeting" below.
TTeemmppoorraarryy wwhhiitteelliisstt tteesstt
TTeemmppoorraarryy aalllloowwlliisstt tteesstt
The postscreen(8) daemon maintains a temporary whitelist for SMTP client IP
The postscreen(8) daemon maintains a temporary 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 that
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 postscreen(8)
daemons. See Sharing the temporary whitelist below for alternatives.
By default the temporary allowlist is not shared with other postscreen(8)
daemons. See Sharing the temporary allowlist below for alternatives.
When the SMTP client address appears on the temporary whitelist, postscreen(8)
When the SMTP client address appears on the temporary allowlist, postscreen(8)
logs this with the client address and port number as:
PPAASSSS OOLLDD [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
its temporary allowlist entry expires, as controlled with the postscreen_*_ttl
parameters. Expired entries are silently renewed if possible.
MMXX PPoolliiccyy tteesstt
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 status that allows it to talk to a
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 to a 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).
@ -202,24 +202,24 @@ weaker anti-spam policies than primary MX hosts).
Second, configure Postfix to listen on the new IP address (this step is
needed when you have specified inet_interfaces in main.cf).
* Then, configure postscreen(8) to deny the temporary whitelist status on the
* Then, configure postscreen(8) to deny the temporary allowlist status on the
backup MX address(es). An example for Wietse's server is:
/etc/postfix/main.cf:
postscreen_whitelist_interfaces = !168.100.189.8 static:all
Translation: allow clients to obtain the temporary whitelist status on all
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, postscreen(8)
When a non-allowlisted client connects the backup MX address, postscreen(8)
logs this with the client address and port number as:
CCOONNNNEECCTT ffrroomm [address]:port ttoo [[116688..110000..118899..88]]::2255
WWHHIITTEELLIISSTT VVEETTOO [address]:port
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
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.
TTeessttss bbeeffoorree tthhee 222200 SSMMTTPP sseerrvveerr ggrreeeettiinngg
@ -229,13 +229,13 @@ The postscreen_greet_wait parameter specifies a short time interval before the
parallel.
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
configured, postscreen(8) 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).
* Pregreet test
* DNS White/blacklist test
* DNS Allow/denylist test
* When tests fail before the 220 SMTP server greeting
PPrreeggrreeeett tteesstt
@ -256,8 +256,8 @@ network testing tools, either exclude them from all tests with the
postscreen_access_list feature or else specify an empty teaser banner:
/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
@ -265,7 +265,7 @@ postscreen_access_list feature or else specify an empty teaser banner:
192.168.254.0/24 permit
/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 =
When an SMTP client sends a command before the postscreen_greet_wait time has
@ -282,11 +282,11 @@ return and \n for newline).
The postscreen_greet_action parameter specifies the action that is taken next.
See "When tests fail before the 220 SMTP server greeting" below.
DDNNSS WWhhiittee//bbllaacckklliisstt tteesstt
DDNNSS AAllllooww//ddeennyylliisstt tteesstt
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
for denylisting, negative for allowlisting). These servers will be queried in
parallel with the reverse client IP address. This test is disabled by default.
CAUTION: when postscreen rejects mail, its SMTP reply contains the DNSBL
@ -308,7 +308,7 @@ tests fail before the 220 SMTP server greeting" below.
WWhheenn tteessttss ffaaiill bbeeffoorree tthhee 222200 SSMMTTPP sseerrvveerr ggrreeeettiinngg
When the client address matches the permanent blacklist, or when the client
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.
@ -526,14 +526,14 @@ control these limits.
WWhheenn aallll tteessttss ssuucccceeeedd
When a new SMTP client passes all tests (i.e. it is not whitelisted via some
When a new SMTP client passes all tests (i.e. it is not allowlisted via some
mechanism), postscreen(8) logs this as:
PPAASSSS NNEEWW [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
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 configured, postscreen(8) hands off the
@ -558,7 +558,7 @@ systems.
* postscreen(8) TLS configuration
* Blocking mail with postscreen(8)
* Turning off postscreen(8)
* Sharing the temporary whitelist
* Sharing the temporary allowlist
TTuurrnniinngg oonn ppoossttssccrreeeenn((88)) wwiitthhoouutt bblloocckkiinngg mmaaiill
@ -572,8 +572,8 @@ mail:
broken SMTP implementations):
/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
@ -655,7 +655,7 @@ Notes:
ppoossttssccrreeeenn((88)) TTLLSS ccoonnffiigguurraattiioonn
postscreen(8) TLS support is available for remote SMTP clients that aren't
whitelisted, including clients that need to renew their temporary whitelist
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
@ -697,13 +697,13 @@ more of:
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.
denylisted.
* You can also enable "deep protocol tests", but these are more intrusive
than the pregreet or DNSBL 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"
client to the temporary 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
@ -719,10 +719,10 @@ more of:
after all.
Unfortunately, some senders will retry requests from different IP
addresses, and may never get whitelisted. For this reason, Wietse stopped
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
* There is also support for permanent denylisting and allowlisting; see the
description of the postscreen_access_list parameter for details.
TTuurrnniinngg ooffff ppoossttssccrreeeenn((88))
@ -765,18 +765,18 @@ processes:
6. Read the new configuration with "postfix reload".
SShhaarriinngg tthhee tteemmppoorraarryy wwhhiitteelliisstt
SShhaarriinngg tthhee tteemmppoorraarryy aalllloowwlliisstt
By default, the temporary whitelist is not shared between multiple postscreen
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 between
* 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 first-next API (but see example 4 below
for memcache: with 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
@ -785,32 +785,32 @@ By default, the temporary whitelist is not shared between multiple postscreen
memcache = inet:127.0.0.1:11211
key_format = postscreen:%s
* A persistent lmdb: temporary whitelist can be shared between postscreen(8)
* 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 postscreen(8) daemons except
one that is responsible for cache 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 only between
* 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 be shared through the proxymap(8)
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 =

View File

@ -23,7 +23,7 @@ RReellaayy ccoonnttrrooll,, jjuunnkk mmaaiill ccoonnttr
In a distant past, the Internet was a friendly environment. Mail servers
happily forwarded mail on behalf of anyone towards any destination. On today's
Internet, spammers abuse servers that forward mail from arbitrary systems, and
abused systems end up on anti-spammer blacklists. See, for example, the
abused systems end up on anti-spammer denylists. See, for example, the
information on http://www.mail-abuse.org/ and other websites.
By default, Postfix has a moderately restrictive approach to mail relaying.
@ -50,11 +50,11 @@ email.
Protocol-oriented access controls become less useful over time as spammers
and worm writers learn to read RFC documents.
* Blacklist oriented: some SMTP server access controls query blacklists with
* Denylist oriented: some SMTP server access controls query denylists with
known to be bad sites such as open mail relays, open web proxies, and home
computers that have been compromised and that are under remote control by
criminals. The effectiveness of these blacklists depends on how complete
and how up to date they are.
criminals. The effectiveness of these denylists depends on how complete and
how up to date they are.
* Threshold oriented: some SMTP server access controls attempt to raise the
bar by either making the client do more work (greylisting) or by asking for
@ -160,7 +160,7 @@ Each restriction list is evaluated from left to right until some restriction
produces a result of PERMIT, REJECT or DEFER (try again later). The end of each
list is equivalent to a PERMIT result. By placing a PERMIT restriction before a
REJECT restriction you can make exceptions for specific clients or users. This
is called whitelisting; the fourth example above allows mail from local
is called allowlisting; the fourth example above allows mail from local
networks but otherwise rejects mail to arbitrary destinations.
The table below summarizes the purpose of each SMTP access restriction list.
@ -248,7 +248,7 @@ Benefits of delayed restriction evaluation, and of restriction mixing:
logging only the client hostname and IP address and not knowing whose mail
was being blocked.
* Mixing is needed for complex whitelisting policies. For example, in order
* Mixing is needed for complex allowlisting policies. For example, in order
to reject local sender addresses in mail from non-local clients, you need
to be able to mix restrictions on client information with restrictions on
sender information in the same restriction list. Without this ability, many

View File

@ -516,7 +516,7 @@ If you turn on greylisting for all mail you may want to make exceptions for
mailing lists that use one-time sender addresses, because each message will be
delayed due to greylisting, and the one-time sender addresses can pollute your
greylist database relatively quickly. Instead of making exceptions, you can
automatically whitelist clients that survive greylisting repeatedly; this
automatically allowlist clients that survive greylisting repeatedly; this
avoids most of the delays and most of the database pollution problem.
1 /etc/postfix/main.cf:
@ -578,11 +578,11 @@ $database_name="/var/mta/greylist.db";
$greylist_delay=60;
#
# Auto-whitelist threshold. Specify 0 to disable, or the number of
# Auto-allowlist threshold. Specify 0 to disable, or the number of
# successful "come backs" after which a client is no longer subject
# to greylisting.
#
$auto_whitelist_threshold = 10;
$auto_allowlist_threshold = 10;
#
# Demo SMTPD access policy routine. The result is an action just like
@ -595,10 +595,10 @@ sub smtpd_access_policy {
# Open the database on the fly.
open_database() unless $database_obj;
# Search the auto-whitelist.
if ($auto_whitelist_threshold > 0) {
# Search the auto-allowlist.
if ($auto_allowlist_threshold > 0) {
$count = read_database($attr{"client_address"});
if ($count > $auto_whitelist_threshold) {
if ($count > $auto_allowlist_threshold) {
return "dunno";
}
}
@ -627,8 +627,8 @@ sub smtpd_access_policy {
#
syslog $syslog_priority, "request age %d", $now - $time_stamp if $verbose;
if ($now - $time_stamp > $greylist_delay) {
# Update the auto-whitelist.
if ($auto_whitelist_threshold > 0) {
# Update the auto-allowlist.
if ($auto_allowlist_threshold > 0) {
update_database($attr{"client_address"}, $count + 1);
}
return "dunno";

View File

@ -259,7 +259,7 @@ to Postfix.
maps. The Postfix SMTP server will reject mail and disconnect without
waiting for the remote SMTP client to send a QUIT command.
* To hang up connections from blacklisted zombies, you can set specific
* To hang up connections from denylisted zombies, you can set specific
Postfix SMTP server reject codes for specific RBLs, and for individual
responses from specific RBLs. We'll use zen.spamhaus.org as an example; by
the time you read this document, details may have changed. Right now, their

View File

@ -22,7 +22,7 @@
<p> 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 "<a
site to be denylisted by some providers. See also the "<a
href="#limitations">Limitations</a>" section below for more. </p>
<h2><a name="summary">What Postfix address verification can do for you</a></h2>
@ -211,7 +211,7 @@ address is deliverable. In reality, mail for a remote address can
bounce AFTER a preferred MTA accepts the recipient address, or AFTER
a preferred MTA accepts the message content. </p>
<li> <p> Some sites may blacklist you when you are probing them
<li> <p> 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: </p>
<p> This is also a good way to populate your cache with address
verification results before you start to actually reject mail. </p>
<p> The sender_access restriction is needed to whitelist domains
<p> 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. </p>
<p> NOTE: You will have to whitelist sites such as securityfocus.com
<p> 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

View File

@ -737,14 +737,14 @@ those numbers were 92% and 95%, respectively. While <a href="postscreen.8.html"
keeps the zombies away, more <a href="smtpd.8.html">smtpd(8)</a> processes remain available
for legitimate clients. </p>
<p> <a href="postscreen.8.html">postscreen(8)</a> maintains a temporary whitelist for clients that
pass its tests; by allowing whitelisted clients to skip tests,
<p> <a href="postscreen.8.html">postscreen(8)</a> maintains a temporary allowlist for clients that
pass its tests; by allowing allowlisted clients to skip tests,
<a href="postscreen.8.html">postscreen(8)</a> minimizes its impact on legitimate email traffic.
</p>
<p> The <a href="postscreen.8.html">postscreen(8)</a> server is available with Postfix 2.8 and
later. To keep the implementation simple, <a href="postscreen.8.html">postscreen(8)</a> delegates
DNS white/blacklist lookups to <a href="dnsblog.8.html">dnsblog(8)</a> server processes, and
DNS allow/denylist lookups to <a href="dnsblog.8.html">dnsblog(8)</a> server processes, and
delegates TLS encryption/decryption to <a href="tlsproxy.8.html">tlsproxy(8)</a> server processes.
This delegation is invisible to the remote SMTP client, and is not
shown in the diagram below. </p>

View File

@ -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. </p>
<p> <a href="postscreen.8.html">postscreen(8)</a> maintains a temporary whitelist for clients that
pass its tests; by allowing whitelisted clients to skip tests,
<p> <a href="postscreen.8.html">postscreen(8)</a> maintains a temporary allowlist for clients that
pass its tests; by allowing allowlisted clients to skip tests,
<a href="postscreen.8.html">postscreen(8)</a> minimizes its impact on legitimate email traffic.
</p>
@ -110,11 +110,11 @@ spending most of its resources not receiving email. </p>
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 <a href="postscreen.8.html">postscreen(8)</a> 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. </p>
<p> 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. </p>
<p> <a href="postscreen.8.html">postscreen(8)</a> uses a variety of measurements to recognize
zombies. First, <a href="postscreen.8.html">postscreen(8)</a> determines if the remote SMTP client
IP address is blacklisted. Second, <a href="postscreen.8.html">postscreen(8)</a> looks for protocol
IP address is denylisted. Second, <a href="postscreen.8.html">postscreen(8)</a> 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. </p>
@ -138,8 +138,8 @@ and that is the problem that <a href="postscreen.8.html">postscreen(8)</a> is fo
<p> For each connection from an SMTP client, <a href="postscreen.8.html">postscreen(8)</a> performs
a number of tests
in the order as described below. Some tests introduce a delay of
a few seconds. <a href="postscreen.8.html">postscreen(8)</a> maintains a temporary whitelist for
clients that pass its tests; by allowing whitelisted clients to
a few seconds. <a href="postscreen.8.html">postscreen(8)</a> maintains a temporary allowlist for
clients that pass its tests; by allowing allowlisted clients to
skip tests, <a href="postscreen.8.html">postscreen(8)</a> minimizes its impact on legitimate email
traffic. </p>
@ -158,25 +158,25 @@ overhead for legitimate clients. </p>
<h2> <a name="quick">Quick tests before everything else</a> </h2>
<p> Before engaging in SMTP-level tests. <a href="postscreen.8.html">postscreen(8)</a> 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. </p>
<ul>
<li> <a href="#perm_white_black"> Permanent white/blacklist test </a>
<li> <a href="#perm_white_black"> Permanent allow/denylist test </a>
<li> <a href="#temp_white"> Temporary whitelist test </a>
<li> <a href="#temp_white"> Temporary allowlist test </a>
<li> <a href="#white_veto"> MX Policy test </a>
</ul>
<h3> <a name="perm_white_black"> Permanent white/blacklist test </a> </h3>
<h3> <a name="perm_white_black"> Permanent allow/denylist test </a> </h3>
<p> The <a href="postconf.5.html#postscreen_access_list">postscreen_access_list</a> parameter (default: <a href="postconf.5.html#permit_mynetworks">permit_mynetworks</a>)
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. </p>
one would specify something that allowlists local networks, followed
by a CIDR table for selective allow- and denylisting. </p>
<p> Example: </p>
@ -187,7 +187,7 @@ by a CIDR table for selective white- and blacklisting. </p>
/etc/postfix/postscreen_access.<a href="cidr_table.5.html">cidr</a>:
# 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
</pre>
@ -203,7 +203,7 @@ details. </p>
<b>WHITELISTED</b> <i>[address]:port</i>
</pre>
<p> The whitelist action is not configurable: immediately hand off the
<p> The allowlist action is not configurable: immediately hand off the
connection to a Postfix SMTP server process. </p>
<p> When the SMTP client address matches a "reject" action,
@ -218,21 +218,21 @@ connection to a Postfix SMTP server process. </p>
that is taken next. See "<a href="#fail_before_220">When tests
fail before the 220 SMTP server greeting</a>" below. </p>
<h3> <a name="temp_white"> Temporary whitelist test </a> </h3>
<h3> <a name="temp_white"> Temporary allowlist test </a> </h3>
<p> The <a href="postscreen.8.html">postscreen(8)</a> daemon maintains a <i>temporary</i>
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 <a href="postconf.5.html#postscreen_cache_map">postscreen_cache_map</a> 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 <i>permanent</i> access list. </p>
<p> By default the temporary whitelist is not shared with other
<p> By default the temporary allowlist is not shared with other
postscreen(8) daemons. See <a href="#temp_white_sharing"> Sharing
the temporary whitelist </a> below for alternatives. </p>
the temporary allowlist </a> below for alternatives. </p>
<p> When the SMTP client address appears on the temporary
whitelist, <a href="postscreen.8.html">postscreen(8)</a> logs this with the client address and port
allowlist, <a href="postscreen.8.html">postscreen(8)</a> logs this with the client address and port
number as: </p>
<pre>
@ -241,19 +241,19 @@ number as: </p>
<p> 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. </p>
<h3> <a name="white_veto"> MX Policy test </a> </h3>
<p> When the remote SMTP client is not on the static access list
or temporary whitelist, <a href="postscreen.8.html">postscreen(8)</a> can implement a number of
whitelist tests, before it grants the client a temporary whitelist
or temporary allowlist, <a href="postscreen.8.html">postscreen(8)</a> 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. </p>
<p> When <a href="postscreen.8.html">postscreen(8)</a> 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). </p>
@ -274,7 +274,7 @@ files and "refresh" the network protocol stack. </p>
(this step is needed when you have specified <a href="postconf.5.html#inet_interfaces">inet_interfaces</a> in
<a href="postconf.5.html">main.cf</a>). </p>
<li> <p> Then, configure <a href="postscreen.8.html">postscreen(8)</a> to deny the temporary whitelist
<li> <p> Then, configure <a href="postscreen.8.html">postscreen(8)</a> to deny the temporary allowlist
status on the backup MX address(es). An example for Wietse's
server is: </p>
@ -283,13 +283,13 @@ server is: </p>
<a href="postconf.5.html#postscreen_whitelist_interfaces">postscreen_whitelist_interfaces</a> = !168.100.189.8 <a href="DATABASE_README.html#types">static</a>:all
</pre>
<p> Translation: allow clients to obtain the temporary whitelist
<p> 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. </p>
</ul>
<p> When a non-whitelisted client connects the backup MX address,
<p> When a non-allowlisted client connects the backup MX address,
<a href="postscreen.8.html">postscreen(8)</a> logs this with the client address and port number as:
</p>
@ -299,9 +299,9 @@ backup MX address. </p>
</pre>
<p> Translation: the client at <i>[address]:port</i> 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. </p>
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. </p>
<h2> <a name="before_220"> Tests before the 220 SMTP server greeting </a> </h2>
@ -311,7 +311,7 @@ interval before the "220 <i>text</i>..." server greeting, where
<p> When a good client passes these tests, and no "<a
href="#after_220">deep protocol tests</a>" 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 <a href="postscreen.8.html">postscreen(8)</a> never even existed (except of course
for the short <a href="postconf.5.html#postscreen_greet_wait">postscreen_greet_wait</a> delay). </p>
@ -320,7 +320,7 @@ for the short <a href="postconf.5.html#postscreen_greet_wait">postscreen_greet_w
<li> <a href="#pregreet"> Pregreet test </a>
<li> <a href="#dnsbl"> DNS White/blacklist test </a>
<li> <a href="#dnsbl"> DNS Allow/denylist test </a>
<li> <a href="#fail_before_220">When tests fail before the 220 SMTP server greeting</a>
@ -348,8 +348,8 @@ an empty teaser banner: </p>
<pre>
/etc/postfix/<a href="postconf.5.html">main.cf</a>:
# Exclude broken clients by whitelisting. Clients in <a href="postconf.5.html#mynetworks">mynetworks</a>
# should always be whitelisted.
# Exclude broken clients by allowlisting. Clients in <a href="postconf.5.html#mynetworks">mynetworks</a>
# should always be allowlisted.
<a href="postconf.5.html#postscreen_access_list">postscreen_access_list</a> = <a href="postconf.5.html#permit_mynetworks">permit_mynetworks</a>,
<a href="cidr_table.5.html">cidr</a>:/etc/postfix/postscreen_access.cidr
@ -359,7 +359,7 @@ an empty teaser banner: </p>
<pre>
/etc/postfix/<a href="postconf.5.html">main.cf</a>:
# Disable the teaser banner (try whitelisting first if you can).
# Disable the teaser banner (try allowlisting first if you can).
<a href="postconf.5.html#postscreen_greet_banner">postscreen_greet_banner</a> =
</pre>
@ -382,11 +382,11 @@ and \n for newline). </p>
is taken next. See "<a href="#fail_before_220">When tests fail
before the 220 SMTP server greeting</a>" below. </p>
<h3> <a name="dnsbl"> DNS White/blacklist test </a> </h3>
<h3> <a name="dnsbl"> DNS Allow/denylist test </a> </h3>
<p> The <a href="postconf.5.html#postscreen_dnsbl_sites">postscreen_dnsbl_sites</a> 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. </p>
@ -416,7 +416,7 @@ before the 220 SMTP server greeting</a>" below. </p>
<h3> <a name="fail_before_220">When tests fail before the 220 SMTP server greeting</a> </h3>
<p> When the client address matches the permanent blacklist, or
<p> When the client address matches the permanent denylist, or
when the client fails the pregreet or DNSBL tests, the action is
specified with <a href="postconf.5.html#postscreen_blacklist_action">postscreen_blacklist_action</a>, <a href="postconf.5.html#postscreen_greet_action">postscreen_greet_action</a>,
or <a href="postconf.5.html#postscreen_dnsbl_action">postscreen_dnsbl_action</a>, respectively. </p>
@ -736,7 +736,7 @@ parameters control these limits. </p>
<h2> <a name="victory">When all tests succeed</a> </h2>
<p> When a new SMTP client passes all tests (i.e. it is not whitelisted
<p> When a new SMTP client passes all tests (i.e. it is not allowlisted
via some mechanism), <a href="postscreen.8.html">postscreen(8)</a> logs this as: </p>
<pre>
@ -745,8 +745,8 @@ via some mechanism), <a href="postscreen.8.html">postscreen(8)</a> logs this as:
<p> Where <i>[address]:port</i> are the client IP address and port.
Then, <a href="postscreen.8.html">postscreen(8)</a>
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. </p>
<p> When no "<a href="#after_220">deep protocol tests</a>" are
@ -783,7 +783,7 @@ mail</a>
<li> <a href="#turnoff"> Turning off postscreen(8) </a>
<li> <a href="#temp_white_sharing"> Sharing the temporary whitelist
<li> <a href="#temp_white_sharing"> Sharing the temporary allowlist
</a>
</ul>
@ -803,8 +803,8 @@ tend to have broken SMTP implementations): </p>
<pre>
/etc/postfix/<a href="postconf.5.html">main.cf</a>:
# Exclude broken clients by whitelisting. Clients in <a href="postconf.5.html#mynetworks">mynetworks</a>
# should always be whitelisted.
# Exclude broken clients by allowlisting. Clients in <a href="postconf.5.html#mynetworks">mynetworks</a>
# should always be allowlisted.
<a href="postconf.5.html#postscreen_access_list">postscreen_access_list</a> = <a href="postconf.5.html#permit_mynetworks">permit_mynetworks</a>,
<a href="cidr_table.5.html">cidr</a>:/etc/postfix/postscreen_access.cidr
@ -921,8 +921,8 @@ work reliably on all systems. </p>
<h3> <a name="starttls"> postscreen(8) TLS configuration </a> </h3>
<p> <a href="postscreen.8.html">postscreen(8)</a> 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, <a href="postscreen.8.html">postscreen(8)</a> invisibly hands off the connection to a
<a href="tlsproxy.8.html">tlsproxy(8)</a> process. Then, <a href="tlsproxy.8.html">tlsproxy(8)</a> encrypts and decrypts the
traffic between <a href="postscreen.8.html">postscreen(8)</a> and the remote SMTP client. One
@ -976,7 +976,7 @@ Postfix SMTP servers dramatically. </p>
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. </p>
zombies that haven't yet been denylisted. </p>
<li> <p> You can also enable "<a href="#after_220">deep protocol
tests</a>", but these are more intrusive than the pregreet or DNSBL
@ -984,7 +984,7 @@ tests. </p>
<p> When a good client passes the "<a href="#after_220">deep
protocol tests</a>", 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, <a href="postscreen.8.html">postscreen(8)</a>
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</a>" is that some "good" clients don't return after the 4XX
reply; these clients were not so good after all. </p>
<p> 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 "<a href="#after_220">deep protocol tests</a>"
on his own internet-facing mail server. </p>
<li> <p> There is also support for permanent blacklisting and
whitelisting; see the description of the <a href="postconf.5.html#postscreen_access_list">postscreen_access_list</a>
<li> <p> There is also support for permanent denylisting and
allowlisting; see the description of the <a href="postconf.5.html#postscreen_access_list">postscreen_access_list</a>
parameter for details. </p>
</ul>
@ -1070,15 +1070,15 @@ may follow. </p>
</ol>
<h3> <a name="temp_white_sharing"> Sharing the temporary whitelist </a> </h3>
<h3> <a name="temp_white_sharing"> Sharing the temporary allowlist </a> </h3>
<p> By default, the temporary whitelist is not shared between
<p> By default, the temporary allowlist is not shared between
multiple <a href="postscreen.8.html">postscreen(8)</a> daemons. To enable sharing, choose one
of the following options: </p>
<ul>
<li> <p> A non-persistent <a href="memcache_table.5.html">memcache</a>: temporary whitelist can be shared
<li> <p> A non-persistent <a href="memcache_table.5.html">memcache</a>: temporary allowlist can be shared
between <a href="postscreen.8.html">postscreen(8)</a> daemons on the same host or different
hosts. Disable cache cleanup (<a href="postconf.5.html#postscreen_cache_cleanup_interval">postscreen_cache_cleanup_interval</a>
= 0) in all <a href="postscreen.8.html">postscreen(8)</a> daemons because <a href="memcache_table.5.html">memcache</a>: has no
@ -1086,7 +1086,7 @@ of the following options: </p>
persistent backup). This requires Postfix 2.9 or later. </p>
<pre>
# Example 1: non-persistent <a href="memcache_table.5.html">memcache</a>: whitelist.
# Example 1: non-persistent <a href="memcache_table.5.html">memcache</a>: allowlist.
/etc/postfix/<a href="postconf.5.html">main.cf</a>:
<a href="postconf.5.html#postscreen_cache_map">postscreen_cache_map</a> = <a href="memcache_table.5.html">memcache</a>:/etc/postfix/postscreen_cache
<a href="postconf.5.html#postscreen_cache_cleanup_interval">postscreen_cache_cleanup_interval</a> = 0
@ -1097,7 +1097,7 @@ of the following options: </p>
</pre>
<li> <p>
A persistent <a href="lmdb_table.5.html">lmdb</a>: temporary whitelist can be shared between
A persistent <a href="lmdb_table.5.html">lmdb</a>: temporary allowlist can be shared between
<a href="postscreen.8.html">postscreen(8)</a> daemons that run under the same <a href="master.8.html">master(8)</a> daemon,
or under different <a href="master.8.html">master(8)</a> daemons on the same host. Disable
cache cleanup (<a href="postconf.5.html#postscreen_cache_cleanup_interval">postscreen_cache_cleanup_interval</a> = 0) in all
@ -1105,28 +1105,28 @@ of the following options: </p>
cleanup. This requires Postfix 2.11 or later. </p>
<pre>
# Example 2: persistent <a href="lmdb_table.5.html">lmdb</a>: whitelist.
# Example 2: persistent <a href="lmdb_table.5.html">lmdb</a>: allowlist.
/etc/postfix/<a href="postconf.5.html">main.cf</a>:
<a href="postconf.5.html#postscreen_cache_map">postscreen_cache_map</a> = <a href="lmdb_table.5.html">lmdb</a>:$<a href="postconf.5.html#data_directory">data_directory</a>/postscreen_cache
# See note 1 below.
# <a href="postconf.5.html#postscreen_cache_cleanup_interval">postscreen_cache_cleanup_interval</a> = 0
</pre>
<li> <p> Other kinds of persistent temporary whitelist can be shared
<li> <p> Other kinds of persistent temporary allowlist can be shared
only between <a href="postscreen.8.html">postscreen(8)</a> daemons that run under the same
<a href="master.8.html">master(8)</a> daemon. In this case, temporary whitelist access must
<a href="master.8.html">master(8)</a> daemon. In this case, temporary allowlist access must
be shared through the <a href="proxymap.8.html">proxymap(8)</a> daemon. This requires Postfix
2.9 or later. </p>
<pre>
# Example 3: proxied <a href="DATABASE_README.html#types">btree</a>: whitelist.
# Example 3: proxied <a href="DATABASE_README.html#types">btree</a>: allowlist.
/etc/postfix/<a href="postconf.5.html">main.cf</a>:
<a href="postconf.5.html#postscreen_cache_map">postscreen_cache_map</a> =
<a href="proxymap.8.html">proxy</a>:<a href="DATABASE_README.html#types">btree</a>:/var/lib/postfix/postscreen_cache
# See note 1 below.
# <a href="postconf.5.html#postscreen_cache_cleanup_interval">postscreen_cache_cleanup_interval</a> = 0
# Example 4: proxied <a href="DATABASE_README.html#types">btree</a>: whitelist with <a href="memcache_table.5.html">memcache</a>: accelerator.
# Example 4: proxied <a href="DATABASE_README.html#types">btree</a>: allowlist with <a href="memcache_table.5.html">memcache</a>: accelerator.
/etc/postfix/<a href="postconf.5.html">main.cf</a>:
<a href="postconf.5.html#postscreen_cache_map">postscreen_cache_map</a> = <a href="memcache_table.5.html">memcache</a>:/etc/postfix/postscreen_cache
<a href="postconf.5.html#proxy_write_maps">proxy_write_maps</a> =
@ -1189,4 +1189,3 @@ POP, IMAP, NNTP, and FTP over TLS. </p>
</body>
</html>

View File

@ -55,7 +55,7 @@ policies </a> </h2>
Mail servers happily forwarded mail on behalf of anyone towards
any destination. On today's Internet, spammers abuse servers that
forward mail from arbitrary systems, and abused systems end up on
anti-spammer blacklists. See, for example, the information on
anti-spammer denylists. See, for example, the information on
<a href="http://www.mail-abuse.org/">http://www.mail-abuse.org/</a> and other websites. </p>
<p> By default, Postfix has a moderately restrictive approach to
@ -87,11 +87,11 @@ SMTP client implementations. Protocol-oriented access controls
become less useful over time as spammers and worm writers learn to
read RFC documents. </p>
<li> <p> Blacklist oriented: some SMTP server access controls
query blacklists with known to be bad sites such as open mail
<li> <p> Denylist oriented: some SMTP server access controls
query denylists with known to be bad sites such as open mail
relays, open web proxies, and home computers that have been
compromised and that are under remote control by criminals. The
effectiveness of these blacklists depends on how complete and how
effectiveness of these denylists depends on how complete and how
up to date they are. </p>
<li> <p> Threshold oriented: some SMTP server access controls attempt
@ -218,7 +218,7 @@ some restriction produces a result of PERMIT, REJECT or DEFER (try
again later). The end of each list is equivalent to a PERMIT result.
By placing a PERMIT restriction before a REJECT restriction you
can make exceptions for specific clients or users. This is called
whitelisting; the fourth example above allows mail from local
allowlisting; the fourth example above allows mail from local
networks but otherwise rejects mail to arbitrary destinations. </p>
<p> The table below summarizes the purpose of each SMTP access
@ -320,7 +320,7 @@ until the RCPT TO command, it can log the sender and the recipient
address. This is more useful than logging only the client hostname
and IP address and not knowing whose mail was being blocked. </p>
<li> <p> Mixing is needed for complex whitelisting policies. For
<li> <p> Mixing is needed for complex allowlisting policies. For
example, in order to reject local sender addresses in mail from
non-local clients, you need to be able to mix restrictions on client
information with restrictions on sender information in the same

View File

@ -672,7 +672,7 @@ exceptions for mailing lists that use one-time sender addresses,
because each message will be delayed due to greylisting, and the
one-time sender addresses can pollute your greylist database
relatively quickly. Instead of making exceptions, you can automatically
whitelist clients that survive greylisting repeatedly; this avoids
allowlist clients that survive greylisting repeatedly; this avoids
most of the delays and most of the database pollution problem. </p>
<blockquote>
@ -746,11 +746,11 @@ $database_name="/var/mta/greylist.db";
$greylist_delay=60;
#
# Auto-whitelist threshold. Specify 0 to disable, or the number of
# Auto-allowlist threshold. Specify 0 to disable, or the number of
# successful "come backs" after which a client is no longer subject
# to greylisting.
#
$auto_whitelist_threshold = 10;
$auto_allowlist_threshold = 10;
#
# Demo SMTPD access policy routine. The result is an action just like
@ -763,10 +763,10 @@ sub smtpd_access_policy {
# Open the database on the fly.
open_database() unless $database_obj;
# Search the auto-whitelist.
if ($auto_whitelist_threshold &gt; 0) {
# Search the auto-allowlist.
if ($auto_allowlist_threshold &gt; 0) {
$count = read_database($attr{"client_address"});
if ($count &gt; $auto_whitelist_threshold) {
if ($count &gt; $auto_allowlist_threshold) {
return "dunno";
}
}
@ -795,8 +795,8 @@ sub smtpd_access_policy {
#
syslog $syslog_priority, "request age %d", $now - $time_stamp if $verbose;
if ($now - $time_stamp &gt; $greylist_delay) {
# Update the auto-whitelist.
if ($auto_whitelist_threshold &gt; 0) {
# Update the auto-allowlist.
if ($auto_allowlist_threshold &gt; 0) {
update_database($attr{"client_address"}, $count + 1);
}
return "dunno";

View File

@ -354,7 +354,7 @@ such as SMTP access maps. The Postfix SMTP server will reject mail
and disconnect without waiting for the remote SMTP client to send
a QUIT command. </p>
<li> <p> To hang up connections from blacklisted zombies, you can
<li> <p> To hang up connections from denylisted zombies, you can
set specific Postfix SMTP server reject codes for specific RBLs,
and for individual responses from specific RBLs. We'll use
zen.spamhaus.org as an example; by the time you read this document,

View File

@ -103,8 +103,8 @@ CIDR_TABLE(5) CIDR_TABLE(5)
<a href="postconf.5.html#smtpd_client_restrictions">smtpd_client_restrictions</a> = ... <a href="cidr_table.5.html">cidr</a>:/etc/postfix/client.cidr ...
/etc/postfix/client.<a href="cidr_table.5.html">cidr</a>:
# Rule order matters. Put more specific whitelist entries
# before more general blacklist entries.
# Rule order matters. Put more specific allowlist entries
# before more general denylist entries.
192.168.1.1 OK
192.168.0.0/16 REJECT
2001:db8::1 OK

View File

@ -7,26 +7,26 @@
DNSBLOG(8) DNSBLOG(8)
<b>NAME</b>
dnsblog - Postfix DNS white/blacklist logger
dnsblog - Postfix DNS allow/denylist logger
<b>SYNOPSIS</b>
<b>dnsblog</b> [generic Postfix daemon options]
<b>DESCRIPTION</b>
The <a href="dnsblog.8.html"><b>dnsblog</b>(8)</a> server implements an ad-hoc DNS white/blacklist lookup
The <a href="dnsblog.8.html"><b>dnsblog</b>(8)</a> server implements an ad-hoc DNS allow/denylist lookup
service. This may eventually be replaced by an UDP client that is built
directly into the <a href="postscreen.8.html"><b>postscreen</b>(8)</a> server.
<b>PROTOCOL</b>
With each connection, the <a href="dnsblog.8.html"><b>dnsblog</b>(8)</a> server receives a DNS white/black-
list domain name, an IP address, and an ID. If the IP address is
listed under the DNS white/blacklist, the <a href="dnsblog.8.html"><b>dnsblog</b>(8)</a> server logs the
match and replies with the query arguments plus an address list with
the resulting IP addresses, separated by whitespace, and the reply TTL.
Otherwise it replies with the query arguments plus an empty address
list and the reply TTL; the reply TTL is -1 if there is no reply, or a
negative reply that contains no SOA record. Finally, the <a href="dnsblog.8.html"><b>dnsblog</b>(8)</a>
server closes the connection.
With each connection, the <a href="dnsblog.8.html"><b>dnsblog</b>(8)</a> server receives a DNS
allow/denylist domain name, an IP address, and an ID. If the IP
address is listed under the DNS allow/denylist, the <a href="dnsblog.8.html"><b>dnsblog</b>(8)</a> server
logs the match and replies with the query arguments plus an address
list with the resulting IP addresses, separated by whitespace, and the
reply TTL. Otherwise it replies with the query arguments plus an empty
address list and the reply TTL; the reply TTL is -1 if there is no
reply, or a negative reply that contains no SOA record. Finally, the
<a href="dnsblog.8.html"><b>dnsblog</b>(8)</a> server closes the connection.
<b>DIAGNOSTICS</b>
Problems and transactions are logged to <b>syslogd</b>(8) or <a href="postlogd.8.html"><b>postlogd</b>(8)</a>.
@ -48,7 +48,7 @@ DNSBLOG(8) DNSBLOG(8)
request before it is terminated by a built-in watchdog timer.
<b><a href="postconf.5.html#postscreen_dnsbl_sites">postscreen_dnsbl_sites</a> (empty)</b>
Optional list of DNS white/blacklist domains, filters and weight
Optional list of DNS allow/denylist domains, filters and weight
factors.
<b><a href="postconf.5.html#ipc_timeout">ipc_timeout</a> (3600s)</b>

View File

@ -2510,7 +2510,7 @@ See <a href="postconf.5.html#reject_unknown_reverse_client_hostname">reject_unkn
<dt><b>$rbl_class</b></dt>
<dd>The blacklisted entity type: Client host, Helo command, Sender
<dd>The denylisted entity type: Client host, Helo command, Sender
address, or Recipient address. </dd>
<dt><b>$rbl_code</b></dt>
@ -2523,16 +2523,16 @@ by an <a href="http://tools.ietf.org/html/rfc3463">RFC 3463</a> enhanced status
<dt><b>$rbl_domain</b></dt>
<dd>The RBL domain where $rbl_what is blacklisted. </dd>
<dd>The RBL domain where $rbl_what is denylisted. </dd>
<dt><b>$rbl_reason</b></dt>
<dd>The reason why $rbl_what is blacklisted, or an empty string. </dd>
<dd>The reason why $rbl_what is denylisted, or an empty string. </dd>
<dt><b>$rbl_what</b></dt>
<dd>The entity that is blacklisted (an IP address, a hostname, a domain
name, or an email address whose domain was blacklisted). </dd>
<dd>The entity that is denylisted (an IP address, a hostname, a domain
name, or an email address whose domain was denylisted). </dd>
<dt><b>$recipient</b></dt>
@ -3041,7 +3041,7 @@ This feature is available in Postfix 3.1 and later.
(default: dnsblog)</b></DT><DD>
<p> The name of the <a href="dnsblog.8.html">dnsblog(8)</a> service entry in <a href="master.5.html">master.cf</a>. This
service performs DNS white/blacklist lookups. </p>
service performs DNS allow/denylist lookups. </p>
<p> This feature is available in Postfix 2.8 and later. </p>
@ -7056,7 +7056,7 @@ by default. </p>
</pre>
<p> The <a href="postconf.5.html#milter_header_checks">milter_header_checks</a> mechanism could also be used for
whitelisting. For example it could be used to skip heavy content
allowlisting. For example it could be used to skip heavy content
inspection for DKIM-signed mail from known friendly domains. </p>
<p> This feature is available in Postfix 2.7, and as an optional
@ -7977,7 +7977,7 @@ and enabled instances are processed in reverse order. </p>
<DT><b><a name="postscreen_access_list">postscreen_access_list</a>
(default: <a href="postconf.5.html#permit_mynetworks">permit_mynetworks</a>)</b></DT><DD>
<p> Permanent white/blacklist for remote SMTP client IP addresses.
<p> Permanent allow/denylist for remote SMTP client IP addresses.
<a href="postscreen.8.html">postscreen(8)</a> searches this list immediately after a remote SMTP
client connects. Specify a comma- or whitespace-separated list of
commands (in upper or lower case) or lookup tables. The search stops
@ -7985,7 +7985,7 @@ upon the first command that fires for the client IP address. </p>
<dl>
<dt> <b> <a href="postconf.5.html#permit_mynetworks">permit_mynetworks</a> </b> </dt> <dd> Whitelist the client and
<dt> <b> <a href="postconf.5.html#permit_mynetworks">permit_mynetworks</a> </b> </dt> <dd> Allowlist the client and
terminate the search if the client IP address matches $<a href="postconf.5.html#mynetworks">mynetworks</a>.
Do not subject the client to any before/after 220 greeting tests.
Pass the connection immediately to a Postfix SMTP server process.
@ -8000,12 +8000,12 @@ To discourage the use of hash, btree, etc. tables, there is no
support for substring matching like <a href="smtpd.8.html">smtpd(8)</a>. Use CIDR tables
instead. </dd>
<dt> <b> permit </b> </dt> <dd> Whitelist the client and terminate
<dt> <b> permit </b> </dt> <dd> Allowlist the client and terminate
the search. Do not subject the client to any before/after 220
greeting tests. Pass the connection immediately to a Postfix SMTP
server process. </dd>
<dt> <b> reject </b> </dt> <dd> Blacklist the client and terminate
<dt> <b> reject </b> </dt> <dd> Denylist the client and terminate
the search. Subject the client to the action configured with the
<a href="postconf.5.html#postscreen_blacklist_action">postscreen_blacklist_action</a> configuration parameter. </dd>
@ -8030,7 +8030,7 @@ to the configured before/after 220 greeting tests. </dd>
<pre>
/etc/postfix/postscreen_access.<a href="cidr_table.5.html">cidr</a>:
# 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 dunno
192.168.0.0/16 reject
</pre>
@ -8112,7 +8112,7 @@ one-letter suffix that specifies the time unit). Time units: s
(default: ignore)</b></DT><DD>
<p> The action that <a href="postscreen.8.html">postscreen(8)</a> takes when a remote SMTP client is
permanently blacklisted with the <a href="postconf.5.html#postscreen_access_list">postscreen_access_list</a> parameter.
permanently denylisted with the <a href="postconf.5.html#postscreen_access_list">postscreen_access_list</a> parameter.
Specify one of the following: </p>
<dl>
@ -8185,7 +8185,7 @@ approach see the <a href="memcache_table.5.html">memcache_table(5)</a> manpage.
(default: 7d)</b></DT><DD>
<p> The amount of time that <a href="postscreen.8.html">postscreen(8)</a> will cache an expired
temporary whitelist entry before it is removed. This prevents clients
temporary allowlist entry before it is removed. This prevents clients
from being logged as "NEW" just because their cache entry expired
an hour ago. It also prevents the cache from filling up with clients
that passed some deep protocol test once and never came back. </p>
@ -8394,7 +8394,7 @@ the file is read). </p>
<DT><b><a name="postscreen_dnsbl_sites">postscreen_dnsbl_sites</a>
(default: empty)</b></DT><DD>
<p>Optional list of DNS white/blacklist domains, filters and weight
<p>Optional list of DNS allow/denylist domains, filters and weight
factors. When the list is non-empty, the <a href="dnsblog.8.html">dnsblog(8)</a> daemon will
query these domains with the IP addresses of remote SMTP clients,
and <a href="postscreen.8.html">postscreen(8)</a> will update an SMTP client's DNSBL score with
@ -8423,7 +8423,7 @@ or more ";"-separated numbers or number..number ranges. </p>
the remote SMTP client's DNSBL score by 1. Otherwise, the weight must be
an integral number, and <a href="postscreen.8.html">postscreen(8)</a> adds the specified weight to
the remote SMTP client's DNSBL score. Specify a negative number for
whitelisting. </p>
allowlisting. </p>
<li> <p> When one <a href="postconf.5.html#postscreen_dnsbl_sites">postscreen_dnsbl_sites</a> entry produces multiple
DNSBL responses, <a href="postscreen.8.html">postscreen(8)</a> applies the weight at most once.
@ -8580,7 +8580,7 @@ this test the next time the client connects. </dd>
</dl>
<p> In either case, <a href="postscreen.8.html">postscreen(8)</a> will not whitelist the remote SMTP client
<p> In either case, <a href="postscreen.8.html">postscreen(8)</a> will not allowlist the remote SMTP client
IP address. </p>
<p> This feature is available in Postfix 2.8. </p>
@ -8800,10 +8800,10 @@ receive a 421 response. </p>
<DT><b><a name="postscreen_pre_queue_limit">postscreen_pre_queue_limit</a>
(default: $<a href="postconf.5.html#default_process_limit">default_process_limit</a>)</b></DT><DD>
<p> The number of non-whitelisted clients that can be waiting for
<p> The number of non-allowlisted clients that can be waiting for
a decision whether they will receive service from a real Postfix
SMTP server
process. When this queue is full, all non-whitelisted clients will
process. When this queue is full, all non-allowlisted clients will
receive a 421 response. </p>
<p> This feature is available in Postfix 2.8. </p>
@ -8909,18 +8909,18 @@ one-letter suffix that specifies the time unit). Time units: s
(default: <a href="DATABASE_README.html#types">static</a>:all)</b></DT><DD>
<p> A list of local <a href="postscreen.8.html">postscreen(8)</a> server IP addresses where a
non-whitelisted remote SMTP client can obtain <a href="postscreen.8.html">postscreen(8)</a>'s temporary
whitelist status. This status is required before the client can
non-allowlisted remote SMTP client can obtain <a href="postscreen.8.html">postscreen(8)</a>'s temporary
allowlist status. This status is required before the client can
talk to a Postfix SMTP server process. By default, a client can
obtain <a href="postscreen.8.html">postscreen(8)</a>'s whitelist status on any local <a href="postscreen.8.html">postscreen(8)</a>
obtain <a href="postscreen.8.html">postscreen(8)</a>'s allowlist status on any local <a href="postscreen.8.html">postscreen(8)</a>
server IP address. </p>
<p> When <a href="postscreen.8.html">postscreen(8)</a> listens on both primary and backup MX
addresses, the <a href="postconf.5.html#postscreen_whitelist_interfaces">postscreen_whitelist_interfaces</a> parameter can be
configured to give the temporary whitelist status only when a client
connects to a primary MX address. Once a client is whitelisted it
configured to give the temporary allowlist status only when a client
connects to a primary MX address. Once a client is allowlisted it
can talk to a Postfix SMTP server on any address. Thus, clients
that connect only to backup MX addresses will never become whitelisted,
that connect only to backup MX addresses will never become allowlisted,
and will never be allowed to talk to a Postfix SMTP server process.
</p>
@ -8948,7 +8948,7 @@ pattern. </p>
<pre>
/etc/postfix/<a href="postconf.5.html">main.cf</a>:
# Don't whitelist connections to the backup IP address.
# Don't allowlist connections to the backup IP address.
<a href="postconf.5.html#postscreen_whitelist_interfaces">postscreen_whitelist_interfaces</a> = !168.100.189.8, <a href="DATABASE_README.html#types">static</a>:all
</pre>
@ -14497,7 +14497,7 @@ least significant octets. See the <a href="access.5.html">access(5)</a> manual p
<dd>Search the specified <a href="access.5.html">access(5)</a> database for the IP addresses for the
client hostname, and execute the corresponding action. Note: a result
of "OK" is not allowed for safety reasons. Instead, use DUNNO in order
to exclude specific hosts from blacklists. This feature is available
to exclude specific hosts from denylists. This feature is available
in Postfix 3.0 and later. </dd>
<dt><b><a name="check_client_mx_access">check_client_mx_access</a> <i><a href="DATABASE_README.html">type:table</a></i></b></dt>
@ -14507,7 +14507,7 @@ client hostname, and execute the corresponding action. If no MX
record is found, look up A or AAAA records, just like the Postfix
SMTP client would. Note: a result
of "OK" is not allowed for safety reasons. Instead, use DUNNO in order
to exclude specific hosts from blacklists. This feature is available
to exclude specific hosts from denylists. This feature is available
in Postfix 2.7 and later. </dd>
<dt><b><a name="check_client_ns_access">check_client_ns_access</a> <i><a href="DATABASE_README.html">type:table</a></i></b></dt>
@ -14515,7 +14515,7 @@ in Postfix 2.7 and later. </dd>
<dd>Search the specified <a href="access.5.html">access(5)</a> database for the DNS servers for
the client hostname, and execute the corresponding action. Note: a
result of "OK" is not allowed for safety reasons. Instead, use DUNNO
in order to exclude specific hosts from blacklists. This feature is
in order to exclude specific hosts from denylists. This feature is
available in Postfix 2.7 and later. </dd>
<dt><b><a name="check_reverse_client_hostname_access">check_reverse_client_hostname_access</a> <i><a href="DATABASE_README.html">type:table</a></i></b></dt>
@ -14525,7 +14525,7 @@ client hostname, parent domains, client IP address, or networks
obtained by stripping least significant octets. See the <a href="access.5.html">access(5)</a>
manual page for details. Note: a result of "OK" is not allowed for
safety reasons. Instead, use DUNNO in order to exclude specific
hosts from blacklists. This feature is available in Postfix 2.6
hosts from denylists. This feature is available in Postfix 2.6
and later.</dd>
<dt><b><a name="check_reverse_client_hostname_a_access">check_reverse_client_hostname_a_access</a> <i><a href="DATABASE_README.html">type:table</a></i></b></dt>
@ -14533,7 +14533,7 @@ and later.</dd>
<dd>Search the specified <a href="access.5.html">access(5)</a> database for the IP addresses for the
unverified reverse client hostname, and execute the corresponding
action. Note: a result of "OK" is not allowed for safety reasons.
Instead, use DUNNO in order to exclude specific hosts from blacklists.
Instead, use DUNNO in order to exclude specific hosts from denylists.
This feature is available in Postfix 3.0 and later. </dd>
<dt><b><a name="check_reverse_client_hostname_mx_access">check_reverse_client_hostname_mx_access</a> <i><a href="DATABASE_README.html">type:table</a></i></b></dt>
@ -14543,7 +14543,7 @@ unverified reverse client hostname, and execute the corresponding
action. If no MX record is found, look up A or AAAA records, just
like the Postfix SMTP client would.
Note: a result of "OK" is not allowed for safety reasons.
Instead, use DUNNO in order to exclude specific hosts from blacklists.
Instead, use DUNNO in order to exclude specific hosts from denylists.
This feature is available in Postfix 2.7 and later. </dd>
<dt><b><a name="check_reverse_client_hostname_ns_access">check_reverse_client_hostname_ns_access</a> <i><a href="DATABASE_README.html">type:table</a></i></b></dt>
@ -14551,7 +14551,7 @@ This feature is available in Postfix 2.7 and later. </dd>
<dd>Search the specified <a href="access.5.html">access(5)</a> database for the DNS servers for
the unverified reverse client hostname, and execute the corresponding
action. Note: a result of "OK" is not allowed for safety reasons.
Instead, use DUNNO in order to exclude specific hosts from blacklists.
Instead, use DUNNO in order to exclude specific hosts from denylists.
This feature is available in Postfix 2.7 and later. </dd>
<dt><b><a name="check_sasl_access">check_sasl_access</a> <i><a href="DATABASE_README.html">type:table</a></i></b></dt>
@ -14636,7 +14636,7 @@ If no "<i>=d.d.d.d</i>" is specified, accept the request when the
reversed client network address is listed with any A record under
<i>dnswl_domain</i>. <br> For safety, <a href="postconf.5.html#permit_dnswl_client">permit_dnswl_client</a> is silently
ignored when it would override <a href="postconf.5.html#reject_unauth_destination">reject_unauth_destination</a>. The
result is DEFER_IF_REJECT when whitelist lookup fails. This feature
result is DEFER_IF_REJECT when allowlist lookup fails. This feature
is available in Postfix 2.8 and later. </dd>
<dt><b><a name="reject_rhsbl_client">reject_rhsbl_client <i>rbl_domain=d.d.d.d</i></a></b></dt>
@ -14662,13 +14662,13 @@ is a number, or a pattern inside "[]" that contains one or more
";"-separated numbers or number..number ranges. If no
"<i>=d.d.d.d</i>" is specified, accept the request when the client
hostname is listed with any A record under <i>rhswl_domain</i>.
<br> Caution: client name whitelisting is fragile, since the client
<br> Caution: client name allowlisting is fragile, since the client
name lookup can fail due to temporary outages. Client name
whitelisting should be used only to reduce false positives in e.g.
allowlisting should be used only to reduce false positives in e.g.
DNS-based blocklists, and not for making access rule exceptions.
<br> For safety, <a href="postconf.5.html#permit_rhswl_client">permit_rhswl_client</a> is silently ignored when it
would override <a href="postconf.5.html#reject_unauth_destination">reject_unauth_destination</a>. The result is DEFER_IF_REJECT
when whitelist lookup fails. This feature is available in Postfix
when allowlist lookup fails. This feature is available in Postfix
2.8 and later. </dd>
<dt><b><a name="reject_rhsbl_reverse_client">reject_rhsbl_reverse_client <i>rbl_domain=d.d.d.d</i></a></b></dt>
@ -14734,7 +14734,7 @@ the SMTP server reply code (default: 450).</dd>
<dt><b><a name="defer_if_permit">defer_if_permit</a></b></dt>
<dd>Defer the request if some later restriction would result in an
explicit or implicit PERMIT action. This is useful when a blacklisting
explicit or implicit PERMIT action. This is useful when a denylisting
feature fails due to a temporary problem. This feature is available
in Postfix version 2.1 and later. </dd>
@ -15324,7 +15324,7 @@ simply skip <a href="postconf.5.html#check_helo_access">check_helo_access</a> by
<dd>Search the specified <a href="access.5.html">access(5)</a> database for the IP addresses for
the HELO or EHLO hostname, and execute the corresponding action.
Note 1: a result of "OK" is not allowed for safety reasons. Instead,
use DUNNO in order to exclude specific hosts from blacklists. Note
use DUNNO in order to exclude specific hosts from denylists. Note
2: specify "<a href="postconf.5.html#smtpd_helo_required">smtpd_helo_required</a> = yes" to fully enforce this
restriction (without "<a href="postconf.5.html#smtpd_helo_required">smtpd_helo_required</a> = yes", a client can
simply skip check_helo_a_access by not sending HELO or EHLO). This
@ -15338,7 +15338,7 @@ the HELO or EHLO hostname, and execute the corresponding action.
If no MX record is found, look up A or AAAA records, just like the
Postfix SMTP client would.
Note 1: a result of "OK" is not allowed for safety reasons. Instead,
use DUNNO in order to exclude specific hosts from blacklists. Note
use DUNNO in order to exclude specific hosts from denylists. Note
2: specify "<a href="postconf.5.html#smtpd_helo_required">smtpd_helo_required</a> = yes" to fully enforce this
restriction (without "<a href="postconf.5.html#smtpd_helo_required">smtpd_helo_required</a> = yes", a client can
simply skip <a href="postconf.5.html#check_helo_mx_access">check_helo_mx_access</a> by not sending HELO or EHLO). This
@ -15350,7 +15350,7 @@ feature is available in Postfix 2.1 and later.
<dd>Search the specified <a href="access.5.html">access(5)</a> database for the DNS servers
for the HELO or EHLO hostname, and execute the corresponding action.
Note 1: a result of "OK" is not allowed for safety reasons. Instead,
use DUNNO in order to exclude specific hosts from blacklists. Note
use DUNNO in order to exclude specific hosts from denylists. Note
2: specify "<a href="postconf.5.html#smtpd_helo_required">smtpd_helo_required</a> = yes" to fully enforce this
restriction (without "<a href="postconf.5.html#smtpd_helo_required">smtpd_helo_required</a> = yes", a client can
simply skip <a href="postconf.5.html#check_helo_ns_access">check_helo_ns_access</a> by not sending HELO or EHLO). This
@ -15918,7 +15918,7 @@ corresponding action. </dd>
<dd>Search the specified <a href="access.5.html">access(5)</a> database for the IP addresses for
the RCPT TO domain, and execute the corresponding action. Note:
a result of "OK" is not allowed for safety reasons. Instead, use
DUNNO in order to exclude specific hosts from blacklists. This
DUNNO in order to exclude specific hosts from denylists. This
feature is available in Postfix 3.0 and later. </dd>
<dt><b><a name="check_recipient_mx_access">check_recipient_mx_access</a> <i><a href="DATABASE_README.html">type:table</a></i></b></dt>
@ -15928,7 +15928,7 @@ the RCPT TO domain, and execute the corresponding action. If no
MX record is found, look up A or AAAA records, just like the Postfix
SMTP client would. Note:
a result of "OK" is not allowed for safety reasons. Instead, use
DUNNO in order to exclude specific hosts from blacklists. This
DUNNO in order to exclude specific hosts from denylists. This
feature is available in Postfix 2.1 and later. </dd>
<dt><b><a name="check_recipient_ns_access">check_recipient_ns_access</a> <i><a href="DATABASE_README.html">type:table</a></i></b></dt>
@ -15936,7 +15936,7 @@ feature is available in Postfix 2.1 and later. </dd>
<dd>Search the specified <a href="access.5.html">access(5)</a> database for the DNS servers
for the RCPT TO domain, and execute the corresponding action.
Note: a result of "OK" is not allowed for safety reasons. Instead,
use DUNNO in order to exclude specific hosts from blacklists. This
use DUNNO in order to exclude specific hosts from denylists. This
feature is available in Postfix 2.1 and later. </dd>
<dt><b><a name="permit_auth_destination">permit_auth_destination</a></b></dt>
@ -16796,7 +16796,7 @@ corresponding action. </dd>
<dd>Search the specified <a href="access.5.html">access(5)</a> database for the IP addresses for
the MAIL FROM domain, and execute the corresponding action. Note:
a result of "OK" is not allowed for safety reasons. Instead, use
DUNNO in order to exclude specific hosts from blacklists. This
DUNNO in order to exclude specific hosts from denylists. This
feature is available in Postfix 3.0 and later. </dd>
<dt><b><a name="check_sender_mx_access">check_sender_mx_access</a> <i><a href="DATABASE_README.html">type:table</a></i></b></dt>
@ -16806,7 +16806,7 @@ the MAIL FROM domain, and execute the corresponding action. If no
MX record is found, look up A or AAAA records, just like the Postfix
SMTP client would. Note:
a result of "OK" is not allowed for safety reasons. Instead, use
DUNNO in order to exclude specific hosts from blacklists. This
DUNNO in order to exclude specific hosts from denylists. This
feature is available in Postfix 2.1 and later. </dd>
<dt><b><a name="check_sender_ns_access">check_sender_ns_access</a> <i><a href="DATABASE_README.html">type:table</a></i></b></dt>
@ -16814,7 +16814,7 @@ feature is available in Postfix 2.1 and later. </dd>
<dd>Search the specified <a href="access.5.html">access(5)</a> database for the DNS servers
for the MAIL FROM domain, and execute the corresponding action.
Note: a result of "OK" is not allowed for safety reasons. Instead,
use DUNNO in order to exclude specific hosts from blacklists. This
use DUNNO in order to exclude specific hosts from denylists. This
feature is available in Postfix 2.1 and later. </dd>
<dt><b><a name="reject_authenticated_sender_login_mismatch">reject_authenticated_sender_login_mismatch</a></b></dt>

View File

@ -192,7 +192,7 @@ the following convention: </p>
<li> <a href="discard.8.html">discard(8)</a>, Postfix discard delivery agent
<li> <a href="dnsblog.8.html">dnsblog(8)</a>, DNS black/whitelist logger
<li> <a href="dnsblog.8.html">dnsblog(8)</a>, DNS allow/denylist logger
<li> <a href="error.8.html">error(8)</a>, Postfix error delivery agent

View File

@ -366,7 +366,7 @@ POSTFIX(1) POSTFIX(1)
<a href="bounce.8.html">bounce(8)</a>, <a href="defer.8.html">defer(8)</a>, <a href="trace.8.html">trace(8)</a>, Delivery status reports
<a href="cleanup.8.html">cleanup(8)</a>, canonicalize and enqueue message
<a href="discard.8.html">discard(8)</a>, Postfix discard delivery agent
<a href="dnsblog.8.html">dnsblog(8)</a>, DNS black/whitelist logger
<a href="dnsblog.8.html">dnsblog(8)</a>, DNS allow/denylist logger
<a href="error.8.html">error(8)</a>, Postfix error delivery agent
<a href="flush.8.html">flush(8)</a>, Postfix fast ETRN service
<a href="local.8.html">local(8)</a>, Postfix local delivery agent

View File

@ -28,9 +28,9 @@ POSTSCREEN(8) POSTSCREEN(8)
"port 25" server that provides <b>submission</b> service and client authenti-
cation, but no MX service.
<a href="postscreen.8.html"><b>postscreen</b>(8)</a> maintains a temporary whitelist for clients that have
<a href="postscreen.8.html"><b>postscreen</b>(8)</a> maintains a temporary allowlist for clients that have
passed a number of tests. When an SMTP client IP address is
whitelisted, <a href="postscreen.8.html"><b>postscreen</b>(8)</a> hands off the connection immediately to a
allowlisted, <a href="postscreen.8.html"><b>postscreen</b>(8)</a> hands off the connection immediately to a
Postfix SMTP server process. This minimizes the overhead for legitimate
mail.
@ -152,22 +152,22 @@ POSTSCREEN(8) POSTSCREEN(8)
The time limit for the proxy protocol specified with the
<a href="postconf.5.html#postscreen_upstream_proxy_protocol">postscreen_upstream_proxy_protocol</a> parameter.
<b>PERMANENT WHITE/BLACKLIST TEST</b>
<b>PERMANENT ALLOW/DENYLIST TEST</b>
This test is executed immediately after a remote SMTP client connects.
If a client is permanently whitelisted, the client will be handed off
If a client is permanently allowlisted, the client will be handed off
immediately to a Postfix SMTP server process.
<b><a href="postconf.5.html#postscreen_access_list">postscreen_access_list</a> (<a href="postconf.5.html#permit_mynetworks">permit_mynetworks</a>)</b>
Permanent white/blacklist for remote SMTP client IP addresses.
Permanent allow/denylist for remote SMTP client IP addresses.
<b><a href="postconf.5.html#postscreen_blacklist_action">postscreen_blacklist_action</a> (ignore)</b>
The action that <a href="postscreen.8.html"><b>postscreen</b>(8)</a> takes when a remote SMTP client is
permanently blacklisted with the <a href="postconf.5.html#postscreen_access_list">postscreen_access_list</a> parame-
permanently denylisted with the <a href="postconf.5.html#postscreen_access_list">postscreen_access_list</a> parame-
ter.
<b>MAIL EXCHANGER POLICY TESTS</b>
When <a href="postscreen.8.html"><b>postscreen</b>(8)</a> is configured to monitor all primary and backup MX
addresses, it can refuse to whitelist clients that connect to a backup
addresses, it can refuse to allowlist clients that connect to a backup
MX address only. For small sites, this requires configuring primary and
backup MX addresses on the same MTA. Larger sites would have to share
the <a href="postscreen.8.html"><b>postscreen</b>(8)</a> cache between primary and backup MTAs, which would
@ -175,8 +175,8 @@ POSTSCREEN(8) POSTSCREEN(8)
<b><a href="postconf.5.html#postscreen_whitelist_interfaces">postscreen_whitelist_interfaces</a> (<a href="DATABASE_README.html#types">static</a>:all)</b>
A list of local <a href="postscreen.8.html"><b>postscreen</b>(8)</a> server IP addresses where a
non-whitelisted remote SMTP client can obtain <a href="postscreen.8.html"><b>postscreen</b>(8)</a>'s
temporary whitelist status.
non-allowlisted remote SMTP client can obtain <a href="postscreen.8.html"><b>postscreen</b>(8)</a>'s
temporary allowlist status.
<b>BEFORE 220 GREETING TESTS</b>
These tests are executed before the remote SMTP client receives the
@ -199,7 +199,7 @@ POSTSCREEN(8) POSTSCREEN(8)
with when it rejects mail.
<b><a href="postconf.5.html#postscreen_dnsbl_sites">postscreen_dnsbl_sites</a> (empty)</b>
Optional list of DNS white/blacklist domains, filters and weight
Optional list of DNS allow/denylist domains, filters and weight
factors.
<b><a href="postconf.5.html#postscreen_dnsbl_threshold">postscreen_dnsbl_threshold</a> (1)</b>
@ -293,7 +293,7 @@ POSTSCREEN(8) POSTSCREEN(8)
<b><a href="postconf.5.html#postscreen_cache_retention_time">postscreen_cache_retention_time</a> (7d)</b>
The amount of time that <a href="postscreen.8.html"><b>postscreen</b>(8)</a> will cache an expired tem-
porary whitelist entry before it is removed.
porary allowlist entry before it is removed.
<b><a href="postconf.5.html#postscreen_bare_newline_ttl">postscreen_bare_newline_ttl</a> (30d)</b>
The amount of time that <a href="postscreen.8.html"><b>postscreen</b>(8)</a> will use the result from a
@ -345,7 +345,7 @@ POSTSCREEN(8) POSTSCREEN(8)
real Postfix SMTP server process.
<b><a href="postconf.5.html#postscreen_pre_queue_limit">postscreen_pre_queue_limit</a> ($<a href="postconf.5.html#default_process_limit">default_process_limit</a>)</b>
The number of non-whitelisted clients that can be waiting for a
The number of non-allowlisted clients that can be waiting for a
decision whether they will receive service from a real Postfix
SMTP server process.
@ -418,7 +418,7 @@ POSTSCREEN(8) POSTSCREEN(8)
<b>SEE ALSO</b>
<a href="smtpd.8.html">smtpd(8)</a>, Postfix SMTP server
<a href="tlsproxy.8.html">tlsproxy(8)</a>, Postfix TLS proxy server
<a href="dnsblog.8.html">dnsblog(8)</a>, DNS black/whitelist logger
<a href="dnsblog.8.html">dnsblog(8)</a>, DNS allow/denylist logger
<a href="postlogd.8.html">postlogd(8)</a>, Postfix logging
syslogd(8), system logging

View File

@ -15,7 +15,7 @@ TLSPROXY(8) TLSPROXY(8)
<b>DESCRIPTION</b>
The <a href="tlsproxy.8.html"><b>tlsproxy</b>(8)</a> server implements a two-way TLS proxy. It is used by
the <a href="postscreen.8.html"><b>postscreen</b>(8)</a> server to talk SMTP-over-TLS with remote SMTP clients
that are not whitelisted (including clients whose whitelist status has
that are not allowlisted (including clients whose allowlist status has
expired), and by the <a href="smtp.8.html"><b>smtp</b>(8)</a> client to support TLS connection reuse,
but it should also work for non-SMTP protocols.

View File

@ -65,7 +65,7 @@ VERIFY(8) VERIFY(8)
queue. Recipient 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.
to be denylisted by some providers.
If the persistent database ever gets corrupted then the world comes to
an end and human intervention is needed. This violates a basic Postfix

View File

@ -338,7 +338,7 @@ anvil(8), Postfix connection/rate limiting
bounce(8), defer(8), trace(8), Delivery status reports
cleanup(8), canonicalize and enqueue message
discard(8), Postfix discard delivery agent
dnsblog(8), DNS black/whitelist logger
dnsblog(8), DNS allow/denylist logger
error(8), Postfix error delivery agent
flush(8), Postfix fast ETRN service
local(8), Postfix local delivery agent

View File

@ -118,8 +118,8 @@ this form is not required.
smtpd_client_restrictions = ... cidr:/etc/postfix/client.cidr ...
/etc/postfix/client.cidr:
# Rule order matters. Put more specific whitelist entries
# before more general blacklist entries.
# Rule order matters. Put more specific allowlist entries
# before more general denylist entries.
192.168.1.1 OK
192.168.0.0/16 REJECT
2001:db8::1 OK

View File

@ -1602,7 +1602,7 @@ See reject_unknown_reverse_client_hostname for more details.
The hostname given in HELO or EHLO command or empty string.
.br
.IP "\fB$rbl_class\fR"
The blacklisted entity type: Client host, Helo command, Sender
The denylisted entity type: Client host, Helo command, Sender
address, or Recipient address.
.br
.IP "\fB$rbl_code\fR"
@ -1613,14 +1613,14 @@ reply. With Postfix version 2.3 and later this information may be followed
by an RFC 3463 enhanced status code.
.br
.IP "\fB$rbl_domain\fR"
The RBL domain where $rbl_what is blacklisted.
The RBL domain where $rbl_what is denylisted.
.br
.IP "\fB$rbl_reason\fR"
The reason why $rbl_what is blacklisted, or an empty string.
The reason why $rbl_what is denylisted, or an empty string.
.br
.IP "\fB$rbl_what\fR"
The entity that is blacklisted (an IP address, a hostname, a domain
name, or an email address whose domain was blacklisted).
The entity that is denylisted (an IP address, a hostname, a domain
name, or an email address whose domain was denylisted).
.br
.IP "\fB$recipient\fR"
The recipient address or <> in case of the null address.
@ -1910,7 +1910,7 @@ A debugging aid to artificially delay DNS responses.
This feature is available in Postfix 2.8.
.SH dnsblog_service_name (default: dnsblog)
The name of the \fBdnsblog\fR(8) service entry in master.cf. This
service performs DNS white/blacklist lookups.
service performs DNS allow/denylist lookups.
.PP
This feature is available in Postfix 2.8 and later.
.SH dnssec_probe (default: ns:.)
@ -4348,7 +4348,7 @@ by default.
.ft R
.PP
The milter_header_checks mechanism could also be used for
whitelisting. For example it could be used to skip heavy content
allowlisting. For example it could be used to skip heavy content
inspection for DKIM\-signed mail from known friendly domains.
.PP
This feature is available in Postfix 2.7, and as an optional
@ -4919,13 +4919,13 @@ and enabled instances are processed in reverse order.
.PP
This feature is available in Postfix 2.6 and later.
.SH postscreen_access_list (default: permit_mynetworks)
Permanent white/blacklist for remote SMTP client IP addresses.
Permanent allow/denylist for remote SMTP client IP addresses.
\fBpostscreen\fR(8) searches this list immediately after a remote SMTP
client connects. Specify a comma\- or whitespace\-separated list of
commands (in upper or lower case) or lookup tables. The search stops
upon the first command that fires for the client IP address.
.IP "\fB permit_mynetworks \fR"
Whitelist the client and
Allowlist the client and
terminate the search if the client IP address matches $mynetworks.
Do not subject the client to any before/after 220 greeting tests.
Pass the connection immediately to a Postfix SMTP server process.
@ -4944,13 +4944,13 @@ support for substring matching like \fBsmtpd\fR(8). Use CIDR tables
instead.
.br
.IP "\fB permit \fR"
Whitelist the client and terminate
Allowlist the client and terminate
the search. Do not subject the client to any before/after 220
greeting tests. Pass the connection immediately to a Postfix SMTP
server process.
.br
.IP "\fB reject \fR"
Blacklist the client and terminate
Denylist the client and terminate
the search. Subject the client to the action configured with the
postscreen_blacklist_action configuration parameter.
.br
@ -4986,7 +4986,7 @@ Example:
.ft C
/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 dunno
192.168.0.0/16 reject
.fi
@ -5039,7 +5039,7 @@ one\-letter suffix that specifies the time unit). Time units: s
This feature is available in Postfix 2.8.
.SH postscreen_blacklist_action (default: ignore)
The action that \fBpostscreen\fR(8) takes when a remote SMTP client is
permanently blacklisted with the postscreen_access_list parameter.
permanently denylisted with the postscreen_access_list parameter.
Specify one of the following:
.IP "\fBignore\fR (default)"
Ignore this result. Allow other tests to complete. Repeat
@ -5088,7 +5088,7 @@ approach see the \fBmemcache_table\fR(5) manpage.
This feature is available in Postfix 2.8.
.SH postscreen_cache_retention_time (default: 7d)
The amount of time that \fBpostscreen\fR(8) will cache an expired
temporary whitelist entry before it is removed. This prevents clients
temporary allowlist entry before it is removed. This prevents clients
from being logged as "NEW" just because their cache entry expired
an hour ago. It also prevents the cache from filling up with clients
that passed some deep protocol test once and never came back.
@ -5227,7 +5227,7 @@ Example:
.PP
This feature is available in Postfix 2.8.
.SH postscreen_dnsbl_sites (default: empty)
Optional list of DNS white/blacklist domains, filters and weight
Optional list of DNS allow/denylist domains, filters and weight
factors. When the list is non\-empty, the \fBdnsblog\fR(8) daemon will
query these domains with the IP addresses of remote SMTP clients,
and \fBpostscreen\fR(8) will update an SMTP client's DNSBL score with
@ -5254,7 +5254,7 @@ When no "*weight" is specified, \fBpostscreen\fR(8) increments
the remote SMTP client's DNSBL score by 1. Otherwise, the weight must be
an integral number, and \fBpostscreen\fR(8) adds the specified weight to
the remote SMTP client's DNSBL score. Specify a negative number for
whitelisting.
allowlisting.
.IP \(bu
When one postscreen_dnsbl_sites entry produces multiple
DNSBL responses, \fBpostscreen\fR(8) applies the weight at most once.
@ -5361,7 +5361,7 @@ this test the next time the client connects.
.br
.br
.PP
In either case, \fBpostscreen\fR(8) will not whitelist the remote SMTP client
In either case, \fBpostscreen\fR(8) will not allowlist the remote SMTP client
IP address.
.PP
This feature is available in Postfix 2.8.
@ -5497,10 +5497,10 @@ receive a 421 response.
.PP
This feature is available in Postfix 2.8.
.SH postscreen_pre_queue_limit (default: $default_process_limit)
The number of non\-whitelisted clients that can be waiting for
The number of non\-allowlisted clients that can be waiting for
a decision whether they will receive service from a real Postfix
SMTP server
process. When this queue is full, all non\-whitelisted clients will
process. When this queue is full, all non\-allowlisted clients will
receive a 421 response.
.PP
This feature is available in Postfix 2.8.
@ -5558,18 +5558,18 @@ one\-letter suffix that specifies the time unit). Time units: s
This feature is available in Postfix 2.8.
.SH postscreen_whitelist_interfaces (default: static:all)
A list of local \fBpostscreen\fR(8) server IP addresses where a
non\-whitelisted remote SMTP client can obtain \fBpostscreen\fR(8)'s temporary
whitelist status. This status is required before the client can
non\-allowlisted remote SMTP client can obtain \fBpostscreen\fR(8)'s temporary
allowlist status. This status is required before the client can
talk to a Postfix SMTP server process. By default, a client can
obtain \fBpostscreen\fR(8)'s whitelist status on any local \fBpostscreen\fR(8)
obtain \fBpostscreen\fR(8)'s allowlist status on any local \fBpostscreen\fR(8)
server IP address.
.PP
When \fBpostscreen\fR(8) listens on both primary and backup MX
addresses, the postscreen_whitelist_interfaces parameter can be
configured to give the temporary whitelist status only when a client
connects to a primary MX address. Once a client is whitelisted it
configured to give the temporary allowlist status only when a client
connects to a primary MX address. Once a client is allowlisted it
can talk to a Postfix SMTP server on any address. Thus, clients
that connect only to backup MX addresses will never become whitelisted,
that connect only to backup MX addresses will never become allowlisted,
and will never be allowed to talk to a Postfix SMTP server process.
.PP
Specify a list of network addresses or network/netmask patterns,
@ -5598,7 +5598,7 @@ Example:
.na
.ft C
/etc/postfix/main.cf:
# Don't whitelist connections to the backup IP address.
# Don't allowlist connections to the backup IP address.
postscreen_whitelist_interfaces = !168.100.189.8, static:all
.fi
.ad
@ -9761,7 +9761,7 @@ least significant octets. See the \fBaccess\fR(5) manual page for details.
Search the specified \fBaccess\fR(5) database for the IP addresses for the
client hostname, and execute the corresponding action. Note: a result
of "OK" is not allowed for safety reasons. Instead, use DUNNO in order
to exclude specific hosts from blacklists. This feature is available
to exclude specific hosts from denylists. This feature is available
in Postfix 3.0 and later.
.br
.IP "\fBcheck_client_mx_access \fItype:table\fR\fR"
@ -9770,14 +9770,14 @@ client hostname, and execute the corresponding action. If no MX
record is found, look up A or AAAA records, just like the Postfix
SMTP client would. Note: a result
of "OK" is not allowed for safety reasons. Instead, use DUNNO in order
to exclude specific hosts from blacklists. This feature is available
to exclude specific hosts from denylists. This feature is available
in Postfix 2.7 and later.
.br
.IP "\fBcheck_client_ns_access \fItype:table\fR\fR"
Search the specified \fBaccess\fR(5) database for the DNS servers for
the client hostname, and execute the corresponding action. Note: a
result of "OK" is not allowed for safety reasons. Instead, use DUNNO
in order to exclude specific hosts from blacklists. This feature is
in order to exclude specific hosts from denylists. This feature is
available in Postfix 2.7 and later.
.br
.IP "\fBcheck_reverse_client_hostname_access \fItype:table\fR\fR"
@ -9786,14 +9786,14 @@ client hostname, parent domains, client IP address, or networks
obtained by stripping least significant octets. See the \fBaccess\fR(5)
manual page for details. Note: a result of "OK" is not allowed for
safety reasons. Instead, use DUNNO in order to exclude specific
hosts from blacklists. This feature is available in Postfix 2.6
hosts from denylists. This feature is available in Postfix 2.6
and later.
.br
.IP "\fBcheck_reverse_client_hostname_a_access \fItype:table\fR\fR"
Search the specified \fBaccess\fR(5) database for the IP addresses for the
unverified reverse client hostname, and execute the corresponding
action. Note: a result of "OK" is not allowed for safety reasons.
Instead, use DUNNO in order to exclude specific hosts from blacklists.
Instead, use DUNNO in order to exclude specific hosts from denylists.
This feature is available in Postfix 3.0 and later.
.br
.IP "\fBcheck_reverse_client_hostname_mx_access \fItype:table\fR\fR"
@ -9802,14 +9802,14 @@ unverified reverse client hostname, and execute the corresponding
action. If no MX record is found, look up A or AAAA records, just
like the Postfix SMTP client would.
Note: a result of "OK" is not allowed for safety reasons.
Instead, use DUNNO in order to exclude specific hosts from blacklists.
Instead, use DUNNO in order to exclude specific hosts from denylists.
This feature is available in Postfix 2.7 and later.
.br
.IP "\fBcheck_reverse_client_hostname_ns_access \fItype:table\fR\fR"
Search the specified \fBaccess\fR(5) database for the DNS servers for
the unverified reverse client hostname, and execute the corresponding
action. Note: a result of "OK" is not allowed for safety reasons.
Instead, use DUNNO in order to exclude specific hosts from blacklists.
Instead, use DUNNO in order to exclude specific hosts from denylists.
This feature is available in Postfix 2.7 and later.
.br
.IP "\fBcheck_sasl_access \fItype:table\fR\fR"
@ -9889,7 +9889,7 @@ reversed client network address is listed with any A record under
.br
For safety, permit_dnswl_client is silently
ignored when it would override reject_unauth_destination. The
result is DEFER_IF_REJECT when whitelist lookup fails. This feature
result is DEFER_IF_REJECT when allowlist lookup fails. This feature
is available in Postfix 2.8 and later.
.br
.IP "\fBreject_rhsbl_client \fIrbl_domain=d.d.d.d\fR\fR"
@ -9914,14 +9914,14 @@ is a number, or a pattern inside "[]" that contains one or more
"\fI=d.d.d.d\fR" is specified, accept the request when the client
hostname is listed with any A record under \fIrhswl_domain\fR.
.br
Caution: client name whitelisting is fragile, since the client
Caution: client name allowlisting is fragile, since the client
name lookup can fail due to temporary outages. Client name
whitelisting should be used only to reduce false positives in e.g.
allowlisting should be used only to reduce false positives in e.g.
DNS\-based blocklists, and not for making access rule exceptions.
.br
For safety, permit_rhswl_client is silently ignored when it
would override reject_unauth_destination. The result is DEFER_IF_REJECT
when whitelist lookup fails. This feature is available in Postfix
when allowlist lookup fails. This feature is available in Postfix
2.8 and later.
.br
.IP "\fBreject_rhsbl_reverse_client \fIrbl_domain=d.d.d.d\fR\fR"
@ -9987,7 +9987,7 @@ the SMTP server reply code (default: 450).
.br
.IP "\fBdefer_if_permit\fR"
Defer the request if some later restriction would result in an
explicit or implicit PERMIT action. This is useful when a blacklisting
explicit or implicit PERMIT action. This is useful when a denylisting
feature fails due to a temporary problem. This feature is available
in Postfix version 2.1 and later.
.br
@ -10429,7 +10429,7 @@ simply skip check_helo_access by not sending HELO or EHLO).
Search the specified \fBaccess\fR(5) database for the IP addresses for
the HELO or EHLO hostname, and execute the corresponding action.
Note 1: a result of "OK" is not allowed for safety reasons. Instead,
use DUNNO in order to exclude specific hosts from blacklists. Note
use DUNNO in order to exclude specific hosts from denylists. Note
2: specify "smtpd_helo_required = yes" to fully enforce this
restriction (without "smtpd_helo_required = yes", a client can
simply skip check_helo_a_access by not sending HELO or EHLO). This
@ -10441,7 +10441,7 @@ the HELO or EHLO hostname, and execute the corresponding action.
If no MX record is found, look up A or AAAA records, just like the
Postfix SMTP client would.
Note 1: a result of "OK" is not allowed for safety reasons. Instead,
use DUNNO in order to exclude specific hosts from blacklists. Note
use DUNNO in order to exclude specific hosts from denylists. Note
2: specify "smtpd_helo_required = yes" to fully enforce this
restriction (without "smtpd_helo_required = yes", a client can
simply skip check_helo_mx_access by not sending HELO or EHLO). This
@ -10451,7 +10451,7 @@ feature is available in Postfix 2.1 and later.
Search the specified \fBaccess\fR(5) database for the DNS servers
for the HELO or EHLO hostname, and execute the corresponding action.
Note 1: a result of "OK" is not allowed for safety reasons. Instead,
use DUNNO in order to exclude specific hosts from blacklists. Note
use DUNNO in order to exclude specific hosts from denylists. Note
2: specify "smtpd_helo_required = yes" to fully enforce this
restriction (without "smtpd_helo_required = yes", a client can
simply skip check_helo_ns_access by not sending HELO or EHLO). This
@ -10835,7 +10835,7 @@ corresponding action.
Search the specified \fBaccess\fR(5) database for the IP addresses for
the RCPT TO domain, and execute the corresponding action. Note:
a result of "OK" is not allowed for safety reasons. Instead, use
DUNNO in order to exclude specific hosts from blacklists. This
DUNNO in order to exclude specific hosts from denylists. This
feature is available in Postfix 3.0 and later.
.br
.IP "\fBcheck_recipient_mx_access \fItype:table\fR\fR"
@ -10844,14 +10844,14 @@ the RCPT TO domain, and execute the corresponding action. If no
MX record is found, look up A or AAAA records, just like the Postfix
SMTP client would. Note:
a result of "OK" is not allowed for safety reasons. Instead, use
DUNNO in order to exclude specific hosts from blacklists. This
DUNNO in order to exclude specific hosts from denylists. This
feature is available in Postfix 2.1 and later.
.br
.IP "\fBcheck_recipient_ns_access \fItype:table\fR\fR"
Search the specified \fBaccess\fR(5) database for the DNS servers
for the RCPT TO domain, and execute the corresponding action.
Note: a result of "OK" is not allowed for safety reasons. Instead,
use DUNNO in order to exclude specific hosts from blacklists. This
use DUNNO in order to exclude specific hosts from denylists. This
feature is available in Postfix 2.1 and later.
.br
.IP "\fBpermit_auth_destination\fR"
@ -11518,7 +11518,7 @@ corresponding action.
Search the specified \fBaccess\fR(5) database for the IP addresses for
the MAIL FROM domain, and execute the corresponding action. Note:
a result of "OK" is not allowed for safety reasons. Instead, use
DUNNO in order to exclude specific hosts from blacklists. This
DUNNO in order to exclude specific hosts from denylists. This
feature is available in Postfix 3.0 and later.
.br
.IP "\fBcheck_sender_mx_access \fItype:table\fR\fR"
@ -11527,14 +11527,14 @@ the MAIL FROM domain, and execute the corresponding action. If no
MX record is found, look up A or AAAA records, just like the Postfix
SMTP client would. Note:
a result of "OK" is not allowed for safety reasons. Instead, use
DUNNO in order to exclude specific hosts from blacklists. This
DUNNO in order to exclude specific hosts from denylists. This
feature is available in Postfix 2.1 and later.
.br
.IP "\fBcheck_sender_ns_access \fItype:table\fR\fR"
Search the specified \fBaccess\fR(5) database for the DNS servers
for the MAIL FROM domain, and execute the corresponding action.
Note: a result of "OK" is not allowed for safety reasons. Instead,
use DUNNO in order to exclude specific hosts from blacklists. This
use DUNNO in order to exclude specific hosts from denylists. This
feature is available in Postfix 2.1 and later.
.br
.IP "\fBreject_authenticated_sender_login_mismatch\fR"

View File

@ -4,7 +4,7 @@
.SH NAME
dnsblog
\-
Postfix DNS white/blacklist logger
Postfix DNS allow/denylist logger
.SH "SYNOPSIS"
.na
.nf
@ -13,7 +13,7 @@ Postfix DNS white/blacklist logger
.ad
.fi
The \fBdnsblog\fR(8) server implements an ad\-hoc DNS
white/blacklist lookup service. This may eventually be
allow/denylist lookup service. This may eventually be
replaced by an UDP client that is built directly into the
\fBpostscreen\fR(8) server.
.SH "PROTOCOL"
@ -22,8 +22,8 @@ replaced by an UDP client that is built directly into the
.ad
.fi
With each connection, the \fBdnsblog\fR(8) server receives
a DNS white/blacklist domain name, an IP address, and an ID.
If the IP address is listed under the DNS white/blacklist, the
a DNS allow/denylist domain name, an IP address, and an ID.
If the IP address is listed under the DNS allow/denylist, the
\fBdnsblog\fR(8) server logs the match and replies with the
query arguments plus an address list with the resulting IP
addresses, separated by whitespace, and the reply TTL.
@ -55,7 +55,7 @@ configuration files.
How much time a Postfix daemon process may take to handle a
request before it is terminated by a built\-in watchdog timer.
.IP "\fBpostscreen_dnsbl_sites (empty)\fR"
Optional list of DNS white/blacklist domains, filters and weight
Optional list of DNS allow/denylist domains, filters and weight
factors.
.IP "\fBipc_timeout (3600s)\fR"
The time limit for sending or receiving information over an internal

View File

@ -29,9 +29,9 @@ Alternatively, a site could set up a dedicated, non\-postscreen,
"port 25" server that provides \fBsubmission\fR service and
client authentication, but no MX service.
\fBpostscreen\fR(8) maintains a temporary whitelist for
\fBpostscreen\fR(8) maintains a temporary allowlist for
clients that have passed a number of tests. When an SMTP
client IP address is whitelisted, \fBpostscreen\fR(8) hands
client IP address is allowlisted, \fBpostscreen\fR(8) hands
off the connection immediately to a Postfix SMTP server
process. This minimizes the overhead for legitimate mail.
@ -169,27 +169,27 @@ proxy agent.
.IP "\fBpostscreen_upstream_proxy_timeout (5s)\fR"
The time limit for the proxy protocol specified with the
postscreen_upstream_proxy_protocol parameter.
.SH "PERMANENT WHITE/BLACKLIST TEST"
.SH "PERMANENT ALLOW/DENYLIST TEST"
.na
.nf
.ad
.fi
This test is executed immediately after a remote SMTP client
connects. If a client is permanently whitelisted, the client
connects. If a client is permanently allowlisted, the client
will be handed off immediately to a Postfix SMTP server
process.
.IP "\fBpostscreen_access_list (permit_mynetworks)\fR"
Permanent white/blacklist for remote SMTP client IP addresses.
Permanent allow/denylist for remote SMTP client IP addresses.
.IP "\fBpostscreen_blacklist_action (ignore)\fR"
The action that \fBpostscreen\fR(8) takes when a remote SMTP client is
permanently blacklisted with the postscreen_access_list parameter.
permanently denylisted with the postscreen_access_list parameter.
.SH "MAIL EXCHANGER POLICY TESTS"
.na
.nf
.ad
.fi
When \fBpostscreen\fR(8) is configured to monitor all primary
and backup MX addresses, it can refuse to whitelist clients
and backup MX addresses, it can refuse to allowlist clients
that connect to a backup MX address only. For small sites,
this requires configuring primary and backup MX addresses
on the same MTA. Larger sites would have to share the
@ -197,8 +197,8 @@ on the same MTA. Larger sites would have to share the
which would introduce a common point of failure.
.IP "\fBpostscreen_whitelist_interfaces (static:all)\fR"
A list of local \fBpostscreen\fR(8) server IP addresses where a
non\-whitelisted remote SMTP client can obtain \fBpostscreen\fR(8)'s temporary
whitelist status.
non\-allowlisted remote SMTP client can obtain \fBpostscreen\fR(8)'s temporary
allowlist status.
.SH "BEFORE 220 GREETING TESTS"
.na
.nf
@ -221,7 +221,7 @@ A mapping from actual DNSBL domain name which includes a secret
password, to the DNSBL domain name that postscreen will reply with
when it rejects mail.
.IP "\fBpostscreen_dnsbl_sites (empty)\fR"
Optional list of DNS white/blacklist domains, filters and weight
Optional list of DNS allow/denylist domains, filters and weight
factors.
.IP "\fBpostscreen_dnsbl_threshold (1)\fR"
The inclusive lower bound for blocking a remote SMTP client, based on
@ -306,7 +306,7 @@ The amount of time between \fBpostscreen\fR(8) cache cleanup runs.
Persistent storage for the \fBpostscreen\fR(8) server decisions.
.IP "\fBpostscreen_cache_retention_time (7d)\fR"
The amount of time that \fBpostscreen\fR(8) will cache an expired
temporary whitelist entry before it is removed.
temporary allowlist entry before it is removed.
.IP "\fBpostscreen_bare_newline_ttl (30d)\fR"
The amount of time that \fBpostscreen\fR(8) will use the result from
a successful "bare newline" SMTP protocol test.
@ -349,7 +349,7 @@ built\-in SMTP protocol engine.
The number of clients that can be waiting for service from a
real Postfix SMTP server process.
.IP "\fBpostscreen_pre_queue_limit ($default_process_limit)\fR"
The number of non\-whitelisted clients that can be waiting for
The number of non\-allowlisted clients that can be waiting for
a decision whether they will receive service from a real Postfix
SMTP server
process.
@ -420,7 +420,7 @@ The email address form that will be used in non\-debug logging
.nf
smtpd(8), Postfix SMTP server
tlsproxy(8), Postfix TLS proxy server
dnsblog(8), DNS black/whitelist logger
dnsblog(8), DNS allow/denylist logger
postlogd(8), Postfix logging
syslogd(8), system logging
.SH "README FILES"

View File

@ -14,8 +14,8 @@ Postfix TLS proxy
.fi
The \fBtlsproxy\fR(8) server implements a two\-way TLS proxy. It
is used by the \fBpostscreen\fR(8) server to talk SMTP\-over\-TLS
with remote SMTP clients that are not whitelisted (including
clients whose whitelist status has expired), and by the
with remote SMTP clients that are not allowlisted (including
clients whose allowlist status has expired), and by the
\fBsmtp\fR(8) client to support TLS connection reuse, but it
should also work for non\-SMTP protocols.

View File

@ -76,7 +76,7 @@ Recipient 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.
denylisted by some providers.
If the persistent database ever gets corrupted then the world
comes to an end and human intervention is needed. This violates

View File

@ -22,7 +22,7 @@
<p> 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 "<a
site to be denylisted by some providers. See also the "<a
href="#limitations">Limitations</a>" section below for more. </p>
<h2><a name="summary">What Postfix address verification can do for you</a></h2>
@ -211,7 +211,7 @@ address is deliverable. In reality, mail for a remote address can
bounce AFTER a preferred MTA accepts the recipient address, or AFTER
a preferred MTA accepts the message content. </p>
<li> <p> Some sites may blacklist you when you are probing them
<li> <p> 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: </p>
<p> This is also a good way to populate your cache with address
verification results before you start to actually reject mail. </p>
<p> The sender_access restriction is needed to whitelist domains
<p> 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. </p>
<p> NOTE: You will have to whitelist sites such as securityfocus.com
<p> 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

View File

@ -737,14 +737,14 @@ those numbers were 92% and 95%, respectively. While postscreen(8)
keeps the zombies away, more smtpd(8) processes remain available
for legitimate clients. </p>
<p> postscreen(8) maintains a temporary whitelist for clients that
pass its tests; by allowing whitelisted clients to skip tests,
<p> 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.
</p>
<p> 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. </p>

View File

@ -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. </p>
<p> postscreen(8) maintains a temporary whitelist for clients that
pass its tests; by allowing whitelisted clients to skip tests,
<p> 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.
</p>
@ -110,11 +110,11 @@ spending most of its resources not receiving email. </p>
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. </p>
<p> 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. </p>
<p> 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. </p>
@ -138,8 +138,8 @@ and that is the problem that postscreen(8) is focused on. </p>
<p> For 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. </p>
@ -158,25 +158,25 @@ overhead for legitimate clients. </p>
<h2> <a name="quick">Quick tests before everything else</a> </h2>
<p> 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. </p>
<ul>
<li> <a href="#perm_white_black"> Permanent white/blacklist test </a>
<li> <a href="#perm_white_black"> Permanent allow/denylist test </a>
<li> <a href="#temp_white"> Temporary whitelist test </a>
<li> <a href="#temp_white"> Temporary allowlist test </a>
<li> <a href="#white_veto"> MX Policy test </a>
</ul>
<h3> <a name="perm_white_black"> Permanent white/blacklist test </a> </h3>
<h3> <a name="perm_white_black"> Permanent allow/denylist test </a> </h3>
<p> 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. </p>
one would specify something that allowlists local networks, followed
by a CIDR table for selective allow- and denylisting. </p>
<p> Example: </p>
@ -187,7 +187,7 @@ by a CIDR table for selective white- and blacklisting. </p>
/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
</pre>
@ -203,7 +203,7 @@ postscreen(8) logs this with the client address and port number as:
<b>WHITELISTED</b> <i>[address]:port</i>
</pre>
<p> The whitelist action is not configurable: immediately hand off the
<p> The allowlist action is not configurable: immediately hand off the
connection to a Postfix SMTP server process. </p>
<p> When the SMTP client address matches a "reject" action,
@ -218,21 +218,21 @@ postscreen(8) logs this with the client address and port number as:
that is taken next. See "<a href="#fail_before_220">When tests
fail before the 220 SMTP server greeting</a>" below. </p>
<h3> <a name="temp_white"> Temporary whitelist test </a> </h3>
<h3> <a name="temp_white"> Temporary allowlist test </a> </h3>
<p> The postscreen(8) daemon maintains a <i>temporary</i>
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 <i>permanent</i> access list. </p>
<p> By default the temporary whitelist is not shared with other
<p> By default the temporary allowlist is not shared with other
postscreen(8) daemons. See <a href="#temp_white_sharing"> Sharing
the temporary whitelist </a> below for alternatives. </p>
the temporary allowlist </a> below for alternatives. </p>
<p> 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: </p>
<pre>
@ -241,19 +241,19 @@ number as: </p>
<p> 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. </p>
<h3> <a name="white_veto"> MX Policy test </a> </h3>
<p> 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. </p>
<p> 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). </p>
@ -274,7 +274,7 @@ files and "refresh" the network protocol stack. </p>
(this step is needed when you have specified inet_interfaces in
main.cf). </p>
<li> <p> Then, configure postscreen(8) to deny the temporary whitelist
<li> <p> Then, configure postscreen(8) to deny the temporary allowlist
status on the backup MX address(es). An example for Wietse's
server is: </p>
@ -283,13 +283,13 @@ server is: </p>
postscreen_whitelist_interfaces = !168.100.189.8 static:all
</pre>
<p> Translation: allow clients to obtain the temporary whitelist
<p> 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. </p>
</ul>
<p> When a non-whitelisted client connects the backup MX address,
<p> When a non-allowlisted client connects the backup MX address,
postscreen(8) logs this with the client address and port number as:
</p>
@ -299,9 +299,9 @@ postscreen(8) logs this with the client address and port number as:
</pre>
<p> Translation: the client at <i>[address]:port</i> 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. </p>
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. </p>
<h2> <a name="before_220"> Tests before the 220 SMTP server greeting </a> </h2>
@ -311,7 +311,7 @@ postscreen(8) can run a number of tests in parallel. </p>
<p> When a good client passes these tests, and no "<a
href="#after_220">deep protocol tests</a>" 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). </p>
@ -320,7 +320,7 @@ for the short postscreen_greet_wait delay). </p>
<li> <a href="#pregreet"> Pregreet test </a>
<li> <a href="#dnsbl"> DNS White/blacklist test </a>
<li> <a href="#dnsbl"> DNS Allow/denylist test </a>
<li> <a href="#fail_before_220">When tests fail before the 220 SMTP server greeting</a>
@ -348,8 +348,8 @@ an empty teaser banner: </p>
<pre>
/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: </p>
<pre>
/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 =
</pre>
@ -382,11 +382,11 @@ and \n for newline). </p>
is taken next. See "<a href="#fail_before_220">When tests fail
before the 220 SMTP server greeting</a>" below. </p>
<h3> <a name="dnsbl"> DNS White/blacklist test </a> </h3>
<h3> <a name="dnsbl"> DNS Allow/denylist test </a> </h3>
<p> 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. </p>
@ -416,7 +416,7 @@ before the 220 SMTP server greeting</a>" below. </p>
<h3> <a name="fail_before_220">When tests fail before the 220 SMTP server greeting</a> </h3>
<p> When the client address matches the permanent blacklist, or
<p> 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. </p>
@ -736,7 +736,7 @@ parameters control these limits. </p>
<h2> <a name="victory">When all tests succeed</a> </h2>
<p> When a new SMTP client passes all tests (i.e. it is not whitelisted
<p> When a new SMTP client passes all tests (i.e. it is not allowlisted
via some mechanism), postscreen(8) logs this as: </p>
<pre>
@ -745,8 +745,8 @@ via some mechanism), postscreen(8) logs this as: </p>
<p> Where <i>[address]:port</i> 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. </p>
<p> When no "<a href="#after_220">deep protocol tests</a>" are
@ -783,7 +783,7 @@ mail</a>
<li> <a href="#turnoff"> Turning off postscreen(8) </a>
<li> <a href="#temp_white_sharing"> Sharing the temporary whitelist
<li> <a href="#temp_white_sharing"> Sharing the temporary allowlist
</a>
</ul>
@ -803,8 +803,8 @@ tend to have broken SMTP implementations): </p>
<pre>
/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. </p>
<h3> <a name="starttls"> postscreen(8) TLS configuration </a> </h3>
<p> 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. </p>
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. </p>
zombies that haven't yet been denylisted. </p>
<li> <p> You can also enable "<a href="#after_220">deep protocol
tests</a>", but these are more intrusive than the pregreet or DNSBL
@ -984,7 +984,7 @@ tests. </p>
<p> When a good client passes the "<a href="#after_220">deep
protocol tests</a>", 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</a>" is that some "good" clients don't return after the 4XX
reply; these clients were not so good after all. </p>
<p> 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 "<a href="#after_220">deep protocol tests</a>"
on his own internet-facing mail server. </p>
<li> <p> There is also support for permanent blacklisting and
whitelisting; see the description of the postscreen_access_list
<li> <p> There is also support for permanent denylisting and
allowlisting; see the description of the postscreen_access_list
parameter for details. </p>
</ul>
@ -1070,15 +1070,15 @@ may follow. </p>
</ol>
<h3> <a name="temp_white_sharing"> Sharing the temporary whitelist </a> </h3>
<h3> <a name="temp_white_sharing"> Sharing the temporary allowlist </a> </h3>
<p> By default, the temporary whitelist is not shared between
<p> By default, the temporary allowlist is not shared between
multiple postscreen(8) daemons. To enable sharing, choose one
of the following options: </p>
<ul>
<li> <p> A non-persistent memcache: temporary whitelist can be shared
<li> <p> 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: </p>
persistent backup). This requires Postfix 2.9 or later. </p>
<pre>
# 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: </p>
</pre>
<li> <p>
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: </p>
cleanup. This requires Postfix 2.11 or later. </p>
<pre>
# 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
</pre>
<li> <p> Other kinds of persistent temporary whitelist can be shared
<li> <p> 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. </p>
<pre>
# 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. </p>
</body>
</html>

View File

@ -55,7 +55,7 @@ policies </a> </h2>
Mail servers happily forwarded mail on behalf of anyone towards
any destination. On today's Internet, spammers abuse servers that
forward mail from arbitrary systems, and abused systems end up on
anti-spammer blacklists. See, for example, the information on
anti-spammer denylists. See, for example, the information on
http://www.mail-abuse.org/ and other websites. </p>
<p> By default, Postfix has a moderately restrictive approach to
@ -87,11 +87,11 @@ SMTP client implementations. Protocol-oriented access controls
become less useful over time as spammers and worm writers learn to
read RFC documents. </p>
<li> <p> Blacklist oriented: some SMTP server access controls
query blacklists with known to be bad sites such as open mail
<li> <p> Denylist oriented: some SMTP server access controls
query denylists with known to be bad sites such as open mail
relays, open web proxies, and home computers that have been
compromised and that are under remote control by criminals. The
effectiveness of these blacklists depends on how complete and how
effectiveness of these denylists depends on how complete and how
up to date they are. </p>
<li> <p> Threshold oriented: some SMTP server access controls attempt
@ -218,7 +218,7 @@ some restriction produces a result of PERMIT, REJECT or DEFER (try
again later). The end of each list is equivalent to a PERMIT result.
By placing a PERMIT restriction before a REJECT restriction you
can make exceptions for specific clients or users. This is called
whitelisting; the fourth example above allows mail from local
allowlisting; the fourth example above allows mail from local
networks but otherwise rejects mail to arbitrary destinations. </p>
<p> The table below summarizes the purpose of each SMTP access
@ -320,7 +320,7 @@ until the RCPT TO command, it can log the sender and the recipient
address. This is more useful than logging only the client hostname
and IP address and not knowing whose mail was being blocked. </p>
<li> <p> Mixing is needed for complex whitelisting policies. For
<li> <p> Mixing is needed for complex allowlisting policies. For
example, in order to reject local sender addresses in mail from
non-local clients, you need to be able to mix restrictions on client
information with restrictions on sender information in the same

View File

@ -672,7 +672,7 @@ exceptions for mailing lists that use one-time sender addresses,
because each message will be delayed due to greylisting, and the
one-time sender addresses can pollute your greylist database
relatively quickly. Instead of making exceptions, you can automatically
whitelist clients that survive greylisting repeatedly; this avoids
allowlist clients that survive greylisting repeatedly; this avoids
most of the delays and most of the database pollution problem. </p>
<blockquote>
@ -746,11 +746,11 @@ $database_name="/var/mta/greylist.db";
$greylist_delay=60;
#
# Auto-whitelist threshold. Specify 0 to disable, or the number of
# Auto-allowlist threshold. Specify 0 to disable, or the number of
# successful "come backs" after which a client is no longer subject
# to greylisting.
#
$auto_whitelist_threshold = 10;
$auto_allowlist_threshold = 10;
#
# Demo SMTPD access policy routine. The result is an action just like
@ -763,10 +763,10 @@ sub smtpd_access_policy {
# Open the database on the fly.
open_database() unless $database_obj;
# Search the auto-whitelist.
if ($auto_whitelist_threshold &gt; 0) {
# Search the auto-allowlist.
if ($auto_allowlist_threshold &gt; 0) {
$count = read_database($attr{"client_address"});
if ($count &gt; $auto_whitelist_threshold) {
if ($count &gt; $auto_allowlist_threshold) {
return "dunno";
}
}
@ -795,8 +795,8 @@ sub smtpd_access_policy {
#
syslog $syslog_priority, "request age %d", $now - $time_stamp if $verbose;
if ($now - $time_stamp &gt; $greylist_delay) {
# Update the auto-whitelist.
if ($auto_whitelist_threshold &gt; 0) {
# Update the auto-allowlist.
if ($auto_allowlist_threshold &gt; 0) {
update_database($attr{"client_address"}, $count + 1);
}
return "dunno";

View File

@ -354,7 +354,7 @@ such as SMTP access maps. The Postfix SMTP server will reject mail
and disconnect without waiting for the remote SMTP client to send
a QUIT command. </p>
<li> <p> To hang up connections from blacklisted zombies, you can
<li> <p> To hang up connections from denylisted zombies, you can
set specific Postfix SMTP server reject codes for specific RBLs,
and for individual responses from specific RBLs. We'll use
zen.spamhaus.org as an example; by the time you read this document,

View File

@ -104,8 +104,8 @@
# smtpd_client_restrictions = ... cidr:/etc/postfix/client.cidr ...
#
# /etc/postfix/client.cidr:
# # Rule order matters. Put more specific whitelist entries
# # before more general blacklist entries.
# # Rule order matters. Put more specific allowlist entries
# # before more general denylist entries.
# 192.168.1.1 OK
# 192.168.0.0/16 REJECT
# 2001:db8::1 OK

View File

@ -1166,7 +1166,7 @@ See reject_unknown_reverse_client_hostname for more details. </dd>
<dt><b>$rbl_class</b></dt>
<dd>The blacklisted entity type: Client host, Helo command, Sender
<dd>The denylisted entity type: Client host, Helo command, Sender
address, or Recipient address. </dd>
<dt><b>$rbl_code</b></dt>
@ -1179,16 +1179,16 @@ by an RFC 3463 enhanced status code. </dd>
<dt><b>$rbl_domain</b></dt>
<dd>The RBL domain where $rbl_what is blacklisted. </dd>
<dd>The RBL domain where $rbl_what is denylisted. </dd>
<dt><b>$rbl_reason</b></dt>
<dd>The reason why $rbl_what is blacklisted, or an empty string. </dd>
<dd>The reason why $rbl_what is denylisted, or an empty string. </dd>
<dt><b>$rbl_what</b></dt>
<dd>The entity that is blacklisted (an IP address, a hostname, a domain
name, or an email address whose domain was blacklisted). </dd>
<dd>The entity that is denylisted (an IP address, a hostname, a domain
name, or an email address whose domain was denylisted). </dd>
<dt><b>$recipient</b></dt>
@ -5151,7 +5151,7 @@ least significant octets. See the access(5) manual page for details. </dd>
<dd>Search the specified access(5) database for the IP addresses for the
client hostname, and execute the corresponding action. Note: a result
of "OK" is not allowed for safety reasons. Instead, use DUNNO in order
to exclude specific hosts from blacklists. This feature is available
to exclude specific hosts from denylists. This feature is available
in Postfix 3.0 and later. </dd>
<dt><b><a name="check_client_mx_access">check_client_mx_access</a> <i><a href="DATABASE_README.html">type:table</a></i></b></dt>
@ -5161,7 +5161,7 @@ client hostname, and execute the corresponding action. If no MX
record is found, look up A or AAAA records, just like the Postfix
SMTP client would. Note: a result
of "OK" is not allowed for safety reasons. Instead, use DUNNO in order
to exclude specific hosts from blacklists. This feature is available
to exclude specific hosts from denylists. This feature is available
in Postfix 2.7 and later. </dd>
<dt><b><a name="check_client_ns_access">check_client_ns_access</a> <i><a href="DATABASE_README.html">type:table</a></i></b></dt>
@ -5169,7 +5169,7 @@ in Postfix 2.7 and later. </dd>
<dd>Search the specified access(5) database for the DNS servers for
the client hostname, and execute the corresponding action. Note: a
result of "OK" is not allowed for safety reasons. Instead, use DUNNO
in order to exclude specific hosts from blacklists. This feature is
in order to exclude specific hosts from denylists. This feature is
available in Postfix 2.7 and later. </dd>
<dt><b><a name="check_reverse_client_hostname_access">check_reverse_client_hostname_access</a> <i><a href="DATABASE_README.html">type:table</a></i></b></dt>
@ -5179,7 +5179,7 @@ client hostname, parent domains, client IP address, or networks
obtained by stripping least significant octets. See the access(5)
manual page for details. Note: a result of "OK" is not allowed for
safety reasons. Instead, use DUNNO in order to exclude specific
hosts from blacklists. This feature is available in Postfix 2.6
hosts from denylists. This feature is available in Postfix 2.6
and later.</dd>
<dt><b><a name="check_reverse_client_hostname_a_access">check_reverse_client_hostname_a_access</a> <i><a href="DATABASE_README.html">type:table</a></i></b></dt>
@ -5187,7 +5187,7 @@ and later.</dd>
<dd>Search the specified access(5) database for the IP addresses for the
unverified reverse client hostname, and execute the corresponding
action. Note: a result of "OK" is not allowed for safety reasons.
Instead, use DUNNO in order to exclude specific hosts from blacklists.
Instead, use DUNNO in order to exclude specific hosts from denylists.
This feature is available in Postfix 3.0 and later. </dd>
<dt><b><a name="check_reverse_client_hostname_mx_access">check_reverse_client_hostname_mx_access</a> <i><a href="DATABASE_README.html">type:table</a></i></b></dt>
@ -5197,7 +5197,7 @@ unverified reverse client hostname, and execute the corresponding
action. If no MX record is found, look up A or AAAA records, just
like the Postfix SMTP client would.
Note: a result of "OK" is not allowed for safety reasons.
Instead, use DUNNO in order to exclude specific hosts from blacklists.
Instead, use DUNNO in order to exclude specific hosts from denylists.
This feature is available in Postfix 2.7 and later. </dd>
<dt><b><a name="check_reverse_client_hostname_ns_access">check_reverse_client_hostname_ns_access</a> <i><a href="DATABASE_README.html">type:table</a></i></b></dt>
@ -5205,7 +5205,7 @@ This feature is available in Postfix 2.7 and later. </dd>
<dd>Search the specified access(5) database for the DNS servers for
the unverified reverse client hostname, and execute the corresponding
action. Note: a result of "OK" is not allowed for safety reasons.
Instead, use DUNNO in order to exclude specific hosts from blacklists.
Instead, use DUNNO in order to exclude specific hosts from denylists.
This feature is available in Postfix 2.7 and later. </dd>
<dt><b><a name="check_sasl_access">check_sasl_access</a> <i><a href="DATABASE_README.html">type:table</a></i></b></dt>
@ -5291,7 +5291,7 @@ If no "<i>=d.d.d.d</i>" is specified, accept the request when the
reversed client network address is listed with any A record under
<i>dnswl_domain</i>. <br> For safety, permit_dnswl_client is silently
ignored when it would override reject_unauth_destination. The
result is DEFER_IF_REJECT when whitelist lookup fails. This feature
result is DEFER_IF_REJECT when allowlist lookup fails. This feature
is available in Postfix 2.8 and later. </dd>
<dt><b><a name="reject_rhsbl_client">reject_rhsbl_client <i>rbl_domain=d.d.d.d</i></a></b></dt>
@ -5317,13 +5317,13 @@ is a number, or a pattern inside "[]" that contains one or more
";"-separated numbers or number..number ranges. If no
"<i>=d.d.d.d</i>" is specified, accept the request when the client
hostname is listed with any A record under <i>rhswl_domain</i>.
<br> Caution: client name whitelisting is fragile, since the client
<br> Caution: client name allowlisting is fragile, since the client
name lookup can fail due to temporary outages. Client name
whitelisting should be used only to reduce false positives in e.g.
allowlisting should be used only to reduce false positives in e.g.
DNS-based blocklists, and not for making access rule exceptions.
<br> For safety, permit_rhswl_client is silently ignored when it
would override reject_unauth_destination. The result is DEFER_IF_REJECT
when whitelist lookup fails. This feature is available in Postfix
when allowlist lookup fails. This feature is available in Postfix
2.8 and later. </dd>
<dt><b><a name="reject_rhsbl_reverse_client">reject_rhsbl_reverse_client <i>rbl_domain=d.d.d.d</i></a></b></dt>
@ -5402,7 +5402,7 @@ the SMTP server reply code (default: 450).</dd>
<dt><b><a name="defer_if_permit">defer_if_permit</a></b></dt>
<dd>Defer the request if some later restriction would result in an
explicit or implicit PERMIT action. This is useful when a blacklisting
explicit or implicit PERMIT action. This is useful when a denylisting
feature fails due to a temporary problem. This feature is available
in Postfix version 2.1 and later. </dd>
@ -5754,7 +5754,7 @@ simply skip check_helo_access by not sending HELO or EHLO). </dd>
<dd>Search the specified access(5) database for the IP addresses for
the HELO or EHLO hostname, and execute the corresponding action.
Note 1: a result of "OK" is not allowed for safety reasons. Instead,
use DUNNO in order to exclude specific hosts from blacklists. Note
use DUNNO in order to exclude specific hosts from denylists. Note
2: specify "smtpd_helo_required = yes" to fully enforce this
restriction (without "smtpd_helo_required = yes", a client can
simply skip check_helo_a_access by not sending HELO or EHLO). This
@ -5768,7 +5768,7 @@ the HELO or EHLO hostname, and execute the corresponding action.
If no MX record is found, look up A or AAAA records, just like the
Postfix SMTP client would.
Note 1: a result of "OK" is not allowed for safety reasons. Instead,
use DUNNO in order to exclude specific hosts from blacklists. Note
use DUNNO in order to exclude specific hosts from denylists. Note
2: specify "smtpd_helo_required = yes" to fully enforce this
restriction (without "smtpd_helo_required = yes", a client can
simply skip check_helo_mx_access by not sending HELO or EHLO). This
@ -5780,7 +5780,7 @@ feature is available in Postfix 2.1 and later.
<dd>Search the specified access(5) database for the DNS servers
for the HELO or EHLO hostname, and execute the corresponding action.
Note 1: a result of "OK" is not allowed for safety reasons. Instead,
use DUNNO in order to exclude specific hosts from blacklists. Note
use DUNNO in order to exclude specific hosts from denylists. Note
2: specify "smtpd_helo_required = yes" to fully enforce this
restriction (without "smtpd_helo_required = yes", a client can
simply skip check_helo_ns_access by not sending HELO or EHLO). This
@ -6047,7 +6047,7 @@ corresponding action. </dd>
<dd>Search the specified access(5) database for the IP addresses for
the RCPT TO domain, and execute the corresponding action. Note:
a result of "OK" is not allowed for safety reasons. Instead, use
DUNNO in order to exclude specific hosts from blacklists. This
DUNNO in order to exclude specific hosts from denylists. This
feature is available in Postfix 3.0 and later. </dd>
<dt><b><a name="check_recipient_mx_access">check_recipient_mx_access</a> <i><a href="DATABASE_README.html">type:table</a></i></b></dt>
@ -6057,7 +6057,7 @@ the RCPT TO domain, and execute the corresponding action. If no
MX record is found, look up A or AAAA records, just like the Postfix
SMTP client would. Note:
a result of "OK" is not allowed for safety reasons. Instead, use
DUNNO in order to exclude specific hosts from blacklists. This
DUNNO in order to exclude specific hosts from denylists. This
feature is available in Postfix 2.1 and later. </dd>
<dt><b><a name="check_recipient_ns_access">check_recipient_ns_access</a> <i><a href="DATABASE_README.html">type:table</a></i></b></dt>
@ -6065,7 +6065,7 @@ feature is available in Postfix 2.1 and later. </dd>
<dd>Search the specified access(5) database for the DNS servers
for the RCPT TO domain, and execute the corresponding action.
Note: a result of "OK" is not allowed for safety reasons. Instead,
use DUNNO in order to exclude specific hosts from blacklists. This
use DUNNO in order to exclude specific hosts from denylists. This
feature is available in Postfix 2.1 and later. </dd>
<dt><b><a name="permit_auth_destination">permit_auth_destination</a></b></dt>
@ -6560,7 +6560,7 @@ corresponding action. </dd>
<dd>Search the specified access(5) database for the IP addresses for
the MAIL FROM domain, and execute the corresponding action. Note:
a result of "OK" is not allowed for safety reasons. Instead, use
DUNNO in order to exclude specific hosts from blacklists. This
DUNNO in order to exclude specific hosts from denylists. This
feature is available in Postfix 3.0 and later. </dd>
<dt><b><a name="check_sender_mx_access">check_sender_mx_access</a> <i><a href="DATABASE_README.html">type:table</a></i></b></dt>
@ -6570,7 +6570,7 @@ the MAIL FROM domain, and execute the corresponding action. If no
MX record is found, look up A or AAAA records, just like the Postfix
SMTP client would. Note:
a result of "OK" is not allowed for safety reasons. Instead, use
DUNNO in order to exclude specific hosts from blacklists. This
DUNNO in order to exclude specific hosts from denylists. This
feature is available in Postfix 2.1 and later. </dd>
<dt><b><a name="check_sender_ns_access">check_sender_ns_access</a> <i><a href="DATABASE_README.html">type:table</a></i></b></dt>
@ -6578,7 +6578,7 @@ feature is available in Postfix 2.1 and later. </dd>
<dd>Search the specified access(5) database for the DNS servers
for the MAIL FROM domain, and execute the corresponding action.
Note: a result of "OK" is not allowed for safety reasons. Instead,
use DUNNO in order to exclude specific hosts from blacklists. This
use DUNNO in order to exclude specific hosts from denylists. This
feature is available in Postfix 2.1 and later. </dd>
<dt><b><a name="reject_authenticated_sender_login_mismatch">reject_authenticated_sender_login_mismatch</a></b></dt>
@ -14028,7 +14028,7 @@ by default. </p>
</pre>
<p> The milter_header_checks mechanism could also be used for
whitelisting. For example it could be used to skip heavy content
allowlisting. For example it could be used to skip heavy content
inspection for DKIM-signed mail from known friendly domains. </p>
<p> This feature is available in Postfix 2.7, and as an optional
@ -14065,10 +14065,10 @@ receive a 421 response. </p>
%PARAM postscreen_pre_queue_limit $default_process_limit
<p> The number of non-whitelisted clients that can be waiting for
<p> The number of non-allowlisted clients that can be waiting for
a decision whether they will receive service from a real Postfix
SMTP server
process. When this queue is full, all non-whitelisted clients will
process. When this queue is full, all non-allowlisted clients will
receive a 421 response. </p>
<p> This feature is available in Postfix 2.8. </p>
@ -14089,7 +14089,7 @@ one-letter suffix that specifies the time unit). Time units: s
%PARAM postscreen_cache_retention_time 7d
<p> The amount of time that postscreen(8) will cache an expired
temporary whitelist entry before it is removed. This prevents clients
temporary allowlist entry before it is removed. This prevents clients
from being logged as "NEW" just because their cache entry expired
an hour ago. It also prevents the cache from filling up with clients
that passed some deep protocol test once and never came back. </p>
@ -14135,7 +14135,7 @@ one-letter suffix that specifies the time unit). </p>
%PARAM postscreen_dnsbl_sites
<p>Optional list of DNS white/blacklist domains, filters and weight
<p>Optional list of DNS allow/denylist domains, filters and weight
factors. When the list is non-empty, the dnsblog(8) daemon will
query these domains with the IP addresses of remote SMTP clients,
and postscreen(8) will update an SMTP client's DNSBL score with
@ -14164,7 +14164,7 @@ or more ";"-separated numbers or number..number ranges. </p>
the remote SMTP client's DNSBL score by 1. Otherwise, the weight must be
an integral number, and postscreen(8) adds the specified weight to
the remote SMTP client's DNSBL score. Specify a negative number for
whitelisting. </p>
allowlisting. </p>
<li> <p> When one postscreen_dnsbl_sites entry produces multiple
DNSBL responses, postscreen(8) applies the weight at most once.
@ -14250,7 +14250,7 @@ this test the next time the client connects. </dd>
</dl>
<p> In either case, postscreen(8) will not whitelist the remote SMTP client
<p> In either case, postscreen(8) will not allowlist the remote SMTP client
IP address. </p>
<p> This feature is available in Postfix 2.8. </p>
@ -14276,7 +14276,7 @@ IP address. </p>
%PARAM postscreen_access_list permit_mynetworks
<p> Permanent white/blacklist for remote SMTP client IP addresses.
<p> Permanent allow/denylist for remote SMTP client IP addresses.
postscreen(8) searches this list immediately after a remote SMTP
client connects. Specify a comma- or whitespace-separated list of
commands (in upper or lower case) or lookup tables. The search stops
@ -14284,7 +14284,7 @@ upon the first command that fires for the client IP address. </p>
<dl>
<dt> <b> permit_mynetworks </b> </dt> <dd> Whitelist the client and
<dt> <b> permit_mynetworks </b> </dt> <dd> Allowlist the client and
terminate the search if the client IP address matches $mynetworks.
Do not subject the client to any before/after 220 greeting tests.
Pass the connection immediately to a Postfix SMTP server process.
@ -14299,12 +14299,12 @@ To discourage the use of hash, btree, etc. tables, there is no
support for substring matching like smtpd(8). Use CIDR tables
instead. </dd>
<dt> <b> permit </b> </dt> <dd> Whitelist the client and terminate
<dt> <b> permit </b> </dt> <dd> Allowlist the client and terminate
the search. Do not subject the client to any before/after 220
greeting tests. Pass the connection immediately to a Postfix SMTP
server process. </dd>
<dt> <b> reject </b> </dt> <dd> Blacklist the client and terminate
<dt> <b> reject </b> </dt> <dd> Denylist the client and terminate
the search. Subject the client to the action configured with the
postscreen_blacklist_action configuration parameter. </dd>
@ -14329,7 +14329,7 @@ to the configured before/after 220 greeting tests. </dd>
<pre>
/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 dunno
192.168.0.0/16 reject
</pre>
@ -14350,7 +14350,7 @@ value to disable this feature. </p>
%PARAM postscreen_blacklist_action ignore
<p> The action that postscreen(8) takes when a remote SMTP client is
permanently blacklisted with the postscreen_access_list parameter.
permanently denylisted with the postscreen_access_list parameter.
Specify one of the following: </p>
<dl>
@ -15617,7 +15617,7 @@ See smtpd_command_filter for further details. </p>
%PARAM dnsblog_service_name dnsblog
<p> The name of the dnsblog(8) service entry in master.cf. This
service performs DNS white/blacklist lookups. </p>
service performs DNS allow/denylist lookups. </p>
<p> This feature is available in Postfix 2.8 and later. </p>
@ -15677,18 +15677,18 @@ configuration parameter. See there for details. </p>
%PARAM postscreen_whitelist_interfaces static:all
<p> A list of local postscreen(8) server IP addresses where a
non-whitelisted remote SMTP client can obtain postscreen(8)'s temporary
whitelist status. This status is required before the client can
non-allowlisted remote SMTP client can obtain postscreen(8)'s temporary
allowlist status. This status is required before the client can
talk to a Postfix SMTP server process. By default, a client can
obtain postscreen(8)'s whitelist status on any local postscreen(8)
obtain postscreen(8)'s allowlist status on any local postscreen(8)
server IP address. </p>
<p> When postscreen(8) listens on both primary and backup MX
addresses, the postscreen_whitelist_interfaces parameter can be
configured to give the temporary whitelist status only when a client
connects to a primary MX address. Once a client is whitelisted it
configured to give the temporary allowlist status only when a client
connects to a primary MX address. Once a client is allowlisted it
can talk to a Postfix SMTP server on any address. Thus, clients
that connect only to backup MX addresses will never become whitelisted,
that connect only to backup MX addresses will never become allowlisted,
and will never be allowed to talk to a Postfix SMTP server process.
</p>
@ -15716,7 +15716,7 @@ pattern. </p>
<pre>
/etc/postfix/main.cf:
# Don't whitelist connections to the backup IP address.
# Don't allowlist connections to the backup IP address.
postscreen_whitelist_interfaces = !168.100.189.8, static:all
</pre>

View File

@ -332,7 +332,7 @@ static struct __res_state dns_res_state;
#endif
/*
* To improve postscreen's whitelisting support, we need to know how long a
* To improve postscreen's allowlisting support, we need to know how long a
* DNSBL "not found" answer is valid. The 2010 implementation assumed it was
* valid for 3600 seconds. That is too long by 2015 standards.
*

View File

@ -2,20 +2,20 @@
/* NAME
/* dnsblog 8
/* SUMMARY
/* Postfix DNS white/blacklist logger
/* Postfix DNS allow/denylist logger
/* SYNOPSIS
/* \fBdnsblog\fR [generic Postfix daemon options]
/* DESCRIPTION
/* The \fBdnsblog\fR(8) server implements an ad-hoc DNS
/* white/blacklist lookup service. This may eventually be
/* allow/denylist lookup service. This may eventually be
/* replaced by an UDP client that is built directly into the
/* \fBpostscreen\fR(8) server.
/* PROTOCOL
/* .ad
/* .fi
/* With each connection, the \fBdnsblog\fR(8) server receives
/* a DNS white/blacklist domain name, an IP address, and an ID.
/* If the IP address is listed under the DNS white/blacklist, the
/* a DNS allow/denylist domain name, an IP address, and an ID.
/* If the IP address is listed under the DNS allow/denylist, the
/* \fBdnsblog\fR(8) server logs the match and replies with the
/* query arguments plus an address list with the resulting IP
/* addresses, separated by whitespace, and the reply TTL.
@ -43,7 +43,7 @@
/* How much time a Postfix daemon process may take to handle a
/* request before it is terminated by a built-in watchdog timer.
/* .IP "\fBpostscreen_dnsbl_sites (empty)\fR"
/* Optional list of DNS white/blacklist domains, filters and weight
/* Optional list of DNS allow/denylist domains, filters and weight
/* factors.
/* .IP "\fBipc_timeout (3600s)\fR"
/* The time limit for sending or receiving information over an internal

View File

@ -20,7 +20,7 @@
* Patches change both the patchlevel and the release date. Snapshots have no
* patchlevel; they change the release date only.
*/
#define MAIL_RELEASE_DATE "20210215"
#define MAIL_RELEASE_DATE "20210216"
#define MAIL_VERSION_NUMBER "3.6"
#ifdef SNAPSHOT

View File

@ -19,7 +19,7 @@
/* SERVER_ACL *intern_acl;
/* const char *param_name;
/* DESCRIPTION
/* This module implements a permanent black/whitelist that
/* This module implements a permanent allow/denylist that
/* is meant to be evaluated immediately after a client connects
/* to a server.
/*

View File

@ -324,7 +324,7 @@
/* bounce(8), defer(8), trace(8), Delivery status reports
/* cleanup(8), canonicalize and enqueue message
/* discard(8), Postfix discard delivery agent
/* dnsblog(8), DNS black/whitelist logger
/* dnsblog(8), DNS allow/denylist logger
/* error(8), Postfix error delivery agent
/* flush(8), Postfix fast ETRN service
/* local(8), Postfix local delivery agent

View File

@ -23,9 +23,9 @@
/* "port 25" server that provides \fBsubmission\fR service and
/* client authentication, but no MX service.
/*
/* \fBpostscreen\fR(8) maintains a temporary whitelist for
/* \fBpostscreen\fR(8) maintains a temporary allowlist for
/* clients that have passed a number of tests. When an SMTP
/* client IP address is whitelisted, \fBpostscreen\fR(8) hands
/* client IP address is allowlisted, \fBpostscreen\fR(8) hands
/* off the connection immediately to a Postfix SMTP server
/* process. This minimizes the overhead for legitimate mail.
/*
@ -147,23 +147,23 @@
/* .IP "\fBpostscreen_upstream_proxy_timeout (5s)\fR"
/* The time limit for the proxy protocol specified with the
/* postscreen_upstream_proxy_protocol parameter.
/* PERMANENT WHITE/BLACKLIST TEST
/* PERMANENT ALLOW/DENYLIST TEST
/* .ad
/* .fi
/* This test is executed immediately after a remote SMTP client
/* connects. If a client is permanently whitelisted, the client
/* connects. If a client is permanently allowlisted, the client
/* will be handed off immediately to a Postfix SMTP server
/* process.
/* .IP "\fBpostscreen_access_list (permit_mynetworks)\fR"
/* Permanent white/blacklist for remote SMTP client IP addresses.
/* Permanent allow/denylist for remote SMTP client IP addresses.
/* .IP "\fBpostscreen_blacklist_action (ignore)\fR"
/* The action that \fBpostscreen\fR(8) takes when a remote SMTP client is
/* permanently blacklisted with the postscreen_access_list parameter.
/* permanently denylisted with the postscreen_access_list parameter.
/* MAIL EXCHANGER POLICY TESTS
/* .ad
/* .fi
/* When \fBpostscreen\fR(8) is configured to monitor all primary
/* and backup MX addresses, it can refuse to whitelist clients
/* and backup MX addresses, it can refuse to allowlist clients
/* that connect to a backup MX address only. For small sites,
/* this requires configuring primary and backup MX addresses
/* on the same MTA. Larger sites would have to share the
@ -171,8 +171,8 @@
/* which would introduce a common point of failure.
/* .IP "\fBpostscreen_whitelist_interfaces (static:all)\fR"
/* A list of local \fBpostscreen\fR(8) server IP addresses where a
/* non-whitelisted remote SMTP client can obtain \fBpostscreen\fR(8)'s temporary
/* whitelist status.
/* non-allowlisted remote SMTP client can obtain \fBpostscreen\fR(8)'s temporary
/* allowlist status.
/* BEFORE 220 GREETING TESTS
/* .ad
/* .fi
@ -193,7 +193,7 @@
/* password, to the DNSBL domain name that postscreen will reply with
/* when it rejects mail.
/* .IP "\fBpostscreen_dnsbl_sites (empty)\fR"
/* Optional list of DNS white/blacklist domains, filters and weight
/* Optional list of DNS allow/denylist domains, filters and weight
/* factors.
/* .IP "\fBpostscreen_dnsbl_threshold (1)\fR"
/* The inclusive lower bound for blocking a remote SMTP client, based on
@ -274,7 +274,7 @@
/* Persistent storage for the \fBpostscreen\fR(8) server decisions.
/* .IP "\fBpostscreen_cache_retention_time (7d)\fR"
/* The amount of time that \fBpostscreen\fR(8) will cache an expired
/* temporary whitelist entry before it is removed.
/* temporary allowlist entry before it is removed.
/* .IP "\fBpostscreen_bare_newline_ttl (30d)\fR"
/* The amount of time that \fBpostscreen\fR(8) will use the result from
/* a successful "bare newline" SMTP protocol test.
@ -315,7 +315,7 @@
/* The number of clients that can be waiting for service from a
/* real Postfix SMTP server process.
/* .IP "\fBpostscreen_pre_queue_limit ($default_process_limit)\fR"
/* The number of non-whitelisted clients that can be waiting for
/* The number of non-allowlisted clients that can be waiting for
/* a decision whether they will receive service from a real Postfix
/* SMTP server
/* process.
@ -378,7 +378,7 @@
/* SEE ALSO
/* smtpd(8), Postfix SMTP server
/* tlsproxy(8), Postfix TLS proxy server
/* dnsblog(8), DNS black/whitelist logger
/* dnsblog(8), DNS allow/denylist logger
/* postlogd(8), Postfix logging
/* syslogd(8), system logging
/* README FILES
@ -563,9 +563,9 @@ HTABLE *psc_client_concurrency; /* per-client concurrency */
/*
* Local variables and functions.
*/
static ARGV *psc_acl; /* permanent white/backlist */
static ARGV *psc_acl; /* permanent allow/denylist */
static int psc_blist_action; /* PSC_ACT_DROP/ENFORCE/etc */
static ADDR_MATCH_LIST *psc_wlist_if; /* whitelist interfaces */
static ADDR_MATCH_LIST *psc_wlist_if; /* allowlist interfaces */
static void psc_endpt_lookup_done(int, VSTREAM *,
MAI_HOSTADDR_STR *, MAI_SERVPORT_STR *,
@ -730,13 +730,13 @@ static void psc_endpt_lookup_done(int endpt_status,
}
/*
* The permanent white/blacklist has highest precedence.
* The permanent allow/denylist has highest precedence.
*/
if (psc_acl != 0) {
switch (psc_acl_eval(state, psc_acl, VAR_PSC_ACL)) {
/*
* Permanently blacklisted.
* Permanently denylisted.
*/
case PSC_ACL_ACT_BLACKLIST:
msg_info("BLACKLISTED [%s]:%s", PSC_CLIENT_ADDR_PORT(state));
@ -759,13 +759,13 @@ static void psc_endpt_lookup_done(int endpt_status,
*/
break;
default:
msg_panic("%s: unknown blacklist action value %d",
msg_panic("%s: unknown denylist action value %d",
myname, psc_blist_action);
}
break;
/*
* Permanently whitelisted.
* Permanently allowlisted.
*/
case PSC_ACL_ACT_WHITELIST:
msg_info("WHITELISTED [%s]:%s", PSC_CLIENT_ADDR_PORT(state));
@ -781,9 +781,9 @@ static void psc_endpt_lookup_done(int endpt_status,
}
/*
* The temporary whitelist (i.e. the postscreen cache) has the lowest
* The temporary allowlist (i.e. the postscreen cache) has the lowest
* precedence. This cache contains information about the results of prior
* tests. Whitelist the client when all enabled test results are still
* tests. Allowlist the client when all enabled test results are still
* valid.
*/
if ((state->flags & PSC_STATE_MASK_ANY_FAIL) == 0
@ -818,7 +818,7 @@ static void psc_endpt_lookup_done(int endpt_status,
}
/*
* Don't whitelist clients that connect to backup MX addresses. Fail
* Don't allowlist clients that connect to backup MX addresses. Fail
* "closed" on error.
*/
if (addr_match_list_match(psc_wlist_if, smtp_server_addr->buf) == 0) {

View File

@ -156,7 +156,7 @@ typedef struct {
#define PSC_STATE_FLAG_SHIFT_BYFNAME(fname) (PSC_STATE_FLAG_SHIFT_ ## fname)
/*
* Indexable per-test flags. These are used for DNS whitelisting multiple
* Indexable per-test flags. These are used for DNS allowlisting multiple
* tests, without needing per-test ad-hoc code.
*/
#define PSC_STATE_FLAG_BYTINDX_FNAME(tindx, fname) \

View File

@ -150,7 +150,7 @@ typedef struct {
typedef struct {
const char *dnsbl_name; /* DNSBL with largest contribution */
int dnsbl_weight; /* weight of largest contribution */
int total; /* combined white+blocklist score */
int total; /* combined allow+denylist score */
int fail_ttl; /* combined reply TTL */
int pass_ttl; /* combined reply TTL */
int refcount; /* score reference count */
@ -239,7 +239,7 @@ static void psc_dnsbl_add_site(const char *site)
*/
#define DO_GRIPE 1
/* Negative weight means whitelist. */
/* Negative weight means allowlist. */
if ((weight_text = split_at(saved_site, '*')) != 0) {
if (sscanf(weight_text, "%d%c", &weight, &junk) != 1)
msg_fatal("bad DNSBL weight factor \"%s\" in \"%s\"",

View File

@ -56,22 +56,22 @@
static char *psc_teaser_greeting;
static VSTRING *psc_escape_buf;
/* psc_whitelist_non_dnsbl - whitelist pending non-dnsbl tests */
/* psc_allowlist_non_dnsbl - allowlist pending non-dnsbl tests */
static void psc_whitelist_non_dnsbl(PSC_STATE *state)
static void psc_allowlist_non_dnsbl(PSC_STATE *state)
{
time_t now;
int tindx;
/*
* If no tests failed (we can't undo those), and if the whitelist
* If no tests failed (we can't undo those), and if the allowlist
* threshold is met, flag non-dnsbl tests that are pending or disabled as
* successfully completed, and set their expiration times equal to the
* DNSBL expiration time, except for tests that would expire later.
*
* Why flag disabled tests as passed? When a disabled test is turned on,
* postscreen should not apply that test to clients that are already
* whitelisted based on their combined DNSBL score.
* allowlisted based on their combined DNSBL score.
*/
if ((state->flags & PSC_STATE_MASK_ANY_FAIL) == 0
&& state->dnsbl_score < var_psc_dnsbl_thresh
@ -154,7 +154,7 @@ static void psc_early_event(int event, void *context)
}
/*
* Collect the DNSBL score, and whitelist other tests if applicable.
* Collect the DNSBL score, and allowlist other tests if applicable.
* Note: this score will be partial when some DNS lookup did not
* complete before the pregreet timer expired.
*
@ -173,7 +173,7 @@ static void psc_early_event(int event, void *context)
state->dnsbl_index,
&state->dnsbl_ttl);
if (var_psc_dnsbl_wthresh < 0)
psc_whitelist_non_dnsbl(state);
psc_allowlist_non_dnsbl(state);
}
if (state->dnsbl_score < var_psc_dnsbl_thresh) {
expire_time[PSC_TINDX_DNSBL] = event_time() + state->dnsbl_ttl;
@ -303,13 +303,13 @@ static void psc_early_dnsbl_event(int unused_event, void *context)
msg_info("%s: notify [%s]:%s", myname, PSC_CLIENT_ADDR_PORT(state));
/*
* Collect the DNSBL score, and whitelist other tests if applicable.
* Collect the DNSBL score, and allowlist other tests if applicable.
*/
state->dnsbl_score =
psc_dnsbl_retrieve(state->smtp_client_addr, &state->dnsbl_name,
state->dnsbl_index, &state->dnsbl_ttl);
if (var_psc_dnsbl_wthresh < 0)
psc_whitelist_non_dnsbl(state);
psc_allowlist_non_dnsbl(state);
/*
* Terminate the greet delay if we're just waiting for DNSBL lookup to

View File

@ -97,8 +97,8 @@ void psc_conclude(PSC_STATE *state)
/*
* Handle clients that passed at least one test other than permanent
* whitelisting, and that didn't fail any test including permanent
* blacklisting. There may still be unfinished tests; those tests will
* allowlisting, and that didn't fail any test including permanent
* denylisting. There may still be unfinished tests; those tests will
* need to be completed when the client returns in a later session.
*/
if (state->flags & PSC_STATE_MASK_ANY_FAIL)
@ -116,7 +116,7 @@ void psc_conclude(PSC_STATE *state)
/*
* Update the postscreen cache. This still supports a scenario where a
* client gets whitelisted in the course of multiple sessions, as long as
* client gets allowlisted in the course of multiple sessions, as long as
* that client does not "fail" any test. Don't try to optimize away cache
* updates; we want cached information to be up-to-date even if a test
* result is renewed during overlapping SMTP sessions, and even if

View File

@ -40,7 +40,7 @@
/* at any stage.
/*
/* No support is announced for AUTH, XCLIENT or XFORWARD.
/* Clients that need this should be whitelisted or should talk
/* Clients that need this should be allowlisted or should talk
/* directly to the submission service.
/*
/* The engine rejects RCPT TO and VRFY commands with the
@ -902,7 +902,7 @@ static void psc_smtpd_read_event(int event, void *context)
case PSC_ACT_IGNORE:
PSC_UNFAIL_SESSION_STATE(state,
PSC_STATE_FLAG_BARLF_FAIL);
/* Temporarily whitelist until something expires. */
/* Temporarily allowlist until something expires. */
PSC_PASS_SESSION_STATE(state, "bare newline test",
PSC_STATE_FLAG_BARLF_PASS);
expire_time[PSC_TINDX_BARLF] = event_time() + psc_min_ttl;
@ -1028,7 +1028,7 @@ static void psc_smtpd_read_event(int event, void *context)
case PSC_ACT_IGNORE:
PSC_UNFAIL_SESSION_STATE(state,
PSC_STATE_FLAG_NSMTP_FAIL);
/* Temporarily whitelist until something else expires. */
/* Temporarily allowlist until something else expires. */
PSC_PASS_SESSION_STATE(state, "non-smtp test",
PSC_STATE_FLAG_NSMTP_PASS);
expire_time[PSC_TINDX_NSMTP] = event_time() + psc_min_ttl;
@ -1066,7 +1066,7 @@ static void psc_smtpd_read_event(int event, void *context)
case PSC_ACT_IGNORE:
PSC_UNFAIL_SESSION_STATE(state,
PSC_STATE_FLAG_PIPEL_FAIL);
/* Temporarily whitelist until something else expires. */
/* Temporarily allowlist until something else expires. */
PSC_PASS_SESSION_STATE(state, "pipelining test",
PSC_STATE_FLAG_PIPEL_PASS);
expire_time[PSC_TINDX_PIPEL] = event_time() + psc_min_ttl;

View File

@ -259,7 +259,7 @@ void psc_todo_tests(PSC_STATE *state, time_t time_value)
* enabled pre-handshake tests when any pre-handshake test is turned on.
*
* XXX Don't enable PREGREET gratuitously before the test expires. With a
* short TTL for DNSBL whitelisting, turning on PREGREET would force a
* short TTL for DNSBL allowlisting, turning on PREGREET would force a
* full postscreen_greet_wait too frequently.
*/
#if 0

View File

@ -719,7 +719,7 @@ static void post_jail_init(char *service_name, char **unused_argv)
&& htable_locate(proxy_auth_maps, type_name) == 0) {
(void) htable_enter(proxy_auth_maps, type_name, (void *) 0);
if (msg_verbose)
msg_info("whitelisting %s from %s", type_name,
msg_info("allowlisting %s from %s", type_name,
PROXY_MAP_PARAM_NAME(proxy_writer));
}
}

View File

@ -6035,7 +6035,7 @@ static void pre_jail_init(char *unused_name, char **unused_argv)
{
/*
* Initialize blacklist/etc. patterns before entering the chroot jail, in
* Initialize denylist/etc. patterns before entering the chroot jail, in
* case they specify a filename pattern.
*/
smtpd_noop_cmds = string_list_init(VAR_SMTPD_NOOP_CMDS, MATCH_FLAG_RETURN,

View File

@ -397,7 +397,7 @@ static STRING_LIST *smtpd_acl_perm_log;
* restriction must defer immediately when lookup fails, otherwise incorrect
* results happen with:
*
* reject_unknown_client, hostname-based white-list, reject
* reject_unknown_client, hostname-based allow-list, reject
*
* XXX With warn_if_reject, don't raise the defer_if_permit flag when a
* reject-style restriction fails. Instead, log the warning for the
@ -3678,7 +3678,7 @@ static const SMTPD_RBL_STATE *find_dnsxl_addr(SMTPD_STATE *state,
return (rbl);
}
/* reject_rbl_addr - reject address in real-time blackhole list */
/* reject_rbl_addr - reject address in DNS deny list */
static int reject_rbl_addr(SMTPD_STATE *state, const char *rbl_domain,
const char *addr, const char *reply_class)
@ -3708,7 +3708,7 @@ static int permit_dnswl_addr(SMTPD_STATE *state, const char *dnswl_domain,
if (msg_verbose)
msg_info("%s: %s", myname, addr);
/* Safety: don't whitelist unauthorized recipients. */
/* Safety: don't allowlist unauthorized recipients. */
if (strcmp(state->where, SMTPD_CMD_RCPT) == 0 && state->recipient != 0
&& permit_auth_destination(state, state->recipient) != SMTPD_CHECK_OK)
return (SMTPD_CHECK_DUNNO);
@ -3732,7 +3732,7 @@ static int permit_dnswl_addr(SMTPD_STATE *state, const char *dnswl_domain,
}
}
/* find_dnsxl_domain - reject if domain in real-time blackhole list */
/* find_dnsxl_domain - reject if domain in DNS deny list */
static const SMTPD_RBL_STATE *find_dnsxl_domain(SMTPD_STATE *state,
const char *rbl_domain, const char *what)
@ -3797,7 +3797,7 @@ static const SMTPD_RBL_STATE *find_dnsxl_domain(SMTPD_STATE *state,
return (rbl);
}
/* reject_rbl_domain - reject if domain in real-time blackhole list */
/* reject_rbl_domain - reject if domain in DNS deny list */
static int reject_rbl_domain(SMTPD_STATE *state, const char *rbl_domain,
const char *what, const char *reply_class)
@ -3827,7 +3827,7 @@ static int permit_dnswl_domain(SMTPD_STATE *state, const char *dnswl_domain,
if (msg_verbose)
msg_info("%s: %s", myname, what);
/* Safety: don't whitelist unauthorized recipients. */
/* Safety: don't allowlist unauthorized recipients. */
if (strcmp(state->where, SMTPD_CMD_RCPT) == 0 && state->recipient != 0
&& permit_auth_destination(state, state->recipient) != SMTPD_CHECK_OK)
return (SMTPD_CHECK_DUNNO);
@ -3851,7 +3851,7 @@ static int permit_dnswl_domain(SMTPD_STATE *state, const char *dnswl_domain,
}
}
/* reject_maps_rbl - reject if client address in real-time blackhole list */
/* reject_maps_rbl - reject if client address in DNS deny list */
static int reject_maps_rbl(SMTPD_STATE *state)
{
@ -4171,9 +4171,9 @@ static int is_map_command(SMTPD_STATE *state, const char *name,
}
}
/* forbid_whitelist - disallow whitelisting */
/* forbid_allowlist - disallow allowlisting */
static void forbid_whitelist(SMTPD_STATE *state, const char *name,
static void forbid_allowlist(SMTPD_STATE *state, const char *name,
int status, const char *target)
{
if (state->discard == 0 && status == SMTPD_CHECK_OK) {
@ -4318,7 +4318,7 @@ static int generic_checks(SMTPD_STATE *state, ARGV *restrictions,
status = check_namadr_access(state, *cpp, state->reverse_name, state->addr,
FULL, &found, state->reverse_name,
SMTPD_NAME_REV_CLIENT, def_acl);
forbid_whitelist(state, name, status, state->reverse_name);
forbid_allowlist(state, name, status, state->reverse_name);
} else if (strcasecmp(name, REJECT_MAPS_RBL) == 0) {
status = reject_maps_rbl(state);
} else if (strcasecmp(name, REJECT_RBL_CLIENT) == 0
@ -4387,42 +4387,42 @@ static int generic_checks(SMTPD_STATE *state, ARGV *restrictions,
status = check_server_access(state, *cpp, state->name,
T_NS, state->namaddr,
SMTPD_NAME_CLIENT, def_acl);
forbid_whitelist(state, name, status, state->name);
forbid_allowlist(state, name, status, state->name);
}
} else if (is_map_command(state, name, CHECK_CLIENT_MX_ACL, &cpp)) {
if (strcasecmp(state->name, "unknown") != 0) {
status = check_server_access(state, *cpp, state->name,
T_MX, state->namaddr,
SMTPD_NAME_CLIENT, def_acl);
forbid_whitelist(state, name, status, state->name);
forbid_allowlist(state, name, status, state->name);
}
} else if (is_map_command(state, name, CHECK_CLIENT_A_ACL, &cpp)) {
if (strcasecmp(state->name, "unknown") != 0) {
status = check_server_access(state, *cpp, state->name,
T_A, state->namaddr,
SMTPD_NAME_CLIENT, def_acl);
forbid_whitelist(state, name, status, state->name);
forbid_allowlist(state, name, status, state->name);
}
} else if (is_map_command(state, name, CHECK_REVERSE_CLIENT_NS_ACL, &cpp)) {
if (strcasecmp(state->reverse_name, "unknown") != 0) {
status = check_server_access(state, *cpp, state->reverse_name,
T_NS, state->reverse_name,
SMTPD_NAME_REV_CLIENT, def_acl);
forbid_whitelist(state, name, status, state->reverse_name);
forbid_allowlist(state, name, status, state->reverse_name);
}
} else if (is_map_command(state, name, CHECK_REVERSE_CLIENT_MX_ACL, &cpp)) {
if (strcasecmp(state->reverse_name, "unknown") != 0) {
status = check_server_access(state, *cpp, state->reverse_name,
T_MX, state->reverse_name,
SMTPD_NAME_REV_CLIENT, def_acl);
forbid_whitelist(state, name, status, state->reverse_name);
forbid_allowlist(state, name, status, state->reverse_name);
}
} else if (is_map_command(state, name, CHECK_REVERSE_CLIENT_A_ACL, &cpp)) {
if (strcasecmp(state->reverse_name, "unknown") != 0) {
status = check_server_access(state, *cpp, state->reverse_name,
T_A, state->reverse_name,
SMTPD_NAME_REV_CLIENT, def_acl);
forbid_whitelist(state, name, status, state->reverse_name);
forbid_allowlist(state, name, status, state->reverse_name);
}
}
@ -4469,21 +4469,21 @@ static int generic_checks(SMTPD_STATE *state, ARGV *restrictions,
status = check_server_access(state, *cpp, state->helo_name,
T_NS, state->helo_name,
SMTPD_NAME_HELO, def_acl);
forbid_whitelist(state, name, status, state->helo_name);
forbid_allowlist(state, name, status, state->helo_name);
}
} else if (is_map_command(state, name, CHECK_HELO_MX_ACL, &cpp)) {
if (state->helo_name) {
status = check_server_access(state, *cpp, state->helo_name,
T_MX, state->helo_name,
SMTPD_NAME_HELO, def_acl);
forbid_whitelist(state, name, status, state->helo_name);
forbid_allowlist(state, name, status, state->helo_name);
}
} else if (is_map_command(state, name, CHECK_HELO_A_ACL, &cpp)) {
if (state->helo_name) {
status = check_server_access(state, *cpp, state->helo_name,
T_A, state->helo_name,
SMTPD_NAME_HELO, def_acl);
forbid_whitelist(state, name, status, state->helo_name);
forbid_allowlist(state, name, status, state->helo_name);
}
} else if (strcasecmp(name, REJECT_NON_FQDN_HELO_HOSTNAME) == 0
|| strcasecmp(name, REJECT_NON_FQDN_HOSTNAME) == 0) {
@ -4573,21 +4573,21 @@ static int generic_checks(SMTPD_STATE *state, ARGV *restrictions,
status = check_server_access(state, *cpp, state->sender,
T_NS, state->sender,
SMTPD_NAME_SENDER, def_acl);
forbid_whitelist(state, name, status, state->sender);
forbid_allowlist(state, name, status, state->sender);
}
} else if (is_map_command(state, name, CHECK_SENDER_MX_ACL, &cpp)) {
if (state->sender && *state->sender) {
status = check_server_access(state, *cpp, state->sender,
T_MX, state->sender,
SMTPD_NAME_SENDER, def_acl);
forbid_whitelist(state, name, status, state->sender);
forbid_allowlist(state, name, status, state->sender);
}
} else if (is_map_command(state, name, CHECK_SENDER_A_ACL, &cpp)) {
if (state->sender && *state->sender) {
status = check_server_access(state, *cpp, state->sender,
T_A, state->sender,
SMTPD_NAME_SENDER, def_acl);
forbid_whitelist(state, name, status, state->sender);
forbid_allowlist(state, name, status, state->sender);
}
} else if (strcasecmp(name, REJECT_RHSBL_SENDER) == 0) {
if (cpp[1] == 0)
@ -4677,21 +4677,21 @@ static int generic_checks(SMTPD_STATE *state, ARGV *restrictions,
status = check_server_access(state, *cpp, state->recipient,
T_NS, state->recipient,
SMTPD_NAME_RECIPIENT, def_acl);
forbid_whitelist(state, name, status, state->recipient);
forbid_allowlist(state, name, status, state->recipient);
}
} else if (is_map_command(state, name, CHECK_RECIP_MX_ACL, &cpp)) {
if (state->recipient && *state->recipient) {
status = check_server_access(state, *cpp, state->recipient,
T_MX, state->recipient,
SMTPD_NAME_RECIPIENT, def_acl);
forbid_whitelist(state, name, status, state->recipient);
forbid_allowlist(state, name, status, state->recipient);
}
} else if (is_map_command(state, name, CHECK_RECIP_A_ACL, &cpp)) {
if (state->recipient && *state->recipient) {
status = check_server_access(state, *cpp, state->recipient,
T_A, state->recipient,
SMTPD_NAME_RECIPIENT, def_acl);
forbid_whitelist(state, name, status, state->recipient);
forbid_allowlist(state, name, status, state->recipient);
}
} else if (strcasecmp(name, REJECT_RHSBL_RECIPIENT) == 0) {
if (cpp[1] == 0)

View File

@ -12,15 +12,15 @@ helo foobar
# DNSWL (by IP address)
#
# Whitelist overrides reject.
# Allowlist overrides reject.
client_restrictions permit_dnswl_client,wild.porcupine.org,reject
client spike.porcupine.org 168.100.189.2
# Whitelist does not fire - reject.
# Allowlist does not fire - reject.
client_restrictions permit_dnswl_client,porcupine.org,reject
client spike.porcupine.org 168.100.189.2
# Whitelist does not override reject_unauth_destination.
# Allowlist does not override reject_unauth_destination.
client_restrictions permit
recipient_restrictions permit_dnswl_client,wild.porcupine.org,reject_unauth_destination
# Unauthorized destination - reject.
@ -32,23 +32,23 @@ rcpt wietse@porcupine.org
# RHSWL (by domain name)
#
# Whitelist overrides reject.
# Allowlist overrides reject.
client_restrictions permit_rhswl_client,dnswl.porcupine.org,reject
# Non-whitelisted client name - reject.
# Non-allowlisted client name - reject.
client spike.porcupine.org 168.100.189.2
# Whitelisted client name - accept.
# Allowlisted client name - accept.
client example.tld 168.100.189.2
# Whitelist does not override reject_unauth_destination.
# Allowlist does not override reject_unauth_destination.
client_restrictions permit
recipient_restrictions permit_rhswl_client,dnswl.porcupine.org,reject_unauth_destination
# Non-whitelisted client name.
# Non-allowlisted client name.
client spike.porcupine.org 168.100.189.2
# Unauthorized destination - reject.
rcpt rname@rdomain
# Authorized destination - accept.
rcpt wietse@porcupine.org
# Whitelisted client name.
# Allowlisted client name.
client example.tld 168.100.189.2
# Unauthorized destination - reject.
rcpt rname@rdomain

View File

@ -17,20 +17,20 @@ OK
>>> # DNSWL (by IP address)
>>> #
>>>
>>> # Whitelist overrides reject.
>>> # Allowlist overrides reject.
>>> client_restrictions permit_dnswl_client,wild.porcupine.org,reject
OK
>>> client spike.porcupine.org 168.100.189.2
OK
>>>
>>> # Whitelist does not fire - reject.
>>> # Allowlist does not fire - reject.
>>> client_restrictions permit_dnswl_client,porcupine.org,reject
OK
>>> client spike.porcupine.org 168.100.189.2
./smtpd_check: <queue id>: reject: CONNECT from spike.porcupine.org[168.100.189.2]: 554 5.7.1 <spike.porcupine.org[168.100.189.2]>: Client host rejected: Access denied; proto=SMTP helo=<foobar>
554 5.7.1 <spike.porcupine.org[168.100.189.2]>: Client host rejected: Access denied
>>>
>>> # Whitelist does not override reject_unauth_destination.
>>> # Allowlist does not override reject_unauth_destination.
>>> client_restrictions permit
OK
>>> recipient_restrictions permit_dnswl_client,wild.porcupine.org,reject_unauth_destination
@ -47,23 +47,23 @@ OK
>>> # RHSWL (by domain name)
>>> #
>>>
>>> # Whitelist overrides reject.
>>> # Allowlist overrides reject.
>>> client_restrictions permit_rhswl_client,dnswl.porcupine.org,reject
OK
>>> # Non-whitelisted client name - reject.
>>> # Non-allowlisted client name - reject.
>>> client spike.porcupine.org 168.100.189.2
./smtpd_check: <queue id>: reject: CONNECT from spike.porcupine.org[168.100.189.2]: 554 5.7.1 <spike.porcupine.org[168.100.189.2]>: Client host rejected: Access denied; proto=SMTP helo=<foobar>
554 5.7.1 <spike.porcupine.org[168.100.189.2]>: Client host rejected: Access denied
>>> # Whitelisted client name - accept.
>>> # Allowlisted client name - accept.
>>> client example.tld 168.100.189.2
OK
>>>
>>> # Whitelist does not override reject_unauth_destination.
>>> # Allowlist does not override reject_unauth_destination.
>>> client_restrictions permit
OK
>>> recipient_restrictions permit_rhswl_client,dnswl.porcupine.org,reject_unauth_destination
OK
>>> # Non-whitelisted client name.
>>> # Non-allowlisted client name.
>>> client spike.porcupine.org 168.100.189.2
OK
>>> # Unauthorized destination - reject.
@ -73,7 +73,7 @@ OK
>>> # Authorized destination - accept.
>>> rcpt wietse@porcupine.org
OK
>>> # Whitelisted client name.
>>> # Allowlisted client name.
>>> client example.tld 168.100.189.2
OK
>>> # Unauthorized destination - reject.

View File

@ -8,8 +8,8 @@
/* DESCRIPTION
/* The \fBtlsproxy\fR(8) server implements a two-way TLS proxy. It
/* is used by the \fBpostscreen\fR(8) server to talk SMTP-over-TLS
/* with remote SMTP clients that are not whitelisted (including
/* clients whose whitelist status has expired), and by the
/* with remote SMTP clients that are not allowlisted (including
/* clients whose allowlist status has expired), and by the
/* \fBsmtp\fR(8) client to support TLS connection reuse, but it
/* should also work for non-SMTP protocols.
/*
@ -1065,7 +1065,7 @@ static int tlsp_server_start_pre_handshake(TLSP_STATE *state)
/*
* XXX Do we care about TLS session rate limits? Good postscreen(8)
* clients will occasionally require the tlsproxy to renew their
* whitelist status, but bad clients hammering the server can suck up
* allowlist status, but bad clients hammering the server can suck up
* lots of CPU cycles. Per-client concurrency limits in postscreen(8)
* will divert only naive security "researchers".
*/

View File

@ -64,7 +64,7 @@
/* 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.
/* denylisted by some providers.
/*
/* If the persistent database ever gets corrupted then the world
/* comes to an end and human intervention is needed. This violates