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.
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.
W\bWh\bha\bat\bt P\bPo\bos\bst\btf\bfi\bix\bx a\bad\bdd\bdr\bre\bes\bss\bs v\bve\ber\bri\bif\bfi\bic\bca\bat\bti\bio\bon\bn c\bca\ban\bn d\bdo\bo f\bfo\bor\br y\byo\bou\bu
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
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.
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.
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.
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.
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
Q\bQu\bui\bic\bck\bk t\bte\bes\bst\bts\bs b\bbe\bef\bfo\bor\bre\be e\bev\bve\ber\bry\byt\bth\bhi\bin\bng\bg e\bel\bls\bse\be
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
-P\bPe\ber\brm\bma\ban\bne\ben\bnt\bt w\bwh\bhi\bit\bte\be/\b/b\bbl\bla\bac\bck\bkl\bli\bis\bst\bt t\bte\bes\bst\bt
+P\bPe\ber\brm\bma\ban\bne\ben\bnt\bt a\bal\bll\blo\bow\bw/\b/d\bde\ben\bny\byl\bli\bis\bst\bt t\bte\bes\bst\bt
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:
/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
W\bWH\bHI\bIT\bTE\bEL\bLI\bIS\bST\bTE\bED\bD [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
The postscreen_blacklist_action parameter specifies the action that is taken
next. See "When tests fail before the 220 SMTP server greeting" below.
-T\bTe\bem\bmp\bpo\bor\bra\bar\bry\by w\bwh\bhi\bit\bte\bel\bli\bis\bst\bt t\bte\bes\bst\bt
+T\bTe\bem\bmp\bpo\bor\bra\bar\bry\by a\bal\bll\blo\bow\bwl\bli\bis\bst\bt t\bte\bes\bst\bt
-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:
P\bPA\bAS\bSS\bS O\bOL\bLD\bD [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.
M\bMX\bX P\bPo\bol\bli\bic\bcy\by t\bte\bes\bst\bt
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).
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:
C\bCO\bON\bNN\bNE\bEC\bCT\bT f\bfr\bro\bom\bm [address]:port t\bto\bo [\b[1\b16\b68\b8.\b.1\b10\b00\b0.\b.1\b18\b89\b9.\b.8\b8]\b]:\b:2\b25\b5
W\bWH\bHI\bIT\bTE\bEL\bLI\bIS\bST\bT V\bVE\bET\bTO\bO [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.
T\bTe\bes\bst\bts\bs b\bbe\bef\bfo\bor\bre\be t\bth\bhe\be 2\b22\b20\b0 S\bSM\bMT\bTP\bP s\bse\ber\brv\bve\ber\br g\bgr\bre\bee\bet\bti\bin\bng\bg
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
P\bPr\bre\beg\bgr\bre\bee\bet\bt t\bte\bes\bst\bt
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
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
The postscreen_greet_action parameter specifies the action that is taken next.
See "When tests fail before the 220 SMTP server greeting" below.
-D\bDN\bNS\bS W\bWh\bhi\bit\bte\be/\b/b\bbl\bla\bac\bck\bkl\bli\bis\bst\bt t\bte\bes\bst\bt
+D\bDN\bNS\bS A\bAl\bll\blo\bow\bw/\b/d\bde\ben\bny\byl\bli\bis\bst\bt t\bte\bes\bst\bt
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
W\bWh\bhe\ben\bn t\bte\bes\bst\bts\bs f\bfa\bai\bil\bl b\bbe\bef\bfo\bor\bre\be t\bth\bhe\be 2\b22\b20\b0 S\bSM\bMT\bTP\bP s\bse\ber\brv\bve\ber\br g\bgr\bre\bee\bet\bti\bin\bng\bg
-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.
W\bWh\bhe\ben\bn a\bal\bll\bl t\bte\bes\bst\bts\bs s\bsu\buc\bcc\bce\bee\bed\bd
-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:
P\bPA\bAS\bSS\bS N\bNE\bEW\bW [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
* postscreen(8) TLS configuration
* Blocking mail with postscreen(8)
* Turning off postscreen(8)
- * Sharing the temporary whitelist
+ * Sharing the temporary allowlist
T\bTu\bur\brn\bni\bin\bng\bg o\bon\bn p\bpo\bos\bst\bts\bsc\bcr\bre\bee\ben\bn(\b(8\b8)\b) w\bwi\bit\bth\bho\bou\but\bt b\bbl\blo\boc\bck\bki\bin\bng\bg m\bma\bai\bil\bl
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
p\bpo\bos\bst\bts\bsc\bcr\bre\bee\ben\bn(\b(8\b8)\b) T\bTL\bLS\bS c\bco\bon\bnf\bfi\big\bgu\bur\bra\bat\bti\bio\bon\bn
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
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
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.
T\bTu\bur\brn\bni\bin\bng\bg o\bof\bff\bf p\bpo\bos\bst\bts\bsc\bcr\bre\bee\ben\bn(\b(8\b8)\b)
6. Read the new configuration with "postfix reload".
-S\bSh\bha\bar\bri\bin\bng\bg t\bth\bhe\be t\bte\bem\bmp\bpo\bor\bra\bar\bry\by w\bwh\bhi\bit\bte\bel\bli\bis\bst\bt
+S\bSh\bha\bar\bri\bin\bng\bg t\bth\bhe\be t\bte\bem\bmp\bpo\bor\bra\bar\bry\by a\bal\bll\blo\bow\bwl\bli\bis\bst\bt
-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
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 =
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.
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
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.
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
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:
$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
# 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";
}
}
#
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";
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
<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>
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
<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
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>
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>
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
<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>
<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>
<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>
/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>
<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,
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>
<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>
(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>
<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>
</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>
<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>
<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>
<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
<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>
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>
<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>
<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>
<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
<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>
<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
<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
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
<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
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>
</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
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
</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
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> =
</body>
</html>
-
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
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
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
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
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>
$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
# 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";
}
}
#
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";
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,
<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
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>.
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>
<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>
<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>
(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>
</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
<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
<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.
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>
<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>
(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>
(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>
<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
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.
</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>
<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>
(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>
<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>
<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>
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>
<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>
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>
<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>
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>
<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>
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>
";"-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>
<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>
<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
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
<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
<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>
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>
<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>
<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>
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>
<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>
<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
<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
"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.
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
<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
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>
<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
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.
<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
<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.
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
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
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
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"
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.
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:.)
.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
.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.
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
.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
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
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.
.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
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.
.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.
.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.
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,
.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
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"
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"
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"
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"
.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"
"\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"
.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
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
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
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
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"
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"
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"
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"
.SH NAME
dnsblog
\-
-Postfix DNS white/blacklist logger
+Postfix DNS allow/denylist logger
.SH "SYNOPSIS"
.na
.nf
.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"
.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.
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
"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.
.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
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
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
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.
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.
.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"
.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.
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
<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>
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
<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
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>
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>
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
<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>
<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>
<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>
/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>
<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,
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>
<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>
(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>
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>
</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>
<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>
<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>
<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
<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>
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>
<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>
<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>
<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
<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>
<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
<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
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
<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
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>
</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
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
</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
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 =
</body>
</html>
-
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
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
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
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
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>
$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
# 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";
}
}
#
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";
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,
# 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
<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>
<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>
<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>
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>
<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>
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>
<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>
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>
<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>
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>
";"-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>
<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>
<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
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
<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
<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>
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>
<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>
<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>
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>
<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>
</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
%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>
%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>
%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
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.
</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>
%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
<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.
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>
<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>
%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>
%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>
%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>
<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>
#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.
*
/* 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.
/* 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
* 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
/* 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.
/*
/* 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
/* "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.
/*
/* .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
/* 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
/* 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
/* 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.
/* 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.
/* 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
/*
* 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 *,
}
/*
- * 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));
*/
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));
}
/*
- * 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
}
/*
- * 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) {
#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) \
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 */
*/
#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\"",
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
}
/*
- * 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.
*
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;
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
/*
* 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)
/*
* 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
/* 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
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;
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;
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;
* 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
&& 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));
}
}
{
/*
- * 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,
* 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
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)
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);
}
}
-/* 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)
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)
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);
}
}
-/* 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)
{
}
}
-/* 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) {
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
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);
}
}
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) {
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)
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)
# 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.
# 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
>>> # 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
>>> # 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.
>>> # 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.
/* 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.
/*
/*
* 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".
*/
/* 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
projects / thirdparty / postfix.git / commitdiff
