1
PPoossttffiixx PPoossttssccrreeeenn HHoowwttoo
3
-------------------------------------------------------------------------------
5
IInnttrroodduuccttiioonn
7
The Postfix postscreen(8) server performs triage on multiple inbound SMTP
8
connections at the same time. While a single postscreen(8) process keeps
9
zombies away from Postfix SMTP server processes, more Postfix SMTP server
10
processes remain available for legitimate clients.
12
postscreen(8) should not be used on SMTP ports that receive mail from end-user
13
clients (MUAs). In a typical deployment, postscreen(8) is used on the "port 25"
14
service, while MUA clients submit mail via the submission service.
16
postscreen(8) is part of a multi-layer defense.
18
* As the first layer, postscreen(8) blocks connections from zombies and other
19
spambots that are responsible for about 90% of all spam. It is implemented
20
as a single process to make this defense as cheap as possible.
22
* The second layer implements more complex SMTP-level access checks with
23
Postfix SMTP servers, policy daemons, and Milter applications.
25
* The third layer performs light-weight content inspection with the Postfix
26
built-in header_checks and body_checks. This can block unacceptable
27
attachments such as executable programs, and worms or viruses with easy-to-
30
* The fourth layer provides heavy-weight content inspection with external
31
content filters. Typical examples are Amavisd-new, SpamAssassin, and Milter
34
Each layer reduces the spam volume. The general strategy is to use the less
35
expensive defenses first, and to use the more expensive defenses for the spam
38
Topics in this document:
41
* The basic idea behind postscreen(8)
43
* Quick tests before everything else
44
* Tests before the 220 SMTP server greeting
45
* Tests after the 220 SMTP server greeting
47
* When all tests succeed
48
* Configuring the postscreen(8) service
49
* Historical notes and credits
51
TThhee bbaassiicc iiddeeaa bbeehhiinndd ppoossttssccrreeeenn((88))
53
Most email is spam, and most spam is sent out by zombies (malware on
54
compromised end-user computers). Wietse expects that the zombie problem will
55
get worse before things improve, if ever. Without a tool like postscreen(8)
56
that keeps the zombies away, Postfix would be spending most of its resources
59
The main challenge for postscreen(8) is to make an is-it-a-zombie decision
60
based on a single measurement. This is necessary because many zombies avoid
61
spamming the same site repeatedly, in an attempt to fly under the radar. Once
62
postscreen(8) decides that a client is not-a-zombie, it whitelists the client
63
temporarily to avoid further delays for legitimate mail.
65
Zombies have challenges too: they have only a limited amount of time to deliver
66
spam before their IP address becomes blacklisted. To speed up spam deliveries,
67
zombies make compromises in their SMTP protocol implementation. For example,
68
they speak before their turn, or they ignore responses from SMTP servers and
69
continue sending mail even when the server tells them to go away.
71
postscreen(8) uses a variety of measurements to recognize zombies. First,
72
postscreen(8) determines if the remote SMTP client IP address is blacklisted.
73
Second, postscreen(8) looks for protocol compromises that are made to speed up
74
delivery. These are good indicators for making is-it-a-zombie decisions based
75
on single measurements.
77
postscreen(8) does not inspect message content. Message content can vary from
78
one delivery to the next, especially with clients that (also) send legitimate
79
email. Content is not a good indicator for making is-it-a-zombie decisions
80
based on single measurements, and that is the problem that postscreen(8) is
83
GGeenneerraall ooppeerraattiioonn
85
The postscreen(8) triage process involves a number of tests, in the order as
86
described below. Some tests introduce a delay of a few seconds. Once a client
87
passes a test, its IP address is whitelisted from 24 hours for simple tests, to
88
1 week for complex tests. Whitelisting minimizes the impact of postscreen(8)'s
89
tests on legitimate mail clients.
91
After logging its findings, postscreen(8) by default hands off all connections
92
to a Postfix SMTP server process. This mode is useful for non-destructive
95
In a typical production setting, postscreen(8) is configured to reject mail
96
from clients that fail one or more tests, after logging the helo, sender and
97
recipient information.
99
Note: postscreen(8) is not an SMTP proxy; this is intentional. The purpose is
100
to keep zombies away from Postfix, with minimal overhead for legitimate
103
QQuuiicckk tteessttss bbeeffoorree eevveerryytthhiinngg eellssee
105
Before engaging in SMTP-level tests. postscreen(8) queries a number of local
106
black and whitelists. These tests speed up the handling of known clients.
108
* Permanent white/blacklist test
109
* Temporary whitelist test
111
PPeerrmmaanneenntt wwhhiittee//bbllaacckklliisstt tteesstt
113
The postscreen_access_list parameter (default: permit_mynetworks) specifies a
114
permanent access list for SMTP client IP addresses. Typically one would specify
115
something that whitelists local networks, followed by a CIDR table for
116
selective white- and blacklisting.
120
/etc/postfix/main.cf:
121
postscreen_access_list = permit_mynetworks,
122
cidr:/etc/postfix/postscreen_access.cidr
124
/etc/postfix/postscreen_access.cidr:
125
# Rules are evaluated in the order as specified.
126
# Blacklist 192.168.* except 192.168.0.1.
128
192.168.0.0/16 reject
130
See the postscreen_access_list manpage documentation for more details.
132
When the SMTP client address matches a "permit" action, postscreen(8) logs this
133
with the client address and port number as:
135
WWHHIITTEELLIISSTTEEDD [address]:port
137
The whitelist action is not configurable: immediately hand off the connection
138
to a Postfix SMTP server process.
140
When the SMTP client address matches a "reject" action, postscreen(8) logs this
141
with the client address and port number as:
143
BBLLAACCKKLLIISSTTEEDD [address]:port
145
The postscreen_blacklist_action parameter specifies the action that is taken
146
next. See "When tests fail before the 220 SMTP server greeting" below.
148
TTeemmppoorraarryy wwhhiitteelliisstt tteesstt
150
The postscreen(8) daemon maintains a temporary whitelist for SMTP client IP
151
addresses that have passed all the tests described below. The
152
postscreen_cache_map parameter specifies the location of the temporary
153
whitelist. The temporary whitelist is not used for SMTP client addresses that
154
appear on the permanent blacklist or whitelist.
156
When the SMTP client address appears on the temporary whitelist, postscreen(8)
157
logs this with the client address and port number as:
159
PPAASSSS OOLLDD [address]:port
161
The action is not configurable: immediately hand off the connection to a
162
Postfix SMTP server process. The client is excluded from further tests until
163
its temporary whitelist entry expires, as controlled with the postscreen_*_ttl
164
parameters. Expired entries are silently renewed if possible.
166
TTeessttss bbeeffoorree tthhee 222200 SSMMTTPP sseerrvveerr ggrreeeettiinngg
168
The postscreen_greet_wait parameter specifies a short time interval before the
169
"220 text..." server greeting, where postscreen(8) can run a number of tests in
172
When a good client passes these tests, and no "deep protocol tests" are
173
configured, postscreen(8) adds the client to the temporary whitelist and hands
174
off the "live" connection to a Postfix SMTP server process. The client can then
175
continue as if postscreen(8) never even existed (except of course for the short
176
postscreen_greet_wait delay).
179
* DNS White/blacklist test
180
* When tests fail before the 220 SMTP server greeting
182
PPrreeggrreeeett tteesstt
184
The SMTP protocol is a classic example of a protocol where the server speaks
185
before the client. postscreen(8) detects zombies that are in a hurry and that
186
speak before their turn. This test is enabled by default.
188
The postscreen_greet_banner parameter specifies the text portion of a "220-
189
text..." teaser banner (default: $smtpd_banner). Note that this becomes the
190
first part of a multi-line server greeting. The postscreen(8) daemon sends this
191
before the postscreen_greet_wait timer is started. The purpose of the teaser
192
banner is to confuse zombies so that they speak before their turn. It has no
193
effect on SMTP clients that correctly implement the protocol.
195
To avoid problems with poorly-implemented SMTP engines in network appliances or
196
network testing tools, either exclude them from all tests with the
197
postscreen_access_list feature or else specify an empty teaser banner:
199
/etc/postfix/main.cf:
200
# Exclude broken clients by whitelisting. Clients in mynetworks
201
# should always be whitelisted.
202
postscreen_access_list = permit_mynetworks,
203
cidr:/etc/postfix/postscreen_access.cidr
205
/etc/postfix/postscreen_access.cidr:
206
192.168.254.0/24 permit
208
/etc/postfix/main.cf:
209
# Disable the teaser banner (try whitelisting first if you can).
210
postscreen_greet_banner =
212
When an SMTP client sends a command before the postscreen_greet_wait time has
213
elapsed, postscreen(8) logs this as:
215
PPRREEGGRREEEETT count aafftteerr time ffrroomm [address]:port text...
217
Translation: the client at [address]:port sent count bytes before its turn to
218
speak. This happened time seconds after the postscreen_greet_wait timer was
219
started. The text is what the client sent (truncated to 100 bytes, and with
220
non-printable characters replaced with C-style escapes such as \r for carriage-
221
return and \n for newline).
223
The postscreen_greet_action parameter specifies the action that is taken next.
224
See "When tests fail before the 220 SMTP server greeting" below.
226
DDNNSS WWhhiittee//bbllaacckklliisstt tteesstt
228
The postscreen_dnsbl_sites parameter (default: empty) specifies a list of DNS
229
blocklist servers with optional filters and weight factors (positive weights
230
for blacklisting, negative for whitelisting). These servers will be queried in
231
parallel with the reverse client IP address. This test is disabled by default.
233
CAUTION: when postscreen rejects mail, its SMTP reply contains the DNSBL
234
domain name. Use the postscreen_dnsbl_reply_map feature to hide "password"
235
information in DNSBL domain names.
237
When the postscreen_greet_wait time has elapsed, and the combined DNSBL score
238
is equal to or greater than the postscreen_dnsbl_threshold parameter value,
239
postscreen(8) logs this as:
241
DDNNSSBBLL rraannkk count ffoorr [address]:port
243
Translation: the SMTP client at [address]:port has a combined DNSBL score of
246
The postscreen_dnsbl_action parameter specifies the action that is taken when
247
the combined DNSBL score is equal to or greater than the threshold. See "When
248
tests fail before the 220 SMTP server greeting" below.
250
WWhheenn tteessttss ffaaiill bbeeffoorree tthhee 222200 SSMMTTPP sseerrvveerr ggrreeeettiinngg
252
When the client address matches the permanent blacklist, or when the client
253
fails the pregreet or DNSBL tests, the action is specified with
254
postscreen_blacklist_action, postscreen_greet_action, or
255
postscreen_dnsbl_action, respectively.
257
iiggnnoorree (default)
258
Ignore the failure of this test. Allow other tests to complete. Repeat this
259
test the next time the client connects. This option is useful for testing
260
and collecting statistics without blocking mail.
262
Allow other tests to complete. Reject attempts to deliver mail with a 550
263
SMTP reply, and log the helo/sender/recipient information. Repeat this test
264
the next time the client connects.
266
Drop the connection immediately with a 521 SMTP reply. Repeat this test the
267
next time the client connects.
269
TTeessttss aafftteerr tthhee 222200 SSMMTTPP sseerrvveerr ggrreeeettiinngg
271
In this phase of the protocol, postscreen(8) implements a number of "deep
272
protocol" tests. These tests use an SMTP protocol engine that is built into the
273
postscreen(8) server.
275
Important note: deep protocol tests are disabled by default. They are more
276
intrusive than the pregreet and DNSBL tests, and they have limitations as
279
* When a good client passes the deep protocol tests, postscreen(8) adds the
280
client to the temporary whitelist but it cannot hand off the "live"
281
connection to a Postfix SMTP server process in the middle of the session.
282
Instead, postscreen(8) defers mail delivery attempts with a 4XX status,
283
logs the helo/sender/recipient information, and waits for the client to
286
The next time the client connects it will be allowed to talk to a Postfix
287
SMTP server process to deliver its mail. To minimize the impact of this
288
limitation, postscreen(8) gives deep protocol tests a relatively long
291
* postscreen(8)'s built-in SMTP engine does not implement the AUTH, XCLIENT,
292
and XFORWARD features. AUTH support may be added in a future version. In
293
the mean time, if you need to make these services available on port 25,
294
then do not enable the tests after the 220 server greeting.
296
End-user clients should connect directly to the submission service, so that
297
they never have to deal with postscreen(8)'s tests.
299
* Command pipelining test
300
* Non-SMTP command test
302
* When tests fail after the 220 SMTP server greeting
304
CCoommmmaanndd ppiippeelliinniinngg tteesstt
306
By default, SMTP is a half-duplex protocol: the sender and receiver send one
307
command and one response at a time. Unlike the Postfix SMTP server, postscreen
308
(8) does not announce support for ESMTP command pipelining. Therefore, clients
309
are not allowed to send multiple commands. postscreen(8)'s deep protocol test
310
for this is disabled by default.
312
With "postscreen_pipelining_enable = yes", postscreen(8) detects zombies that
313
send multiple commands, instead of sending one command and waiting for the
316
This test is opportunistically enabled when postscreen(8) has to use the built-
317
in SMTP engine anyway. This is to make postscreen(8) logging more informative.
319
When a client sends multiple commands, postscreen(8) logs this as:
321
CCOOMMMMAANNDD PPIIPPEELLIINNIINNGG aafftteerr time ffrroomm [address]:port
323
Translation: the SMTP client at [address]:port sent multiple SMTP commands,
324
instead of sending one command and then waiting for the server to reply. This
325
happened time seconds after the "220 " server greeting was sent.
327
The postscreen_pipelining_action parameter specifies the action that is taken
328
next. See "When tests fail after the 220 SMTP server greeting" below.
330
NNoonn--SSMMTTPP ccoommmmaanndd tteesstt
332
Some spambots send their mail through open proxies. A symptom of this is the
333
usage of commands such as CONNECT and other non-SMTP commands. Just like the
334
Postfix SMTP server's smtpd_forbidden_commands feature, postscreen(8) has an
335
equivalent postscreen_forbidden_commands feature to block these clients.
336
postscreen(8)'s deep protocol test for this is disabled by default.
338
With "postscreen_non_smtp_command_enable = yes", postscreen(8) detects zombies
339
that send commands specified with the postscreen_forbidden_commands parameter.
340
This also detects commands with the syntax of a message header label. The
341
latter is a symptom that the client is sending message content after ignoring
342
all the responses from postscreen(8) that reject mail.
344
This test is opportunistically enabled when postscreen(8) has to use the built-
345
in SMTP engine anyway. This is to make postscreen(8) logging more informative.
347
When a client sends non-SMTP commands, postscreen(8) logs this as:
349
NNOONN--SSMMTTPP CCOOMMMMAANNDD ffrroomm [address]:port command
351
Translation: the SMTP client at [address]:port sent a command that matches the
352
postscreen_forbidden_commands parameter, or that has the syntax of a message
355
The postscreen_non_smtp_command_action parameter specifies the action that is
356
taken next. See "When tests fail after the 220 SMTP server greeting" below.
358
BBaarree nneewwlliinnee tteesstt
360
SMTP is a line-oriented protocol: lines have a limited length, and are
361
terminated with <CR><LF>. Lines ending in a "bare" <LF>, that is newline not
362
preceded by carriage return, are not allowed in SMTP. postscreen(8)'s deep
363
protocol test for this is disabled by default.
365
With "postscreen_bare_newline_enable = yes", postscreen(8) detects clients that
366
send lines ending in bare newline characters.
368
This test is opportunistically enabled when postscreen(8) has to use the built-
369
in SMTP engine anyway. This is to make postscreen(8) logging more informative.
371
When a client sends bare newline characters, postscreen(8) logs this as:
373
BBAARREE NNEEWWLLIINNEE ffrroomm [address]:port
375
Translation: the SMTP client at [address]:port sent a bare newline character,
376
that is newline not preceded by carriage return.
378
The postscreen_bare_newline_action parameter specifies the action that is taken
379
next. See "When tests fail after the 220 SMTP server greeting" below.
381
WWhheenn tteessttss ffaaiill aafftteerr tthhee 222200 SSMMTTPP sseerrvveerr ggrreeeettiinngg
383
When the client fails the pipelining, non-SMTP command or bare newline tests,
384
the action is specified with postscreen_pipelining_action,
385
postscreen_non_smtp_command_action or postscreen_bare_newline_action,
388
iiggnnoorree (default for bare newline)
389
Ignore the failure of this test. Allow other tests to complete. Do NOT
390
repeat this test before the result from some other test expires. This
391
option is useful for testing and collecting statistics without blocking
393
eennffoorrccee (default for pipelining)
394
Allow other tests to complete. Reject attempts to deliver mail with a 550
395
SMTP reply, and log the helo/sender/recipient information. Repeat this test
396
the next time the client connects.
397
ddrroopp (default for non-SMTP commands)
398
Drop the connection immediately with a 521 SMTP reply. Repeat this test the
399
next time the client connects. This action is compatible with the Postfix
400
SMTP server's smtpd_forbidden_commands feature.
402
OOtthheerr eerrrroorrss
404
When an SMTP client hangs up unexpectedly during any tests, postscreen(8) logs
407
HHAANNGGUUPP aafftteerr time ffrroomm [address]:port iinn test name
409
Translation: the SMTP client at [address]:port disconnected unexpectedly, time
410
seconds after the start of the test named test name.
412
The following errors are reported by the built-in SMTP engine. This engine
413
never accepts mail, therefore it has per-session limits on the number of
414
commands and on the session length.
416
CCOOMMMMAANNDD TTIIMMEE LLIIMMIITT ffrroomm [address]:port
418
Translation: the SMTP client at [address]:port reached the per-command time
419
limit as specified with the postscreen_command_time_limit parameter. The
420
session is terminated immediately.
422
CCOOMMMMAANNDD CCOOUUNNTT LLIIMMIITT ffrroomm [address]:port
424
Translation: the SMTP client at [address]:port reached the per-session command
425
count limit as specified with the postscreen_command_count_limit parameter. The
426
session is terminated immediately.
428
CCOOMMMMAANNDD LLEENNGGTTHH LLIIMMIITT ffrroomm [address]:port
430
Translation: the SMTP client at [address]:port reached the per-command length
431
limit, as specified with the line_length_limit parameter. The session is
432
terminated immediately.
434
When an SMTP client makes too many connections at the same time, or when all
435
postscreen(8) ports are busy, postscreen(8) rejects the connection with a 421
436
status code and logs:
438
NNOOQQUUEEUUEE:: rreejjeecctt:: CCOONNNNEECCTT ffrroomm [address]:port:: ttoooo mmaannyy ccoonnnneeccttiioonnss
439
NNOOQQUUEEUUEE:: rreejjeecctt:: CCOONNNNEECCTT ffrroomm [address]:port:: aallll sseerrvveerr ppoorrttss bbuussyy
441
The postscreen_client_connection_count_limit and postscreen_pre_queue_limit
442
parameters control these limits.
444
WWhheenn aallll tteessttss ssuucccceeeedd
446
When a new SMTP client passes all tests (i.e. it is not whitelisted via some
447
mechanism), postscreen(8) logs this as:
449
PPAASSSS NNEEWW [address]:port
451
Where [address]:port are the client IP address and port. Then, postscreen(8)
452
creates a temporary whitelist entry that excludes the client IP address from
453
further tests until the temporary whitelist entry expires, as controlled with
454
the postscreen_*_ttl parameters.
456
When no "deep protocol tests" are configured, postscreen(8) hands off the
457
"live" connection to a Postfix SMTP server process. The client can then
458
continue as if postscreen(8) never even existed (except for the short
459
postscreen_greet_wait delay).
461
When any "deep protocol tests" are configured, postscreen(8) cannot hand off
462
the "live" connection to a Postfix SMTP server process in the middle of the
463
session. Instead, postscreen(8) defers mail delivery attempts with a 4XX
464
status, logs the helo/sender/recipient information, and waits for the client to
465
disconnect. The next time the client connects it will be allowed to talk to a
466
Postfix SMTP server process to deliver its mail. postscreen(8) mitigates the
467
impact of this limitation by giving deep protocol tests a long expiration time.
469
CCoonnffiigguurriinngg tthhee ppoossttssccrreeeenn((88)) sseerrvviiccee
471
postscreen(8) has been tested on FreeBSD [4-8], Linux 2.[4-6] and Solaris 9
474
* Turning on postscreen(8) without blocking mail
475
* postscreen(8) TLS configuration
476
* Blocking mail with postscreen(8)
477
* Turning off postscreen(8)
479
TTuurrnniinngg oonn ppoossttssccrreeeenn((88)) wwiitthhoouutt bblloocckkiinngg mmaaiill
481
To enable the postscreen(8) service and log client information without blocking
484
1. Make sure that local clients and systems with non-standard SMTP
485
implementations are excluded from any postscreen(8) tests. The default is
486
to exclude all clients in mynetworks. To exclude additional clients, for
487
example, third-party performance monitoring tools (these tend to have
488
broken SMTP implementations):
490
/etc/postfix/main.cf:
491
# Exclude broken clients by whitelisting. Clients in mynetworks
492
# should always be whitelisted.
493
postscreen_access_list = permit_mynetworks,
494
cidr:/etc/postfix/postscreen_access.cidr
496
/etc/postfix/postscreen_access.cidr:
497
192.168.254.0/24 permit
499
2. Comment out the "smtp inet ... smtpd" service in master.cf, including any
500
"-o parameter=value" entries that follow.
502
/etc/postfix/master.cf:
503
#smtp inet n - n - - smtpd
504
# -o parameter=value ...
506
3. Uncomment the new "smtpd pass ... smtpd" service in master.cf, and
507
duplicate any "-o parameter=value" entries from the smtpd service that was
508
commented out in step 1.
510
/etc/postfix/master.cf:
511
smtpd pass - - n - - smtpd
512
-o parameter=value ...
514
4. Uncomment the new "smtp inet ... postscreen" service in master.cf.
516
/etc/postfix/master.cf:
517
smtp inet n - n - 1 postscreen
519
5. Uncomment the new "tlsproxy unix ... tlsproxy" service in master.cf. This
520
service implements STARTTLS support for postscreen(8).
522
/etc/postfix/master.cf:
523
tlsproxy unix - - n - 0 tlsproxy
525
6. Uncomment the new "dnsblog unix ... dnsblog" service in master.cf. This
526
service does DNSBL lookups for postscreen(8) and logs results.
528
/etc/postfix/master.cf:
529
dnsblog unix - - n - 0 dnsblog
531
7. To enable DNSBL lookups, list some DNS blocklist sites in main.cf,
532
separated by whitespace. Different sites can have different weights. For
535
/etc/postfix/main.cf:
536
postscreen_dnsbl_threshold = 2
537
postscreen_dnsbl_sites = zen.spamhaus.org*2
538
bl.spamcop.net*1 b.barracudacentral.org*1
540
Note: if your DNSBL queries have a "secret" in the domain name, you must
541
censor this information from the postscreen(8) SMTP replies. For example:
543
/etc/postfix/main.cf:
544
postscreen_dnsbl_reply_map = texthash:/etc/postfix/dnsbl_reply
546
/etc/postfix/dnsbl_reply:
547
# Secret DNSBL name Name in postscreen(8) replies
548
secret.zen.spamhaus.org zen.spamhaus.org
550
The texthash: format is similar to hash: except that there is no need to
551
run postmap(1) before the file can be used, and that it does not detect
552
changes after the file is read. It is new with Postfix version 2.8.
554
8. Read the new configuration with "postfix reload".
558
* Some postscreen(8) configuration parameters implement stress-dependent
559
behavior. This is supported only when the default value is stress-dependent
560
(that is, it looks like ${stress?X}${stress:Y}). Other parameters always
561
evaluate as if the stress value is the empty string.
563
* See "Tests before the 220 SMTP server greeting" for details about the
564
logging from these postscreen(8) tests.
566
* If you run Postfix 2.6 or earlier you must stop and start the master daemon
567
("postfix stop; postfix start"). This is needed because the Postfix "pass"
568
master service type did not work reliably on all systems.
570
ppoossttssccrreeeenn((88)) TTLLSS ccoonnffiigguurraattiioonn
572
postscreen(8) TLS support is available for remote SMTP clients that aren't
573
whitelisted, including clients that need to renew their temporary whitelist
574
status. When a remote SMTP client requests TLS service, postscreen(8) invisibly
575
hands off the connection to a tlsproxy(8) process. Then, tlsproxy(8) encrypts
576
and decrypts the traffic between postscreen(8) and the remote SMTP client. One
577
tlsproxy(8) process can handle multiple SMTP sessions. The number of tlsproxy
578
(8) processes slowly increases with server load, but it should always be much
579
smaller than the number of postscreen(8) TLS sessions.
581
TLS support for postscreen(8) and tlsproxy(8) uses the same parameters as with
582
smtpd(8). We recommend that you keep the relevant configuration parameters in
583
main.cf. If you must specify "-o smtpd_mumble=value" parameter overrides in
584
master.cf for a postscreen-protected smtpd(8) service, then you should specify
585
those same parameter overrides for the postscreen(8) and tlsproxy(8) services.
587
BBlloocckkiinngg mmaaiill wwiitthh ppoossttssccrreeeenn((88))
589
For compatibility with smtpd(8), postscreen(8) implements the soft_bounce
590
safety feature. This causes Postfix to reject mail with a "try again" reply
593
* To turn this on for all of Postfix, specify "soft_bounce = yes" in main.cf.
595
* To turn this on for postscreen(8) only, append "-o soft_bounce=yes" (note:
596
NO SPACES around '=') to the postscreen entry in master.cf.
598
Execute "postfix reload" to make the change effective.
600
After testing, do not forget to remove the soft_bounce feature, otherwise
601
senders won't receive their non-delivery notification until many days later.
603
To use the postscreen(8) service to block mail, edit main.cf and specify one or
606
* "postscreen_dnsbl_action = enforce", to reject clients that are on DNS
607
blocklists, and to log the helo/sender/recipient information. With good
608
DNSBLs this reduces the amount of load on Postfix SMTP servers
611
* "postscreen_greet_action = enforce", to reject clients that talk before
612
their turn, and to log the helo/sender/recipient information. This stops
613
over half of all known-to-be illegitimate connections to Wietse's mail
614
server. It is backup protection for zombies that haven't yet been
617
* You can also enable "deep protocol tests", but these are more intrusive
618
than the pregreet or DNSBL tests.
620
When a good client passes the "deep protocol tests", postscreen(8) adds the
621
client to the temporary whitelist but it cannot hand off the "live"
622
connection to a Postfix SMTP server process in the middle of the session.
623
Instead, postscreen(8) defers mail delivery attempts with a 4XX status,
624
logs the helo/sender/recipient information, and waits for the client to
627
When the good client comes back in a later session, it is allowed to talk
628
directly to a Postfix SMTP server. See "after_220 Tests after the 220 SMTP
629
server greeting above for limitations with AUTH and other features that
632
An unexpected benefit from "deep protocol tests" is that some "good"
633
clients don't return after the 4XX reply; these clients were not so good
634
after all. Wietse enables "deep protocol tests" on his own internet-facing
637
* There is also support for permanent blacklisting and whitelisting; see the
638
description of the postscreen_access_list parameter for details.
640
TTuurrnniinngg ooffff ppoossttssccrreeeenn((88))
642
To turn off postscreen(8) and handle mail directly with Postfix SMTP server
645
1. Comment out the "smtp inet ... postscreen" service in master.cf, including
646
any "-o parameter=value" entries that follow.
648
/etc/postfix/master.cf:
649
#smtp inet n - n - 1 postscreen
650
# -o parameter=value ...
652
2. Comment out the "dnsblog unix ... dnsblog" service in master.cf.
654
/etc/postfix/master.cf:
655
#dnsblog unix - - n - 0 dnsblog
657
3. Comment out the "smtpd pass ... smtpd" service in master.cf, including any
658
"-o parameter=value" entries that follow.
660
/etc/postfix/master.cf:
661
#smtpd pass - - n - - smtpd
662
# -o parameter=value ...
664
4. Comment out the "tlsproxy unix ... tlsproxy" service in master.cf,
665
including any "-o parameter=value" entries that follow.
667
/etc/postfix/master.cf:
668
#tlsproxy unix - - n - 0 tlsproxy
669
# -o parameter=value ...
671
5. Uncomment the "smtp inet ... smtpd" service in master.cf, including any "-
672
o parameter=value" entries that may follow.
674
/etc/postfix/master.cf:
675
smtp inet n - n - - smtpd
676
-o parameter=value ...
678
6. Read the new configuration with "postfix reload".
680
HHiissttoorriiccaall nnootteess aanndd ccrreeddiittss
682
Many ideas in postscreen(8) were explored in earlier work by Michael Tokarev,
683
in OpenBSD spamd, and in MailChannels Traffic Control.
685
Wietse threw together a crude prototype with pregreet and dnsbl support in June
686
2009, because he needed something new for a Mailserver conference presentation
687
in July. Ralf Hildebrandt ran this code on several servers to collect real-
688
world statistics. This version used the dnsblog(8) ad-hoc DNS client program.
690
Wietse needed new material for a LISA conference presentation in November 2010,
691
so he added support for DNSBL weights and filters in August, followed by a
692
major code rewrite, deep protocol tests, helo/sender/recipient logging, and
693
stress-adaptive behavior in September. Ralf Hildebrandt ran this code on
694
several servers to collect real-world statistics. This version still used the
695
embarrassing dnsblog(8) ad-hoc DNS client program.
697
Wietse added STARTTLS support in December 2010. This makes postscreen(8) usable
698
for sites that require TLS support. The implementation introduces the tlsproxy
699
(8) event-driven TLS proxy that decrypts/encrypts the sessions for multiple
added
removed
README_FILES/POSTSCREEN_README
