23
23
Postfix SMTP server processes remain available for legitimate
26
<p> postscreen(8) maintains a temporary whitelist for clients that
27
pass its tests; by allowing whitelisted clients to skip tests,
28
postscreen(8) minimizes its impact on legitimate email traffic.
26
31
<p> postscreen(8) should not be used on SMTP ports that receive
27
32
mail from end-user clients (MUAs). In a typical deployment,
28
33
postscreen(8) is used on the "port 25" service, while MUA clients
29
submit mail via the submission service. </p>
34
submit mail via the submission service (port 587) which normally
35
requires client authentication, or via a "port 25" server that
36
provides no MX service (i.e. a dedicated server that provides
37
submission service on port 25). </p>
31
39
<p> postscreen(8) is part of a multi-layer defense. <p>
55
63
<p> Each layer reduces the spam volume. The general strategy is to
56
64
use the less expensive defenses first, and to use the more expensive
57
defenses for the spam that remains. </p>
65
defenses only for the spam that remains. </p>
59
67
<p> Topics in this document: </p>
93
101
<p> The main challenge for postscreen(8) is to make an is-it-a-zombie
94
102
decision based on a single measurement. This is necessary because
95
many zombies avoid spamming the same site repeatedly, in an attempt
96
to fly under the radar. Once postscreen(8) decides that a client
97
is not-a-zombie, it whitelists the client temporarily to avoid
98
further delays for legitimate mail. </p>
103
many zombies try to fly under the radar and avoid spamming the same
104
site repeatedly. Once postscreen(8) decides that a client is
105
not-a-zombie, it whitelists the client temporarily to avoid further
106
delays for legitimate mail. </p>
100
108
<p> Zombies have challenges too: they have only a limited amount
101
109
of time to deliver spam before their IP address becomes blacklisted.
122
130
<p> The postscreen(8) triage process involves a number of tests,
123
131
in the order as described below. Some tests introduce a delay of
124
a few seconds. Once a client passes a test, its IP address is
125
whitelisted from 24 hours for simple tests, to 1 week for complex
126
tests. Whitelisting minimizes the impact of postscreen(8)'s tests
127
on legitimate mail clients. </p>
132
a few seconds. postscreen(8) maintains a temporary whitelist for
133
clients that pass its tests; by allowing whitelisted clients to
134
skip tests, postscreen(8) minimizes its impact on legitimate email
129
<p> After logging its findings, postscreen(8) by default hands off
130
all connections to a Postfix SMTP server process. This mode is
131
useful for non-destructive testing. </p>
137
<p> By default, postscreen(8) hands off all connections to a Postfix
138
SMTP server process after logging its findings. This mode is useful
139
for non-destructive testing. </p>
133
141
<p> In a typical production setting, postscreen(8) is configured
134
142
to reject mail from clients that fail one or more tests, after
206
216
the tests described below. The postscreen_cache_map parameter
207
217
specifies the location of the temporary whitelist. The
208
218
temporary whitelist is not used for SMTP client addresses
209
that appear on the <i>permanent</i> blacklist or whitelist. </p>
219
that appear on the <i>permanent</i> access list. </p>
221
<blockquote> <p> NOTE: To share a postscreen(8) cache between
222
multiple postscreen(8) instances, use "<tt>postscreen_cache_map =
223
proxy:btree:$data_directory/postscreen_cache</tt>", and disable
224
cache cleanup (postscreen_cache_cleanup_interval = 0) in all
225
postscreen(8) instances except one that is responsible for cache
226
cleanup. </p> <p> postscreen(8) cache sharing requires Postfix 2.9
227
or later; earlier proxymap(8) implementations don't support cache
228
cleanup. </p> <p> For an alternative postscreen(8) cache sharing
229
approach see the memcache_table(5) manpage. </p> </blockquote>
211
231
<p> When the SMTP client address appears on the temporary
212
232
whitelist, postscreen(8) logs this with the client address and port
222
242
entry expires, as controlled with the postscreen_*_ttl
223
243
parameters. Expired entries are silently renewed if possible. </p>
245
<h3> <a name="white_veto"> MX Policy test </a> </h3>
247
<p> When the remote SMTP client is not on the static access list
248
or temporary whitelist, postscreen(8) can implement a number of
249
whitelist tests, before it grants the client a temporary whitelist
250
status that allows it to talk to a Postfix SMTP server process. </p>
252
<p> By listening on both primary and backup MX addresses, postscreen(8)
253
can deny the temporary whitelist status to clients that connect
254
only to backup MX hosts (an old spammer trick to take advantage of
255
backup MX hosts with weaker anti-spam policies than primary MX
260
<li> <p> First, configure the host to listen on both primary and
261
backup MX addresses. Use the appropriate <tt>ifconfig</tt> command
262
for the local operating system, or update the appropriate configuration
263
files and "refresh" the network protocol stack. </p>
265
<li> <p> Then, configure postscreen(8) to deny the temporary whitelist
266
status on the backup MX address(es). An example for Wietse's
270
/etc/postfix/main.cf:
271
postscreen_whitelist_interfaces = !168.100.189.8 static:all
274
<p> Translation: allow clients to obtain the temporary whitelist
275
status on all server IP addresses except 168.100.189.8, which is a
276
backup MX address. </p>
280
<p> When a non-whitelisted client connects the backup MX address,
281
postscreen(8) logs this with the client address and port number as:
285
<b>CONNECT from</b> <i>[address]:port</i> <b>to [168.100.189.8]:25</b>
286
<b>WHITELIST VETO</b> <i>[address]:port</i>
289
<p> Translation: the client at <i>[address]:port</i> connected to
290
the backup MX address 168.100.189.8 while it was not whitelisted.
291
The client will not be granted the temporary whitelist status, even
292
if passes all the whitelist tests described below. </p>
225
294
<h2> <a name="before_220"> Tests before the 220 SMTP server greeting </a> </h2>
227
296
<p> The postscreen_greet_wait parameter specifies a short time
435
<b>COMMAND PIPELINING from</b> <i>[address]:port</i> <b>after</b> <i>command</i>
504
<b>COMMAND PIPELINING from</b> <i>[address]:port</i> <b>after</b> <i>command</i>: <i>text</i>
438
507
<p> Translation: the SMTP client at <i>[address]:port</i> sent
439
508
multiple SMTP commands, instead of sending one command and then
440
509
waiting for the server to reply. This happened after the client
441
sent <i>command</i>. Postfix 2.8 does not log the input that was
510
sent <i>command</i>. The <i>text</i> shows part of the input that
511
was sent too early; it is not logged with Postfix 2.8. </p>
444
513
<p> The postscreen_pipelining_action parameter specifies the action
445
514
that is taken next. See "<a href="#fail_after_220">When tests fail
549
618
<h2> <a name="other_error">Other errors</a> </h2>
551
<p> When an SMTP client hangs up unexpectedly during any tests,
552
postscreen(8) logs this as: </p>
620
<p> When an SMTP client hangs up unexpectedly, postscreen(8) logs
555
624
<b>HANGUP after</b> <i>time</i> <b>from</b> <i>[address]:port</i> <b>in</b> <i>test name</i>
559
628
unexpectedly, <i>time</i> seconds after the start of the
560
629
test named <i>test name</i>. </p>
631
<p> There is no punishment for hanging up. A client that hangs up
632
without sending the QUIT command can still pass all postscreen(8)
564
637
<p> While an unexpired penalty is in effect, an SMTP client is not
780
853
<li> <p> Some postscreen(8) configuration parameters implement
781
854
stress-dependent behavior. This is supported only when the default
782
value is stress-dependent (that is, it looks like ${stress?X}${stress:Y}).
855
value is stress-dependent (that is, "postconf -d <i>parametername</i>"
856
output shows "<i>parametername</i> =
857
${stress?<i>something</i>}${stress:<i>something</i>}").
783
858
Other parameters always evaluate as if the stress value is the empty
added
removed
proto/POSTSCREEN_README.html
