1
<!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN"
2
"http://www.w3.org/TR/html4/loose.dtd">
6
<title>Postfix Postscreen Howto</title>
8
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
14
<h1><img src="postfix-logo.jpg" width="203" height="98" ALT="">Postfix Postscreen Howto</h1>
18
<h2> <a name="intro">Introduction</a> </h2>
20
<p> The Postfix postscreen(8) server performs triage on multiple
21
inbound SMTP connections at the same time. While a single postscreen(8)
22
process keeps zombies away from Postfix SMTP server processes, more
23
Postfix SMTP server processes remain available for legitimate
26
<p> postscreen(8) should not be used on SMTP ports that receive
27
mail from end-user clients (MUAs). In a typical deployment,
28
postscreen(8) is used on the "port 25" service, while MUA clients
29
submit mail via the submission service. </p>
31
<p> postscreen(8) is part of a multi-layer defense. <p>
35
<li> <p> As the first layer, postscreen(8) blocks connections from
36
zombies and other spambots that are responsible for about 90% of
37
all spam. It is implemented as a single process to make this defense
38
as cheap as possible. </p>
40
<li> <p> The second layer implements more complex SMTP-level access
41
checks with Postfix SMTP servers, policy daemons, and Milter
44
<li> <p> The third layer performs light-weight content inspection
45
with the Postfix built-in header_checks and body_checks. This can
46
block unacceptable attachments such as executable programs, and
47
worms or viruses with easy-to-recognize signatures. </p>
49
<li> <p> The fourth layer provides heavy-weight content inspection
50
with external content filters. Typical examples are Amavisd-new,
51
SpamAssassin, and Milter applications. </p>
55
<p> Each layer reduces the spam volume. The general strategy is to
56
use the less expensive defenses first, and to use the more expensive
57
defenses for the spam that remains. </p>
59
<p> Topics in this document: </p>
63
<li> <a href="#intro">Introduction</a>
65
<li> <a href="#basic">The basic idea behind postscreen(8)</a>
67
<li> <a href="#general"> General operation </a>
69
<li> <a href="#quick">Quick tests before everything else</a>
71
<li> <a href="#before_220"> Tests before the 220 SMTP server greeting </a>
73
<li> <a href="#after_220">Tests after the 220 SMTP server greeting</a>
75
<li> <a href="#other_error">Other errors</a>
77
<li> <a href="#victory">When all tests succeed</a>
79
<li> <a href="#config"> Configuring the postscreen(8) service</a>
81
<li> <a href="#historical"> Historical notes and credits </a>
85
<h2> <a name="basic">The basic idea behind postscreen(8)</a> </h2>
87
<p> Most email is spam, and most spam is sent out by zombies (malware
88
on compromised end-user computers). Wietse expects that the zombie
89
problem will get worse before things improve, if ever. Without a
90
tool like postscreen(8) that keeps the zombies away, Postfix would be
91
spending most of its resources not receiving email. </p>
93
<p> The main challenge for postscreen(8) is to make an is-it-a-zombie
94
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>
100
<p> Zombies have challenges too: they have only a limited amount
101
of time to deliver spam before their IP address becomes blacklisted.
102
To speed up spam deliveries, zombies make compromises in their SMTP
103
protocol implementation. For example, they speak before their turn,
104
or they ignore responses from SMTP servers and continue sending
105
mail even when the server tells them to go away. </p>
107
<p> postscreen(8) uses a variety of measurements to recognize
108
zombies. First, postscreen(8) determines if the remote SMTP client
109
IP address is blacklisted. Second, postscreen(8) looks for protocol
110
compromises that are made to speed up delivery. These are good
111
indicators for making is-it-a-zombie decisions based on single
114
<p> postscreen(8) does not inspect message content. Message content
115
can vary from one delivery to the next, especially with clients
116
that (also) send legitimate email. Content is not a good indicator
117
for making is-it-a-zombie decisions based on single measurements,
118
and that is the problem that postscreen(8) is focused on. </p>
120
<h2> <a name="general"> General operation </a> </h2>
122
<p> The postscreen(8) triage process involves a number of tests,
123
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>
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>
133
<p> In a typical production setting, postscreen(8) is configured
134
to reject mail from clients that fail one or more tests, after
135
logging the helo, sender and recipient information. </p>
137
<p> Note: postscreen(8) is not an SMTP proxy; this is intentional.
138
The purpose is to keep zombies away from Postfix, with minimal
139
overhead for legitimate clients. </p>
141
<h2> <a name="quick">Quick tests before everything else</a> </h2>
143
<p> Before engaging in SMTP-level tests. postscreen(8) queries a
144
number of local black and whitelists. These tests speed up the
145
handling of known clients. </p>
149
<li> <a href="#perm_white_black"> Permanent white/blacklist test </a>
151
<li> <a href="#temp_white"> Temporary whitelist test </a>
155
<h3> <a name="perm_white_black"> Permanent white/blacklist test </a> </h3>
157
<p> The postscreen_access_list parameter (default: permit_mynetworks)
158
specifies a permanent access list for SMTP client IP addresses. Typically
159
one would specify something that whitelists local networks, followed
160
by a CIDR table for selective white- and blacklisting. </p>
165
/etc/postfix/main.cf:
166
postscreen_access_list = permit_mynetworks,
167
cidr:/etc/postfix/postscreen_access.cidr
169
/etc/postfix/postscreen_access.cidr:
170
# Rules are evaluated in the order as specified.
171
# Blacklist 192.168.* except 192.168.0.1.
173
192.168.0.0/16 reject
176
<p> See the postscreen_access_list manpage documentation for more
179
<p> When the SMTP client address matches a "permit" action,
180
postscreen(8) logs this with the client address and port number as:
184
<b>WHITELISTED</b> <i>[address]:port</i>
187
<p> The whitelist action is not configurable: immediately hand off the
188
connection to a Postfix SMTP server process. </p>
190
<p> When the SMTP client address matches a "reject" action,
191
postscreen(8) logs this with the client address and port number as:
195
<b>BLACKLISTED</b> <i>[address]:port</i>
198
<p> The postscreen_blacklist_action parameter specifies the action
199
that is taken next. See "<a href="#fail_before_220">When tests
200
fail before the 220 SMTP server greeting</a>" below. </p>
202
<h3> <a name="temp_white"> Temporary whitelist test </a> </h3>
204
<p> The postscreen(8) daemon maintains a <i>temporary</i>
205
whitelist for SMTP client IP addresses that have passed all
206
the tests described below. The postscreen_cache_map parameter
207
specifies the location of the temporary whitelist. The
208
temporary whitelist is not used for SMTP client addresses
209
that appear on the <i>permanent</i> blacklist or whitelist. </p>
211
<p> When the SMTP client address appears on the temporary
212
whitelist, postscreen(8) logs this with the client address and port
216
<b>PASS OLD</b> <i>[address]:port</i>
219
<p> The action is not configurable: immediately hand off the
220
connection to a Postfix SMTP server process. The client is
221
excluded from further tests until its temporary whitelist
222
entry expires, as controlled with the postscreen_*_ttl
223
parameters. Expired entries are silently renewed if possible. </p>
225
<h2> <a name="before_220"> Tests before the 220 SMTP server greeting </a> </h2>
227
<p> The postscreen_greet_wait parameter specifies a short time
228
interval before the "220 <i>text</i>..." server greeting, where
229
postscreen(8) can run a number of tests in parallel. </p>
231
<p> When a good client passes these tests, and no "<a
232
href="#after_220">deep protocol tests</a>" are configured, postscreen(8)
233
adds the client to the temporary whitelist and hands off the "live"
234
connection to a Postfix SMTP server process. The client can then
235
continue as if postscreen(8) never even existed (except of course
236
for the short postscreen_greet_wait delay). </p>
240
<li> <a href="#pregreet"> Pregreet test </a>
242
<li> <a href="#dnsbl"> DNS White/blacklist test </a>
244
<li> <a href="#fail_before_220">When tests fail before the 220 SMTP server greeting</a>
248
<h3> <a name="pregreet"> Pregreet test </a> </h3>
250
<p> The SMTP protocol is a classic example of a protocol where the
251
server speaks before the client. postscreen(8) detects zombies
252
that are in a hurry and that speak before their turn. This test is
253
enabled by default. </p>
255
<p> The postscreen_greet_banner parameter specifies the <i>text</i>
256
portion of a "220-<i>text</i>..." teaser banner (default: $smtpd_banner).
257
Note that this becomes the first part of a multi-line server greeting.
258
The postscreen(8) daemon sends this before the postscreen_greet_wait
259
timer is started. The purpose of the teaser banner is to confuse
260
zombies so that they speak before their turn. It has no effect on
261
SMTP clients that correctly implement the protocol. </p>
263
<p> To avoid problems with poorly-implemented SMTP engines in network
264
appliances or network testing tools, either exclude them from all
265
tests with the postscreen_access_list feature or else specify
266
an empty teaser banner: </p>
269
/etc/postfix/main.cf:
270
# Exclude broken clients by whitelisting. Clients in mynetworks
271
# should always be whitelisted.
272
postscreen_access_list = permit_mynetworks,
273
cidr:/etc/postfix/postscreen_access.cidr
275
/etc/postfix/postscreen_access.cidr:
276
192.168.254.0/24 permit
280
/etc/postfix/main.cf:
281
# Disable the teaser banner (try whitelisting first if you can).
282
postscreen_greet_banner =
285
<p> When an SMTP client sends a command before the
286
postscreen_greet_wait time has elapsed, postscreen(8) logs this as:
290
<b>PREGREET</b> <i>count</i> <b>after</b> <i>time</i> <b>from</b> <i>[address]:port text...</i>
293
<p> Translation: the client at <i>[address]:port</i> sent <i>count</i>
294
bytes before its turn to speak. This happened <i>time</i> seconds
295
after the postscreen_greet_wait timer was started. The <i>text</i>
296
is what the client sent (truncated to 100 bytes, and with non-printable
297
characters replaced with C-style escapes such as \r for carriage-return
298
and \n for newline). </p>
300
<p> The postscreen_greet_action parameter specifies the action that
301
is taken next. See "<a href="#fail_before_220">When tests fail
302
before the 220 SMTP server greeting</a>" below. </p>
304
<h3> <a name="dnsbl"> DNS White/blacklist test </a> </h3>
306
<p> The postscreen_dnsbl_sites parameter (default: empty) specifies
307
a list of DNS blocklist servers with optional filters and weight
308
factors (positive weights for blacklisting, negative for whitelisting).
309
These servers will be queried in parallel with the reverse client
310
IP address. This test is disabled by default. </p>
314
CAUTION: when postscreen rejects mail, its SMTP reply contains the
315
DNSBL domain name. Use the postscreen_dnsbl_reply_map feature to
316
hide "password" information in DNSBL domain names.
320
<p> When the postscreen_greet_wait time has elapsed, and the combined
321
DNSBL score is equal to or greater than the postscreen_dnsbl_threshold
322
parameter value, postscreen(8) logs this as: </p>
325
<b>DNSBL rank</b> <i>count</i> <b>for</b> <i>[address]:port</i>
328
<p> Translation: the SMTP client at <i>[address]:port</i> has a combined
329
DNSBL score of <i>count</i>. </p>
331
<p> The postscreen_dnsbl_action parameter specifies the action that
332
is taken when the combined DNSBL score is equal to or greater than
333
the threshold. See "<a href="#fail_before_220">When tests fail
334
before the 220 SMTP server greeting</a>" below. </p>
336
<h3> <a name="fail_before_220">When tests fail before the 220 SMTP server greeting</a> </h3>
338
<p> When the client address matches the permanent blacklist, or
339
when the client fails the pregreet or DNSBL tests, the action is
340
specified with postscreen_blacklist_action, postscreen_greet_action,
341
or postscreen_dnsbl_action, respectively. </p>
345
<dt> <b>ignore</b> (default) </dt>
347
<dd> Ignore the failure of this test. Allow other tests to complete.
348
Repeat this test the next time the client connects. This option
349
is useful for testing and collecting statistics without blocking
352
<dt> <b>enforce</b> </dt>
354
<dd> Allow other tests to complete. Reject attempts to deliver mail
355
with a 550 SMTP reply, and log the helo/sender/recipient information.
356
Repeat this test the next time the client connects. </dd>
358
<dt> <b>drop</b> </dt>
360
<dd> Drop the connection immediately with a 521 SMTP reply. Repeat
361
this test the next time the client connects. </dd>
365
<h2> <a name="after_220">Tests after the 220 SMTP server greeting</a> </h2>
367
<p> In this phase of the protocol, postscreen(8) implements a
368
number of "deep protocol" tests. These tests use an SMTP protocol
369
engine that is built into the postscreen(8) server. </p>
371
<p> Important note: deep protocol tests are disabled by default.
372
They are more intrusive than the pregreet and DNSBL tests, and they
373
have limitations as discussed next. </p>
377
<li> <p> When a good client passes the <a href="#after_220">deep
378
protocol tests</a>, postscreen(8) adds the client to the temporary
379
whitelist but it cannot hand off the "live" connection to a Postfix
380
SMTP server process in the middle of the session. Instead, postscreen(8)
381
defers mail delivery attempts with a 4XX status, logs the
382
helo/sender/recipient information, and waits for the client to
385
<p> The next time the client connects it will be allowed to talk
386
to a Postfix SMTP server process to deliver its mail. To minimize the
387
impact of this limitation, postscreen(8) gives deep protocol tests
388
a relatively long expiration time. </p>
390
<li> <p> postscreen(8)'s built-in SMTP engine does not implement
391
the AUTH, XCLIENT, and XFORWARD features. AUTH support may be added
392
in a future version. In the mean time, if you need to make these
393
services available on port 25, then do not enable the tests after
394
the 220 server greeting. </p>
398
<p> End-user clients should connect directly to the submission
399
service, so that they never have to deal with postscreen(8)'s tests.
404
<li> <a href="#pipelining">Command pipelining test</a>
406
<li> <a href="#non_smtp">Non-SMTP command test</a>
408
<li> <a href="#barelf">Bare newline test</a>
410
<li> <a href="#fail_after_220">When tests fail after the 220 SMTP server greeting</a>
414
<h3> <a name="pipelining">Command pipelining test</a> </h3>
416
<p> By default, SMTP is a half-duplex protocol: the sender and
417
receiver send one command and one response at a time. Unlike the
418
Postfix SMTP server, postscreen(8) does not announce support
419
for ESMTP command pipelining. Therefore, clients are not allowed
420
to send multiple commands. postscreen(8)'s <a href="#after_220">deep
421
protocol test</a> for this is disabled by default. </p>
423
<p> With "postscreen_pipelining_enable = yes", postscreen(8) detects
424
zombies that send multiple commands, instead of sending one command
425
and waiting for the server to reply. </p>
427
<p> This test is opportunistically enabled when postscreen(8) has
428
to use the built-in SMTP engine anyway. This is to make postscreen(8)
429
logging more informative. </p>
431
<p> When a client sends multiple commands, postscreen(8) logs this
435
<b>COMMAND PIPELINING after</b> <i>time</i> <b>from</b> <i>[address]:port</i>
438
<p> Translation: the SMTP client at <i>[address]:port</i> sent multiple
439
SMTP commands, instead of sending one command and then waiting for
440
the server to reply. This happened <i>time</i> seconds after the
441
"220 " server greeting was sent. </p>
443
<p> The postscreen_pipelining_action parameter specifies the action
444
that is taken next. See "<a href="#fail_after_220">When tests fail
445
after the 220 SMTP server greeting</a>" below. </p>
447
<h3> <a name="non_smtp">Non-SMTP command test</a> </h3>
449
<p> Some spambots send their mail through open proxies. A symptom
450
of this is the usage of commands such as CONNECT and other non-SMTP
451
commands. Just like the Postfix SMTP server's smtpd_forbidden_commands
452
feature, postscreen(8) has an equivalent postscreen_forbidden_commands
453
feature to block these clients. postscreen(8)'s <a href="#after_220">deep
454
protocol test</a> for this is disabled by default. </p>
456
<p> With "postscreen_non_smtp_command_enable = yes", postscreen(8)
457
detects zombies that send commands specified with the
458
postscreen_forbidden_commands parameter. This also detects commands
459
with the syntax of a message header label. The latter is a symptom
460
that the client is sending message content after ignoring all the
461
responses from postscreen(8) that reject mail. </p>
463
<p> This test is opportunistically enabled when postscreen(8) has
464
to use the built-in SMTP engine anyway. This is to make postscreen(8)
465
logging more informative. </p>
467
<p> When a client sends non-SMTP commands, postscreen(8) logs this
471
<b>NON-SMTP COMMAND from</b> <i>[address]:port command</i>
474
<p> Translation: the SMTP client at <i>[address]:port</i> sent a
475
<i>command</i> that matches the postscreen_forbidden_commands
476
parameter, or that has the syntax of a message header label. </p>
478
<p> The postscreen_non_smtp_command_action parameter specifies
479
the action that is taken next. See "<a href="#fail_after_220">When
480
tests fail after the 220 SMTP server greeting</a>" below. </p>
482
<h3> <a name="barelf">Bare newline test</a> </h3>
484
<p> SMTP is a line-oriented protocol: lines have a limited length,
485
and are terminated with <CR><LF>. Lines ending in a
486
"bare" <LF>, that is newline not preceded by carriage return,
487
are not allowed in SMTP. postscreen(8)'s <a href="#after_220">deep
488
protocol test</a> for this is disabled by default. </p>
490
<p> With "postscreen_bare_newline_enable = yes", postscreen(8)
491
detects clients that send lines ending in bare newline characters.
494
<p> This test is opportunistically enabled when postscreen(8) has
495
to use the built-in SMTP engine anyway. This is to make postscreen(8)
496
logging more informative. </p>
498
<p> When a client sends bare newline characters, postscreen(8) logs
503
<b>BARE NEWLINE from</b> <i>[address]:port</i>
506
<p> Translation: the SMTP client at <i>[address]:port</i> sent a bare
507
newline character, that is newline not preceded by carriage
510
<p> The postscreen_bare_newline_action parameter specifies the
511
action that is taken next. See "<a href="#fail_after_220">When
512
tests fail after the 220 SMTP server greeting</a>" below. </p>
514
<h3> <a name="fail_after_220">When tests fail after the 220 SMTP server greeting</a> </h3>
516
<p> When the client fails the pipelining, non-SMTP command or bare
517
newline tests, the action is specified with postscreen_pipelining_action,
518
postscreen_non_smtp_command_action or postscreen_bare_newline_action,
523
<dt> <b>ignore</b> (default for bare newline) </dt>
525
<dd> Ignore the failure of this test. Allow other tests to complete.
526
Do NOT repeat this test before the result from some other test
529
This option is useful for testing and collecting statistics without
530
blocking mail permanently. </dd>
532
<dt> <b>enforce</b> (default for pipelining) </dt>
534
<dd> Allow other tests to complete. Reject attempts to deliver
535
mail with a 550 SMTP reply, and log the helo/sender/recipient
536
information. Repeat this test the next time the client connects.
539
<dt> <b>drop</b> (default for non-SMTP commands) </dt>
541
<dd> Drop the connection immediately with a 521 SMTP reply. Repeat
542
this test the next time the client connects. This action is
543
compatible with the Postfix SMTP server's smtpd_forbidden_commands
548
<h2> <a name="other_error">Other errors</a> </h2>
550
<p> When an SMTP client hangs up unexpectedly during any tests,
551
postscreen(8) logs this as: </p>
554
<b>HANGUP after</b> <i>time</i> <b>from</b> <i>[address]:port</i> <b>in</b> <i>test name</i>
557
<p> Translation: the SMTP client at <i>[address]:port</i> disconnected
558
unexpectedly, <i>time</i> seconds after the start of the
559
test named <i>test name</i>. </p>
563
<p> While an unexpired penalty is in effect, an SMTP client is not
564
allowed to pass any tests, and postscreen(8) logs each connection
565
with the remaining amount of penalty time as: </p>
568
<b>PENALTY</b> <i>time</i> <b>for</b> <i>[address]:port</i>
571
<p> During this time, all attempts by the client to deliver mail
572
will be deferred with a 450 SMTP status. </p>
576
<p> The following errors are reported by the built-in SMTP engine.
577
This engine never accepts mail, therefore it has per-session limits
578
on the number of commands and on the session length. </p>
581
<b>COMMAND TIME LIMIT</b> <b>from</b> <i>[address]:port</i>
584
<p> Translation: the SMTP client at <i>[address]:port</i> reached the
585
per-command time limit as specified with the postscreen_command_time_limit
586
parameter. The session is terminated immediately. </p>
589
<b>COMMAND COUNT LIMIT from</b> <i>[address]:port</i>
592
<p> Translation: the SMTP client at <i>[address]:port</i> reached the
593
per-session command count limit as specified with the
594
postscreen_command_count_limit parameter. The session is terminated
598
<b>COMMAND LENGTH LIMIT from</b> <i>[address]:port</i>
601
<p> Translation: the SMTP client at <i>[address]:port</i> reached the
602
per-command length limit, as specified with the line_length_limit
603
parameter. The session is terminated immediately. </p>
605
<p> When an SMTP client makes too many connections at the same time,
606
or when all postscreen(8) ports are busy, postscreen(8) rejects the
607
connection with a 421 status code and logs: </p>
610
<b>NOQUEUE: reject: CONNECT from</b> <i>[address]:port</i><b>: too many connections</b>
611
<b>NOQUEUE: reject: CONNECT from</b> <i>[address]:port</i><b>: all server ports busy</b>
614
<p> The postscreen_client_connection_count_limit and
615
postscreen_pre_queue_limit parameters control these limits. </p>
617
<h2> <a name="victory">When all tests succeed</a> </h2>
619
<p> When a new SMTP client passes all tests (i.e. it is not whitelisted
620
via some mechanism), postscreen(8) logs this as: </p>
623
<b>PASS NEW</b> <i>[address]:port</i>
626
<p> Where <i>[address]:port</i> are the client IP address and port.
628
creates a temporary whitelist entry that excludes the client IP
629
address from further tests until the temporary whitelist entry
630
expires, as controlled with the postscreen_*_ttl parameters. </p>
632
<p> When no "<a href="#after_220">deep protocol tests</a>" are
633
configured, postscreen(8) hands off the "live" connection to a Postfix
634
SMTP server process. The client can then continue as if postscreen(8)
635
never even existed (except for the short postscreen_greet_wait delay).
638
<p> When any "<a href="#after_220">deep protocol tests</a>" are
639
configured, postscreen(8) cannot hand off the "live" connection to
640
a Postfix SMTP server process in the middle of the session. Instead,
641
postscreen(8) defers mail delivery attempts with a 4XX status, logs
642
the helo/sender/recipient information, and waits for the client to
643
disconnect. The next time the client connects it will be allowed
644
to talk to a Postfix SMTP server process to deliver its mail.
645
postscreen(8) mitigates the impact of this limitation by giving
646
<a href="#after_220">deep protocol tests</a> a long expiration
649
<h2> <a name="config"> Configuring the postscreen(8) service</a>
652
<p> postscreen(8) has been tested on FreeBSD [4-8], Linux 2.[4-6]
653
and Solaris 9 systems. </p>
657
<li> <a href="#enable"> Turning on postscreen(8) without blocking
660
<li> <a href="#starttls"> postscreen(8) TLS configuration </a>
662
<li> <a href="#blocking"> Blocking mail with postscreen(8) </a>
664
<li> <a href="#turnoff"> Turning off postscreen(8) </a>
668
<h3> <a name="enable"> Turning on postscreen(8) without blocking mail</a> </h3>
670
<p> To enable the postscreen(8) service and log client information
671
without blocking mail: </p>
675
<li> <p> Make sure that local clients and systems with non-standard
676
SMTP implementations are excluded from any postscreen(8) tests. The
677
default is to exclude all clients in mynetworks. To exclude additional
678
clients, for example, third-party performance monitoring tools (these
679
tend to have broken SMTP implementations): </p>
682
/etc/postfix/main.cf:
683
# Exclude broken clients by whitelisting. Clients in mynetworks
684
# should always be whitelisted.
685
postscreen_access_list = permit_mynetworks,
686
cidr:/etc/postfix/postscreen_access.cidr
688
/etc/postfix/postscreen_access.cidr:
689
192.168.254.0/24 permit
692
<li> <p> Comment out the "<tt>smtp inet ... smtpd</tt>" service
693
in master.cf, including any "<tt>-o parameter=value</tt>" entries
697
/etc/postfix/master.cf:
698
#smtp inet n - n - - smtpd
699
# -o parameter=value ...
702
<li> <p> Uncomment the new "<tt>smtpd pass ... smtpd</tt>" service
703
in master.cf, and duplicate any "<tt>-o parameter=value</tt>" entries
704
from the smtpd service that was commented out in step 1. </p>
707
/etc/postfix/master.cf:
708
smtpd pass - - n - - smtpd
709
-o parameter=value ...
712
<li> <p> Uncomment the new "<tt>smtp inet ... postscreen</tt>"
713
service in master.cf. </p>
716
/etc/postfix/master.cf:
717
smtp inet n - n - 1 postscreen
720
<li> <p> Uncomment the new "<tt>tlsproxy unix ... tlsproxy</tt>"
721
service in master.cf. This service implements STARTTLS support for
725
/etc/postfix/master.cf:
726
tlsproxy unix - - n - 0 tlsproxy
729
<li> <p> Uncomment the new "<tt>dnsblog unix ... dnsblog</tt>"
730
service in master.cf. This service does DNSBL lookups for postscreen(8)
731
and logs results. </p>
734
/etc/postfix/master.cf:
735
dnsblog unix - - n - 0 dnsblog
738
<li> <p> To enable DNSBL lookups, list some DNS blocklist sites in
739
main.cf, separated by whitespace. Different sites can have different
740
weights. For example:
743
/etc/postfix/main.cf:
744
postscreen_dnsbl_threshold = 2
745
postscreen_dnsbl_sites = zen.spamhaus.org*2
746
bl.spamcop.net*1 b.barracudacentral.org*1
749
<p> Note: if your DNSBL queries have a "secret" in the domain name,
750
you must censor this information from the postscreen(8) SMTP replies.
754
/etc/postfix/main.cf:
755
postscreen_dnsbl_reply_map = texthash:/etc/postfix/dnsbl_reply
759
/etc/postfix/dnsbl_reply:
760
# Secret DNSBL name Name in postscreen(8) replies
761
secret.zen.spamhaus.org zen.spamhaus.org
764
<p> The texthash: format is similar to hash: except that there is
765
no need to run postmap(1) before the file can be used, and that it
766
does not detect changes after the file is read. It is new with
767
Postfix version 2.8. </p>
769
<li> <p> Read the new configuration with "<tt>postfix reload</tt>".
778
<li> <p> Some postscreen(8) configuration parameters implement
779
stress-dependent behavior. This is supported only when the default
780
value is stress-dependent (that is, it looks like ${stress?X}${stress:Y}).
781
Other parameters always evaluate as if the stress value is the empty
784
<li> <p> See "<a href="#before_220">Tests before the 220 SMTP server
785
greeting</a>" for details about the logging from these postscreen(8)
788
<li> <p> If you run Postfix 2.6 or earlier you must stop and start
789
the master daemon ("<tt>postfix stop; postfix start</tt>"). This
790
is needed because the Postfix "pass" master service type did not
791
work reliably on all systems. </p>
795
<h3> <a name="starttls"> postscreen(8) TLS configuration </a> </h3>
797
<p> postscreen(8) TLS support is available for remote SMTP clients
798
that aren't whitelisted, including clients that need to renew their
799
temporary whitelist status. When a remote SMTP client requests TLS
800
service, postscreen(8) invisibly hands off the connection to a
801
tlsproxy(8) process. Then, tlsproxy(8) encrypts and decrypts the
802
traffic between postscreen(8) and the remote SMTP client. One
803
tlsproxy(8) process can handle multiple SMTP sessions. The number
804
of tlsproxy(8) processes slowly increases with server load, but it
805
should always be much smaller than the number of postscreen(8) TLS
808
<p> TLS support for postscreen(8) and tlsproxy(8) uses the same
809
parameters as with smtpd(8). We recommend that you keep the relevant
810
configuration parameters in main.cf. If you must specify "-o
811
smtpd_mumble=value" parameter overrides in master.cf for a
812
postscreen-protected smtpd(8) service, then you should specify those
813
same parameter overrides for the postscreen(8) and tlsproxy(8)
816
<h3> <a name="blocking"> Blocking mail with postscreen(8) </a> </h3>
818
<p> For compatibility with smtpd(8), postscreen(8) implements the
819
soft_bounce safety feature. This causes Postfix to reject mail with
820
a "try again" reply code. </p>
824
<li> <p> To turn this on for all of Postfix, specify "<tt>soft_bounce
825
= yes</tt>" in main.cf. </p>
827
<li> <p> To turn this on for postscreen(8) only, append "<tt>-o
828
soft_bounce=yes</tt>" (note: NO SPACES around '=') to the postscreen
829
entry in master.cf. <p>
833
<p> Execute "<tt>postfix reload</tt>" to make the change effective. </p>
835
<p> After testing, do not forget to remove the soft_bounce feature,
836
otherwise senders won't receive their non-delivery notification
837
until many days later. </p>
839
<p> To use the postscreen(8) service to block mail, edit main.cf and
840
specify one or more of: </p>
844
<li> <p> "<tt>postscreen_dnsbl_action = enforce</tt>", to reject
845
clients that are on DNS blocklists, and to log the helo/sender/recipient
846
information. With good DNSBLs this reduces the amount of load on
847
Postfix SMTP servers dramatically. </p>
849
<li> <p> "<tt>postscreen_greet_action = enforce</tt>", to reject
850
clients that talk before their turn, and to log the helo/sender/recipient
851
information. This stops over half of all known-to-be illegitimate
852
connections to Wietse's mail server. It is backup protection for
853
zombies that haven't yet been blacklisted. </p>
855
<li> <p> You can also enable "<a href="#after_220">deep protocol
856
tests</a>", but these are more intrusive than the pregreet or DNSBL
859
<p> When a good client passes the "<a href="#after_220">deep
860
protocol tests</a>", postscreen(8) adds the client to the temporary
861
whitelist but it cannot hand off the "live" connection to a Postfix
862
SMTP server process in the middle of the session. Instead, postscreen(8)
863
defers mail delivery attempts with a 4XX status, logs the
864
helo/sender/recipient information, and waits for the client to
867
<p> When the good client comes back in a later session, it is allowed
868
to talk directly to a Postfix SMTP server. See "after_220 <a
869
href="#after_220">Tests after the 220 SMTP server greeting</a> above
870
for limitations with AUTH and other features that clients may need.
873
<p> An unexpected benefit from "<a href="#after_220">deep protocol
874
tests</a>" is that some "good" clients don't return after the 4XX
875
reply; these clients were not so good after all. Wietse enables
876
"<a href="#after_220">deep protocol tests</a>" on his own internet-facing
879
<li> <p> There is also support for permanent blacklisting and
880
whitelisting; see the description of the postscreen_access_list
881
parameter for details. </p>
885
<h3> <a name="turnoff"> Turning off postscreen(8) </a> </h3>
887
<p> To turn off postscreen(8) and handle mail directly with Postfix
888
SMTP server processes: </p>
892
<li> <p> Comment out the "<tt>smtp inet ... postscreen</tt>" service
893
in master.cf, including any "<tt>-o parameter=value</tt>" entries
897
/etc/postfix/master.cf:
898
#smtp inet n - n - 1 postscreen
899
# -o parameter=value ...
902
<li> <p> Comment out the "<tt>dnsblog unix ... dnsblog</tt>" service
906
/etc/postfix/master.cf:
907
#dnsblog unix - - n - 0 dnsblog
910
<li> <p> Comment out the "<tt>smtpd pass ... smtpd</tt>" service
911
in master.cf, including any "<tt>-o parameter=value</tt>" entries
915
/etc/postfix/master.cf:
916
#smtpd pass - - n - - smtpd
917
# -o parameter=value ...
920
<li> <p> Comment out the "<tt>tlsproxy unix ... tlsproxy</tt>"
921
service in master.cf, including any "<tt>-o parameter=value</tt>"
922
entries that follow. </p>
925
/etc/postfix/master.cf:
926
#tlsproxy unix - - n - 0 tlsproxy
927
# -o parameter=value ...
930
<li> <p> Uncomment the "<tt>smtp inet ... smtpd</tt>" service in
931
master.cf, including any "<tt>-o parameter=value</tt>" entries that
935
/etc/postfix/master.cf:
936
smtp inet n - n - - smtpd
937
-o parameter=value ...
940
<li> <p> Read the new configuration with "<tt>postfix reload</tt>".
945
<h2> <a name="historical"> Historical notes and credits </a> </h2>
947
<p> Many ideas in postscreen(8) were explored in earlier work by
948
Michael Tokarev, in OpenBSD spamd, and in MailChannels Traffic
951
<p> Wietse threw together a crude prototype with pregreet and dnsbl
952
support in June 2009, because he needed something new for a Mailserver
953
conference presentation in July. Ralf Hildebrandt ran this code on
954
several servers to collect real-world statistics. This version used
955
the dnsblog(8) ad-hoc DNS client program. </p>
957
<p> Wietse needed new material for a LISA conference presentation
958
in November 2010, so he added support for DNSBL weights and filters
959
in August, followed by a major code rewrite, deep protocol tests,
960
helo/sender/recipient logging, and stress-adaptive behavior in
961
September. Ralf Hildebrandt ran this code on several servers to
962
collect real-world statistics. This version still used the embarrassing
963
dnsblog(8) ad-hoc DNS client program. </p>
965
<p> Wietse added STARTTLS support in December 2010. This makes
966
postscreen(8) usable for sites that require TLS support. The
967
implementation introduces the tlsproxy(8) event-driven TLS proxy
968
that decrypts/encrypts the sessions for multiple SMTP clients. </p>
added
removed
proto/POSTSCREEN_README.html
