postfix-master/POSTSCREEN_README.html

   1 <!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN"
   2         "http://www.w3.org/TR/html4/loose.dtd">
   3
   4 <head>
   5
   6 <title>Postfix Postscreen Howto</title>
   7
   8 <meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
   9
  10 </head>
  11
  12 <body>
  13
  14 <h1><img src="postfix-logo.jpg" width="203" height="98" ALT="">Postfix Postscreen Howto</h1>
  15
  16 <hr>
  17
  18 <h2> <a name="intro">Introduction</a> </h2>
  19
  20 <p> The Postfix <a href="postscreen.8.html">postscreen(8)</a> server performs triage on multiple
  21 inbound SMTP connections at the same time. While a single <a href="postscreen.8.html">postscreen(8)</a>
  22 process keeps zombies away from Postfix SMTP server processes, more
  23 Postfix SMTP server processes remain available for legitimate
  24 clients. </p>
  25
  26 <p> <a href="postscreen.8.html">postscreen(8)</a> should not be used on SMTP ports that receive
  27 mail from end-user clients (MUAs). In a typical deployment,
  28 <a href="postscreen.8.html">postscreen(8)</a> is used on the "port 25" service, while MUA clients
  29 submit mail via the submission service. </p>
  30
  31 <p> <a href="postscreen.8.html">postscreen(8)</a> is part of a multi-layer defense. <p>
  32
  33 <ul>
  34
  35 <li> <p> As the first layer, <a href="postscreen.8.html">postscreen(8)</a> 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>
  39
  40 <li> <p> The second layer implements more complex SMTP-level access
  41 checks with Postfix SMTP servers, policy daemons, and Milter
  42 applications. </p>
  43
  44 <li> <p> The third layer performs light-weight content inspection
  45 with the Postfix built-in <a href="postconf.5.html#header_checks">header_checks</a> and <a href="postconf.5.html#body_checks">body_checks</a>. This can
  46 block unacceptable attachments such as executable programs, and
  47 worms or viruses with easy-to-recognize signatures. </p>
  48
  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>
  52
  53 </ul>
  54
  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>
  58
  59 <p> Topics in this document: </p>
  60
  61 <ul>
  62
  63 <li> <a href="#intro">Introduction</a>
  64
  65 <li> <a href="#basic">The basic idea behind postscreen(8)</a>
  66
  67 <li> <a href="#general"> General operation </a>
  68
  69 <li> <a href="#quick">Quick tests before everything else</a>
  70
  71 <li> <a href="#before_220"> Tests before the 220 SMTP server greeting </a>
  72
  73 <li> <a href="#after_220">Tests after the 220 SMTP server greeting</a>
  74
  75 <li> <a href="#other_error">Other errors</a>
  76
  77 <li> <a href="#victory">When all tests succeed</a>
  78
  79 <li> <a href="#config"> Configuring the postscreen(8) service</a>
  80
  81 <li> <a href="#historical"> Historical notes and credits </a>
  82
  83 </ul>
  84
  85 <h2> <a name="basic">The basic idea behind postscreen(8)</a> </h2>
  86
  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 <a href="postscreen.8.html">postscreen(8)</a> that keeps the zombies away, Postfix would be
  91 spending most of its resources not receiving email. </p>
  92
  93 <p> The main challenge for <a href="postscreen.8.html">postscreen(8)</a> is to make an is-it-a-zombie
  94 decision based on a single measurement. This is necessary because
  95 many zombies try to fly under the radar and avoid spamming the same
  96 site repeatedly.  Once <a href="postscreen.8.html">postscreen(8)</a> decides that a client is
  97 not-a-zombie, it whitelists the client temporarily to avoid further
  98 delays for legitimate mail. </p>
  99
 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>
 106
 107 <p> <a href="postscreen.8.html">postscreen(8)</a> uses a variety of measurements to recognize
 108 zombies.  First, <a href="postscreen.8.html">postscreen(8)</a> determines if the remote SMTP client
 109 IP address is blacklisted.  Second, <a href="postscreen.8.html">postscreen(8)</a> 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
 112 measurements.  </p>
 113
 114 <p> <a href="postscreen.8.html">postscreen(8)</a> 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 <a href="postscreen.8.html">postscreen(8)</a> is focused on.  </p>
 119
 120 <h2> <a name="general"> General operation </a> </h2>
 121
 122 <p> The <a href="postscreen.8.html">postscreen(8)</a> 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 <a href="postscreen.8.html">postscreen(8)</a>'s tests
 127 on legitimate mail clients. </p>
 128
 129 <p> By default, <a href="postscreen.8.html">postscreen(8)</a> hands off all connections to a Postfix
 130 SMTP server process after logging its findings. This mode is useful
 131 for non-destructive testing. </p>
 132
 133 <p> In a typical production setting, <a href="postscreen.8.html">postscreen(8)</a> is configured
 134 to reject mail from clients that fail one or more tests, after
 135 logging the helo, sender and recipient information. </p>
 136
 137 <p> Note: <a href="postscreen.8.html">postscreen(8)</a> 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>
 140
 141 <h2> <a name="quick">Quick tests before everything else</a> </h2>
 142
 143 <p> Before engaging in SMTP-level tests. <a href="postscreen.8.html">postscreen(8)</a> queries a
 144 number of local black and whitelists. These tests speed up the
 145 handling of known clients. </p>
 146
 147 <ul>
 148
 149 <li> <a href="#perm_white_black"> Permanent white/blacklist test </a>
 150
 151 <li> <a href="#temp_white"> Temporary whitelist test </a>
 152
 153 <li> <a href="#white_veto"> MX Policy test </a>
 154
 155 </ul>
 156
 157 <h3> <a name="perm_white_black"> Permanent white/blacklist test </a> </h3>
 158
 159 <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>)
 160 specifies a permanent access list for SMTP client IP addresses. Typically
 161 one would specify something that whitelists local networks, followed
 162 by a CIDR table for selective white- and blacklisting. </p>
 163
 164 <p> Example: </p>
 165
 166 <pre>
 167 /etc/postfix/<a href="postconf.5.html">main.cf</a>:
 168     <a href="postconf.5.html#postscreen_access_list">postscreen_access_list</a> = <a href="postconf.5.html#permit_mynetworks">permit_mynetworks</a>,
 169         <a href="cidr_table.5.html">cidr</a>:/etc/postfix/postscreen_access.cidr
 170
 171 /etc/postfix/postscreen_access.<a href="cidr_table.5.html">cidr</a>:
 172    # Rules are evaluated in the order as specified.
 173    # Blacklist 192.168.* except 192.168.0.1.
 174    192.168.0.1          permit
 175    192.168.0.0/16       reject
 176 </pre>
 177
 178 <p> See the <a href="postconf.5.html#postscreen_access_list">postscreen_access_list</a> manpage documentation for more
 179 details.  </p>
 180
 181 <p> When the SMTP client address matches a "permit" action,
 182 <a href="postscreen.8.html">postscreen(8)</a> logs this with the client address and port number as:
 183 </p>
 184
 185 <pre>
 186     <b>WHITELISTED</b> <i>[address]:port</i>
 187 </pre>
 188
 189 <p> The whitelist action is not configurable: immediately hand off the
 190 connection to a Postfix SMTP server process. </p>
 191
 192 <p> When the SMTP client address matches a "reject" action,
 193 <a href="postscreen.8.html">postscreen(8)</a> logs this with the client address and port number as:
 194 </p>
 195
 196 <pre>
 197     <b>BLACKLISTED</b> <i>[address]:port</i>
 198 </pre>
 199
 200 <p> The <a href="postconf.5.html#postscreen_blacklist_action">postscreen_blacklist_action</a> parameter specifies the action
 201 that is taken next.  See "<a href="#fail_before_220">When tests
 202 fail before the 220 SMTP server greeting</a>" below. </p>
 203
 204 <h3> <a name="temp_white"> Temporary whitelist test </a> </h3>
 205
 206 <p> The <a href="postscreen.8.html">postscreen(8)</a> daemon maintains a <i>temporary</i>
 207 whitelist for SMTP client IP addresses that have passed all
 208 the tests described below. The <a href="postconf.5.html#postscreen_cache_map">postscreen_cache_map</a> parameter
 209 specifies the location of the temporary whitelist.  The
 210 temporary whitelist is not used for SMTP client addresses
 211 that appear on the <i>permanent</i> access list. </p>
 212
 213 <p> When the SMTP client address appears on the temporary
 214 whitelist, <a href="postscreen.8.html">postscreen(8)</a> logs this with the client address and port
 215 number as: </p>
 216
 217 <pre>
 218     <b>PASS OLD</b> <i>[address]:port</i>
 219 </pre>
 220
 221 <p> The action is not configurable: immediately hand off the
 222 connection to a Postfix SMTP server process.  The client is
 223 excluded from further tests until its temporary whitelist
 224 entry expires, as controlled with the postscreen_*_ttl
 225 parameters.  Expired entries are silently renewed if possible. </p>
 226
 227 <h3> <a name="white_veto"> MX Policy test </a> </h3>
 228
 229 <p> When the remote SMTP client is not on the static access list
 230 or temporary whitelist, <a href="postscreen.8.html">postscreen(8)</a> can implement a number of
 231 whitelist tests before it grants the client a temporary whitelist
 232 status to talk to a Postfix SMTP server process. </p>
 233
 234 <p> By listening on both primary and backup MX addresses, <a href="postscreen.8.html">postscreen(8)</a>
 235 can deny the temporary whitelist status to clients that connect
 236 only to backup MX hosts (an old trick to take advantage of backup
 237 MX hosts with weaker anti-spam policies). </p>
 238
 239 <p> Note 1: The status of this feature is still experimental, and
 240 implementation details are likely to change. </p>
 241
 242 <p> Note 2: MX policy enforcement is currently supported only for
 243 domains with one Postfix MTA. Support for domains with multiple
 244 Postfix MTAs will have to wait until Postfix has a database client
 245 that can update a shared <a href="postscreen.8.html">postscreen(8)</a> database.  </p>
 246
 247 <ul>
 248
 249 <li> <p> First, configure the host to listen on both primary and
 250 backup MX addresses. Use the appropriate <tt>ifconfig</tt> command
 251 for the local operating system, or update the appropriate configuration
 252 files and "refresh" the network protocol stack. </p>
 253
 254 <li> <p> Then, configure <a href="postscreen.8.html">postscreen(8)</a> to deny the temporary whitelist
 255 status on the backup MX address(es).  An example for Wietse's
 256 server is: </p>
 257
 258 <pre>
 259 /etc/postfix/<a href="postconf.5.html">main.cf</a>:
 260     <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
 261 </pre>
 262
 263 <p> Translation: allow clients to obtain the temporary whitelist
 264 status on all server IP addresses except 168.100.189.8, which is a
 265 backup MX address.  </p>
 266
 267 </ul>
 268
 269 <p> When a non-whitelisted client connects the backup MX address,
 270 <a href="postscreen.8.html">postscreen(8)</a> logs this with the client address and port number as:
 271 </p>
 272
 273 <pre>
 274     <b>CONNECT from</b> <i>[address]:port</i> <b>to [168.100.189.8]:25</b>
 275     <b>WHITELIST VETO</b> <i>[address]:port</i>
 276 </pre>
 277
 278 <p> Translation: the client at <i>[address]:port</i> connected to
 279 the backup MX address 168.100.189.8 while it was not whitelisted.
 280 The client will not be granted the temporary whitelist status, even
 281 if passes all the whitelist tests described below. </p>
 282
 283 <h2> <a name="before_220"> Tests before the 220 SMTP server greeting </a> </h2>
 284
 285 <p> The <a href="postconf.5.html#postscreen_greet_wait">postscreen_greet_wait</a> parameter specifies a short time
 286 interval before the "220 <i>text</i>..." server greeting, where
 287 <a href="postscreen.8.html">postscreen(8)</a> can run a number of tests in parallel. </p>
 288
 289 <p> When a good client passes these tests, and no "<a
 290 href="#after_220">deep protocol tests</a>" are configured, postscreen(8)
 291 adds the client to the temporary whitelist and hands off the "live"
 292 connection to a Postfix SMTP server process.  The client can then
 293 continue as if <a href="postscreen.8.html">postscreen(8)</a> never even existed (except of course
 294 for the short <a href="postconf.5.html#postscreen_greet_wait">postscreen_greet_wait</a> delay).  </p>
 295
 296 <ul>
 297
 298 <li> <a href="#pregreet"> Pregreet test </a>
 299
 300 <li> <a href="#dnsbl"> DNS White/blacklist test </a>
 301
 302 <li> <a href="#fail_before_220">When tests fail before the 220 SMTP server greeting</a>
 303
 304 </ul>
 305
 306 <h3> <a name="pregreet"> Pregreet test </a> </h3>
 307
 308 <p> The SMTP protocol is a classic example of a protocol where the
 309 server speaks before the client. <a href="postscreen.8.html">postscreen(8)</a> detects zombies
 310 that are in a hurry and that speak before their turn. This test is
 311 enabled by default. </p>
 312
 313 <p> The <a href="postconf.5.html#postscreen_greet_banner">postscreen_greet_banner</a> parameter specifies the <i>text</i>
 314 portion of a "220-<i>text</i>..." teaser banner (default: $<a href="postconf.5.html#smtpd_banner">smtpd_banner</a>).
 315 Note that this becomes the first part of a multi-line server greeting.
 316 The <a href="postscreen.8.html">postscreen(8)</a> daemon sends this before the <a href="postconf.5.html#postscreen_greet_wait">postscreen_greet_wait</a>
 317 timer is started.  The purpose of the teaser banner is to confuse
 318 zombies so that they speak before their turn. It has no effect on
 319 SMTP clients that correctly implement the protocol.  </p>
 320
 321 <p> To avoid problems with poorly-implemented SMTP engines in network
 322 appliances or network testing tools, either exclude them from all
 323 tests with the <a href="postconf.5.html#postscreen_access_list">postscreen_access_list</a> feature or else specify
 324 an empty teaser banner: </p>
 325
 326 <pre>
 327 /etc/postfix/<a href="postconf.5.html">main.cf</a>:
 328     # Exclude broken clients by whitelisting. Clients in <a href="postconf.5.html#mynetworks">mynetworks</a>
 329     # should always be whitelisted.
 330     <a href="postconf.5.html#postscreen_access_list">postscreen_access_list</a> = <a href="postconf.5.html#permit_mynetworks">permit_mynetworks</a>,
 331         <a href="cidr_table.5.html">cidr</a>:/etc/postfix/postscreen_access.cidr
 332
 333 /etc/postfix/postscreen_access.<a href="cidr_table.5.html">cidr</a>:
 334     192.168.254.0/24 permit
 335 </pre>
 336
 337 <pre>
 338 /etc/postfix/<a href="postconf.5.html">main.cf</a>:
 339     # Disable the teaser banner (try whitelisting first if you can).
 340     <a href="postconf.5.html#postscreen_greet_banner">postscreen_greet_banner</a> =
 341 </pre>
 342
 343 <p> When an SMTP client sends a command before the
 344 <a href="postconf.5.html#postscreen_greet_wait">postscreen_greet_wait</a> time has elapsed, <a href="postscreen.8.html">postscreen(8)</a> logs this as:
 345 </p>
 346
 347 <pre>
 348     <b>PREGREET</b> <i>count</i> <b>after</b> <i>time</i> <b>from</b> <i>[address]:port text...</i>
 349 </pre>
 350
 351 <p> Translation: the client at <i>[address]:port</i> sent <i>count</i>
 352 bytes before its turn to speak. This happened <i>time</i> seconds
 353 after the <a href="postconf.5.html#postscreen_greet_wait">postscreen_greet_wait</a> timer was started.  The <i>text</i>
 354 is what the client sent (truncated to 100 bytes, and with non-printable
 355 characters replaced with C-style escapes such as \r for carriage-return
 356 and \n for newline). </p>
 357
 358 <p> The <a href="postconf.5.html#postscreen_greet_action">postscreen_greet_action</a> parameter specifies the action that
 359 is taken next.  See "<a href="#fail_before_220">When tests fail
 360 before the 220 SMTP server greeting</a>" below. </p>
 361
 362 <h3> <a name="dnsbl"> DNS White/blacklist test </a> </h3>
 363
 364 <p> The <a href="postconf.5.html#postscreen_dnsbl_sites">postscreen_dnsbl_sites</a> parameter (default: empty) specifies
 365 a list of DNS blocklist servers with optional filters and weight
 366 factors (positive weights for blacklisting, negative for whitelisting).
 367 These servers will be queried in parallel with the reverse client
 368 IP address.  This test is disabled by default. </p>
 369
 370 <blockquote>
 371 <p>
 372 CAUTION: when postscreen rejects mail, its SMTP reply contains the
 373 DNSBL domain name. Use the <a href="postconf.5.html#postscreen_dnsbl_reply_map">postscreen_dnsbl_reply_map</a> feature to
 374 hide "password" information in DNSBL domain names.
 375 </p>
 376 </blockquote>
 377
 378 <p> When the <a href="postconf.5.html#postscreen_greet_wait">postscreen_greet_wait</a> time has elapsed, and the combined
 379 DNSBL score is equal to or greater than the <a href="postconf.5.html#postscreen_dnsbl_threshold">postscreen_dnsbl_threshold</a>
 380 parameter value, <a href="postscreen.8.html">postscreen(8)</a> logs this as: </p>
 381
 382 <pre>
 383     <b>DNSBL rank</b> <i>count</i> <b>for</b> <i>[address]:port</i>
 384 </pre>
 385
 386 <p> Translation: the SMTP client at <i>[address]:port</i> has a combined
 387 DNSBL score of <i>count</i>. </p>
 388
 389 <p> The <a href="postconf.5.html#postscreen_dnsbl_action">postscreen_dnsbl_action</a> parameter specifies the action that
 390 is taken when the combined DNSBL score is equal to or greater than
 391 the threshold.  See "<a href="#fail_before_220">When tests fail
 392 before the 220 SMTP server greeting</a>" below. </p>
 393
 394 <h3> <a name="fail_before_220">When tests fail before the 220 SMTP server greeting</a> </h3>
 395
 396 <p> When the client address matches the permanent blacklist, or
 397 when the client fails the pregreet or DNSBL tests, the action is
 398 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>,
 399 or <a href="postconf.5.html#postscreen_dnsbl_action">postscreen_dnsbl_action</a>, respectively. </p>
 400
 401 <dl>
 402
 403 <dt> <b>ignore</b> (default) </dt>
 404
 405 <dd> Ignore the failure of this test. Allow other tests to complete.
 406 Repeat this test the next time the client connects.  This option
 407 is useful for testing and collecting statistics without blocking
 408 mail. </dd>
 409
 410 <dt> <b>enforce</b> </dt>
 411
 412 <dd> Allow other tests to complete.  Reject attempts to deliver mail
 413 with a 550 SMTP reply, and log the helo/sender/recipient information.
 414 Repeat this test the next time the client connects. </dd>
 415
 416 <dt> <b>drop</b> </dt>
 417
 418 <dd> Drop the connection immediately with a 521 SMTP reply.  Repeat
 419 this test the next time the client connects. </dd>
 420
 421 </dl>
 422
 423 <h2> <a name="after_220">Tests after the 220 SMTP server greeting</a> </h2>
 424
 425 <p> In this phase of the protocol, <a href="postscreen.8.html">postscreen(8)</a> implements a
 426 number of "deep protocol" tests. These tests use an SMTP protocol
 427 engine that is built into the <a href="postscreen.8.html">postscreen(8)</a> server. </p>
 428
 429 <p> Important note: deep protocol tests are disabled by default.
 430 They are more intrusive than the pregreet and DNSBL tests, and they
 431 have limitations as discussed next. </p>
 432
 433 <ul>
 434
 435 <li> <p> When a good client passes the <a href="#after_220">deep
 436 protocol tests</a>, postscreen(8) adds the client to the temporary
 437 whitelist but it cannot hand off the "live" connection to a Postfix
 438 SMTP server process in the middle of the session. Instead, <a href="postscreen.8.html">postscreen(8)</a>
 439 defers mail delivery attempts with a 4XX status, logs the
 440 helo/sender/recipient information, and waits for the client to
 441 disconnect. </p>
 442
 443 <p> The next time the client connects it will be allowed to talk
 444 to a Postfix SMTP server process to deliver its mail.  To minimize the
 445 impact of this limitation, <a href="postscreen.8.html">postscreen(8)</a> gives deep protocol tests
 446 a relatively long expiration time. </p>
 447
 448 <li> <p> <a href="postscreen.8.html">postscreen(8)</a>'s built-in SMTP engine does not implement
 449 the AUTH, XCLIENT, and XFORWARD features.  AUTH support may be added
 450 in a future version. In the mean time, if you need to make these
 451 services available on port 25, then do not enable the tests after
 452 the 220 server greeting. </p>
 453
 454 </ul>
 455
 456 <p> End-user clients should connect directly to the submission
 457 service, so that they never have to deal with <a href="postscreen.8.html">postscreen(8)</a>'s tests.
 458 </p>
 459
 460 <ul>
 461
 462 <li> <a href="#pipelining">Command pipelining test</a>
 463
 464 <li> <a href="#non_smtp">Non-SMTP command test</a>
 465
 466 <li> <a href="#barelf">Bare newline test</a>
 467
 468 <li> <a href="#fail_after_220">When tests fail after the 220 SMTP server greeting</a>
 469
 470 </ul>
 471
 472 <h3> <a name="pipelining">Command pipelining test</a> </h3>
 473
 474 <p> By default, SMTP is a half-duplex protocol: the sender and
 475 receiver send one command and one response at a time.  Unlike the
 476 Postfix SMTP server, <a href="postscreen.8.html">postscreen(8)</a> does not announce support
 477 for ESMTP command pipelining.  Therefore, clients are not allowed
 478 to send multiple commands. postscreen(8)'s <a href="#after_220">deep
 479 protocol test</a> for this is disabled by default. </p>
 480
 481 <p> With "<a href="postconf.5.html#postscreen_pipelining_enable">postscreen_pipelining_enable</a> = yes", <a href="postscreen.8.html">postscreen(8)</a> detects
 482 zombies that send multiple commands, instead of sending one command
 483 and waiting for the server to reply.  </p>
 484
 485 <p> This test is opportunistically enabled when <a href="postscreen.8.html">postscreen(8)</a> has
 486 to use the built-in SMTP engine anyway. This is to make <a href="postscreen.8.html">postscreen(8)</a>
 487 logging more informative. </p>
 488
 489 <p> When a client sends multiple commands, <a href="postscreen.8.html">postscreen(8)</a> logs this
 490 as: </p>
 491
 492 <pre>
 493     <b>COMMAND PIPELINING from</b> <i>[address]:port</i> <b>after</b> <i>command</i>: <i>text</i>
 494 </pre>
 495
 496 <p> Translation: the SMTP client at <i>[address]:port</i> sent
 497 multiple SMTP commands, instead of sending one command and then
 498 waiting for the server to reply. This happened after the client
 499 sent <i>command</i>. The <i>text</i> shows part of the input that
 500 was sent too early; it is not logged with Postfix 2.8. </p>
 501
 502 <p> The <a href="postconf.5.html#postscreen_pipelining_action">postscreen_pipelining_action</a> parameter specifies the action
 503 that is taken next.  See "<a href="#fail_after_220">When tests fail
 504 after the 220 SMTP server greeting</a>" below. </p>
 505
 506 <h3> <a name="non_smtp">Non-SMTP command test</a> </h3>
 507
 508 <p> Some spambots send their mail through open proxies. A symptom
 509 of this is the usage of commands such as CONNECT and other non-SMTP
 510 commands. Just like the Postfix SMTP server's <a href="postconf.5.html#smtpd_forbidden_commands">smtpd_forbidden_commands</a>
 511 feature, <a href="postscreen.8.html">postscreen(8)</a> has an equivalent <a href="postconf.5.html#postscreen_forbidden_commands">postscreen_forbidden_commands</a>
 512 feature to block these clients. postscreen(8)'s <a href="#after_220">deep
 513 protocol test</a> for this is disabled by default.  </p>
 514
 515 <p> With "<a href="postconf.5.html#postscreen_non_smtp_command_enable">postscreen_non_smtp_command_enable</a> = yes", <a href="postscreen.8.html">postscreen(8)</a>
 516 detects zombies that send commands specified with the
 517 <a href="postconf.5.html#postscreen_forbidden_commands">postscreen_forbidden_commands</a> parameter. This also detects commands
 518 with the syntax of a message header label. The latter is a symptom
 519 that the client is sending message content after ignoring all the
 520 responses from <a href="postscreen.8.html">postscreen(8)</a> that reject mail. </p>
 521
 522 <p> This test is opportunistically enabled when <a href="postscreen.8.html">postscreen(8)</a> has
 523 to use the built-in SMTP engine anyway. This is to make <a href="postscreen.8.html">postscreen(8)</a>
 524 logging more informative.  </p>
 525
 526 <p> When a client sends non-SMTP commands, <a href="postscreen.8.html">postscreen(8)</a> logs this
 527 as: </p>
 528
 529 <pre>
 530     <b>NON-SMTP COMMAND from</b> <i>[address]:port command</i>
 531 </pre>
 532
 533 <p> Translation: the SMTP client at <i>[address]:port</i> sent a
 534 <i>command</i> that matches the <a href="postconf.5.html#postscreen_forbidden_commands">postscreen_forbidden_commands</a>
 535 parameter, or that has the syntax of a message header label. </p>
 536
 537 <p> The <a href="postconf.5.html#postscreen_non_smtp_command_action">postscreen_non_smtp_command_action</a> parameter specifies
 538 the action that is taken next.  See "<a href="#fail_after_220">When
 539 tests fail after the 220 SMTP server greeting</a>" below. </p>
 540
 541 <h3> <a name="barelf">Bare newline test</a> </h3>
 542
 543 <p> SMTP is a line-oriented protocol: lines have a limited length,
 544 and are terminated with &lt;CR&gt;&lt;LF&gt;. Lines ending in a
 545 "bare" &lt;LF&gt;, that is newline not preceded by carriage return,
 546 are not allowed in SMTP.  postscreen(8)'s <a href="#after_220">deep
 547 protocol test</a> for this is disabled by default.  </p>
 548
 549 <p> With "<a href="postconf.5.html#postscreen_bare_newline_enable">postscreen_bare_newline_enable</a> = yes", <a href="postscreen.8.html">postscreen(8)</a>
 550 detects clients that send lines ending in bare newline characters.
 551 </p>
 552
 553 <p> This test is opportunistically enabled when <a href="postscreen.8.html">postscreen(8)</a> has
 554 to use the built-in SMTP engine anyway. This is to make <a href="postscreen.8.html">postscreen(8)</a>
 555 logging more informative.  </p>
 556
 557 <p> When a client sends bare newline characters, <a href="postscreen.8.html">postscreen(8)</a> logs
 558 this as:
 559 </p>
 560
 561 <pre>
 562     <b>BARE NEWLINE from</b> <i>[address]:port</i>
 563 </pre>
 564
 565 <p> Translation: the SMTP client at <i>[address]:port</i> sent a bare
 566 newline character, that is newline not preceded by carriage
 567 return. </p>
 568
 569 <p> The <a href="postconf.5.html#postscreen_bare_newline_action">postscreen_bare_newline_action</a> parameter specifies the
 570 action that is taken next.  See "<a href="#fail_after_220">When
 571 tests fail after the 220 SMTP server greeting</a>" below. </p>
 572
 573 <h3> <a name="fail_after_220">When tests fail after the 220 SMTP server greeting</a> </h3>
 574
 575 <p> When the client fails the pipelining, non-SMTP command or bare
 576 newline tests, the action is specified with <a href="postconf.5.html#postscreen_pipelining_action">postscreen_pipelining_action</a>,
 577 <a href="postconf.5.html#postscreen_non_smtp_command_action">postscreen_non_smtp_command_action</a> or <a href="postconf.5.html#postscreen_bare_newline_action">postscreen_bare_newline_action</a>,
 578 respectively. </p>
 579
 580 <dl>
 581
 582 <dt> <b>ignore</b> (default for bare newline) </dt>
 583
 584 <dd> Ignore the failure of this test. Allow other tests to complete.
 585 Do NOT repeat this test before the result from some other test
 586 expires.
 587
 588 This option is useful for testing and collecting statistics without
 589 blocking mail permanently. </dd>
 590
 591 <dt> <b>enforce</b> (default for pipelining) </dt>
 592
 593 <dd> Allow other tests to complete.  Reject attempts to deliver
 594 mail with a 550 SMTP reply, and log the helo/sender/recipient
 595 information.  Repeat this test the next time the client connects.
 596 </dd>
 597
 598 <dt> <b>drop</b> (default for non-SMTP commands) </dt>
 599
 600 <dd> Drop the connection immediately with a 521 SMTP reply.  Repeat
 601 this test the next time the client connects.  This action is
 602 compatible with the Postfix SMTP server's <a href="postconf.5.html#smtpd_forbidden_commands">smtpd_forbidden_commands</a>
 603 feature. </dd>
 604
 605 </dl>
 606
 607 <h2> <a name="other_error">Other errors</a> </h2>
 608
 609 <p> When an SMTP client hangs up unexpectedly during any tests,
 610 <a href="postscreen.8.html">postscreen(8)</a> logs this as: </p>
 611
 612 <pre>
 613     <b>HANGUP after</b> <i>time</i> <b>from</b> <i>[address]:port</i> <b>in</b> <i>test name</i>
 614 </pre>
 615
 616 <p> Translation: the SMTP client at <i>[address]:port</i> disconnected
 617 unexpectedly, <i>time</i> seconds after the start of the
 618 test named <i>test name</i>. </p>
 619
 620 <!--
 621
 622 <p> While an unexpired penalty is in effect, an SMTP client is not
 623 allowed to pass any tests, and  <a href="postscreen.8.html">postscreen(8)</a> logs each connection
 624 with the remaining amount of penalty time as: </p>
 625
 626 <pre>
 627     <b>PENALTY</b> <i>time</i> <b>for</b> <i>[address]:port</i>
 628 </pre>
 629
 630 <p> During this time, all attempts by the client to deliver mail
 631 will be deferred with a 450 SMTP status.  </p>
 632
 633 -->
 634
 635 <p> The following errors are reported by the built-in SMTP engine.
 636 This engine never accepts mail, therefore it has per-session limits
 637 on the number of commands and on the session length. </p>
 638
 639 <pre>
 640     <b>COMMAND TIME LIMIT</b> <b>from</b> <i>[address]:port</i>
 641 </pre>
 642
 643 <p> Translation: the SMTP client at <i>[address]:port</i> reached the
 644 per-command time limit as specified with the <a href="postconf.5.html#postscreen_command_time_limit">postscreen_command_time_limit</a>
 645 parameter.  The session is terminated immediately. </p>
 646
 647 <pre>
 648     <b>COMMAND COUNT LIMIT from</b> <i>[address]:port</i>
 649 </pre>
 650
 651 <p> Translation: the SMTP client at <i>[address]:port</i> reached the
 652 per-session command count limit as specified with the
 653 <a href="postconf.5.html#postscreen_command_count_limit">postscreen_command_count_limit</a> parameter.  The session is terminated
 654 immediately. </p>
 655
 656 <pre>
 657     <b>COMMAND LENGTH LIMIT from</b> <i>[address]:port</i>
 658 </pre>
 659
 660 <p> Translation: the SMTP client at <i>[address]:port</i> reached the
 661 per-command length limit, as specified with the <a href="postconf.5.html#line_length_limit">line_length_limit</a>
 662 parameter.  The session is terminated immediately. </p>
 663
 664 <p> When an SMTP client makes too many connections at the same time,
 665 or when all <a href="postscreen.8.html">postscreen(8)</a> ports are busy, <a href="postscreen.8.html">postscreen(8)</a> rejects the
 666 connection with a 421 status code and logs: </p>
 667
 668 <pre>
 669     <b>NOQUEUE: reject: CONNECT from</b> <i>[address]:port</i><b>: too many connections</b>
 670     <b>NOQUEUE: reject: CONNECT from</b> <i>[address]:port</i><b>: all server ports busy</b>
 671 </pre>
 672
 673 <p> The <a href="postconf.5.html#postscreen_client_connection_count_limit">postscreen_client_connection_count_limit</a> and
 674 <a href="postconf.5.html#postscreen_pre_queue_limit">postscreen_pre_queue_limit</a> parameters control these limits.  </p>
 675
 676 <h2> <a name="victory">When all tests succeed</a> </h2>
 677
 678 <p> When a new SMTP client passes all tests (i.e. it is not whitelisted
 679 via some mechanism), <a href="postscreen.8.html">postscreen(8)</a> logs this as: </p>
 680
 681 <pre>
 682     <b>PASS NEW</b> <i>[address]:port</i>
 683 </pre>
 684
 685 <p> Where <i>[address]:port</i> are the client IP address and port.
 686 Then, <a href="postscreen.8.html">postscreen(8)</a>
 687 creates a temporary whitelist entry that excludes the client IP
 688 address from further tests until the temporary whitelist entry
 689 expires, as controlled with the postscreen_*_ttl parameters. </p>
 690
 691 <p> When no "<a href="#after_220">deep protocol tests</a>" are
 692 configured, <a href="postscreen.8.html">postscreen(8)</a> hands off the "live" connection to a Postfix
 693 SMTP server process.  The client can then continue as if <a href="postscreen.8.html">postscreen(8)</a>
 694 never even existed (except for the short <a href="postconf.5.html#postscreen_greet_wait">postscreen_greet_wait</a> delay).
 695 </p>
 696
 697 <p> When any "<a href="#after_220">deep protocol tests</a>" are
 698 configured, <a href="postscreen.8.html">postscreen(8)</a> cannot hand off the "live" connection to
 699 a Postfix SMTP server process in the middle of the session.  Instead,
 700 <a href="postscreen.8.html">postscreen(8)</a> defers mail delivery attempts with a 4XX status, logs
 701 the helo/sender/recipient information, and waits for the client to
 702 disconnect.  The next time the client connects it will be allowed
 703 to talk to a Postfix SMTP server process to deliver its mail.
 704 <a href="postscreen.8.html">postscreen(8)</a> mitigates the impact of this limitation by giving
 705 <a href="#after_220">deep protocol tests</a> a long expiration
 706 time. </p>
 707
 708 <h2> <a name="config"> Configuring the postscreen(8) service</a>
 709 </h2>
 710
 711 <p> <a href="postscreen.8.html">postscreen(8)</a> has been tested on FreeBSD [4-8], Linux 2.[4-6]
 712 and Solaris 9 systems. </p>
 713
 714 <ul>
 715
 716 <li> <a href="#enable"> Turning on postscreen(8) without blocking
 717 mail</a>
 718
 719 <li> <a href="#starttls"> postscreen(8) TLS configuration </a>
 720
 721 <li> <a href="#blocking"> Blocking mail with postscreen(8) </a>
 722
 723 <li> <a href="#turnoff"> Turning off postscreen(8) </a>
 724
 725 </ul>
 726
 727 <h3> <a name="enable"> Turning on postscreen(8) without blocking mail</a> </h3>
 728
 729 <p> To enable the <a href="postscreen.8.html">postscreen(8)</a> service and log client information
 730 without blocking mail: </p>
 731
 732 <ol>
 733
 734 <li> <p> Make sure that local clients and systems with non-standard
 735 SMTP implementations are excluded from any <a href="postscreen.8.html">postscreen(8)</a> tests. The
 736 default is to exclude all clients in <a href="postconf.5.html#mynetworks">mynetworks</a>. To exclude additional
 737 clients, for example, third-party performance monitoring tools (these
 738 tend to have broken SMTP implementations): </p>
 739
 740 <pre>
 741 /etc/postfix/<a href="postconf.5.html">main.cf</a>:
 742     # Exclude broken clients by whitelisting. Clients in <a href="postconf.5.html#mynetworks">mynetworks</a>
 743     # should always be whitelisted.
 744     <a href="postconf.5.html#postscreen_access_list">postscreen_access_list</a> = <a href="postconf.5.html#permit_mynetworks">permit_mynetworks</a>,
 745         <a href="cidr_table.5.html">cidr</a>:/etc/postfix/postscreen_access.cidr
 746
 747 /etc/postfix/postscreen_access.<a href="cidr_table.5.html">cidr</a>:
 748     192.168.254.0/24 permit
 749 </pre>
 750
 751 <li> <p> Comment out the "<tt>smtp  inet ... smtpd</tt>" service
 752 in <a href="master.5.html">master.cf</a>, including any "<tt>-o parameter=value</tt>" entries
 753 that follow.  </p>
 754
 755 <pre>
 756 /etc/postfix/<a href="master.5.html">master.cf</a>:
 757     #smtp      inet  n       -       n       -       -       smtpd
 758     #    -o parameter=value ...
 759 </pre>
 760
 761 <li> <p> Uncomment the new "<tt>smtpd pass ... smtpd</tt>" service
 762 in <a href="master.5.html">master.cf</a>, and duplicate any "<tt>-o parameter=value</tt>" entries
 763 from the smtpd service that was commented out in the previous step.
 764 </p>
 765
 766 <pre>
 767 /etc/postfix/<a href="master.5.html">master.cf</a>:
 768     smtpd     pass  -       -       n       -       -       smtpd
 769         -o parameter=value ...
 770 </pre>
 771
 772 <li> <p> Uncomment the new "<tt>smtp inet ... postscreen</tt>"
 773 service in <a href="master.5.html">master.cf</a>. </p>
 774
 775 <pre>
 776 /etc/postfix/<a href="master.5.html">master.cf</a>:
 777     smtp      inet  n       -       n       -       1       postscreen
 778 </pre>
 779
 780 <li> <p> Uncomment the new "<tt>tlsproxy unix ... tlsproxy</tt>"
 781 service in <a href="master.5.html">master.cf</a>.  This service implements STARTTLS support for
 782 <a href="postscreen.8.html">postscreen(8)</a>. </p>
 783
 784 <pre>
 785 /etc/postfix/<a href="master.5.html">master.cf</a>:
 786     tlsproxy  unix  -       -       n       -       0       tlsproxy
 787 </pre>
 788
 789 <li> <p> Uncomment the new "<tt>dnsblog  unix ... dnsblog</tt>"
 790 service in <a href="master.5.html">master.cf</a>.  This service does DNSBL lookups for <a href="postscreen.8.html">postscreen(8)</a>
 791 and logs results. </p>
 792
 793 <pre>
 794 /etc/postfix/<a href="master.5.html">master.cf</a>:
 795     dnsblog   unix  -       -       n       -       0       dnsblog
 796 </pre>
 797
 798 <li> <p> To enable DNSBL lookups, list some DNS blocklist sites in
 799 <a href="postconf.5.html">main.cf</a>, separated by whitespace. Different sites can have different
 800 weights. For example:
 801
 802 <pre>
 803 /etc/postfix/<a href="postconf.5.html">main.cf</a>:
 804     <a href="postconf.5.html#postscreen_dnsbl_threshold">postscreen_dnsbl_threshold</a> = 2
 805     <a href="postconf.5.html#postscreen_dnsbl_sites">postscreen_dnsbl_sites</a> = zen.spamhaus.org*2
 806         bl.spamcop.net*1 b.barracudacentral.org*1
 807 </pre>
 808
 809 <p> Note: if your DNSBL queries have a "secret" in the domain name,
 810 you must censor this information from the <a href="postscreen.8.html">postscreen(8)</a> SMTP replies.
 811 For example: </p>
 812
 813 <pre>
 814 /etc/postfix/<a href="postconf.5.html">main.cf</a>:
 815     <a href="postconf.5.html#postscreen_dnsbl_reply_map">postscreen_dnsbl_reply_map</a> = <a href="DATABASE_README.html#types">texthash</a>:/etc/postfix/dnsbl_reply
 816 </pre>
 817
 818 <pre>
 819 /etc/postfix/dnsbl_reply:
 820     # Secret DNSBL name        Name in <a href="postscreen.8.html">postscreen(8)</a> replies
 821     secret.zen.spamhaus.org    zen.spamhaus.org
 822 </pre>
 823
 824 <p> The <a href="DATABASE_README.html#types">texthash</a>: format is similar to hash: except that there is
 825 no need to run <a href="postmap.1.html">postmap(1)</a> before the file can be used, and that it
 826 does not detect changes after the file is read. It is new with
 827 Postfix version 2.8. </p>
 828
 829 <li> <p> Read the new configuration with "<tt>postfix reload</tt>".
 830 </p>
 831
 832 </ol>
 833
 834 <p> Notes: </p>
 835
 836 <ul>
 837
 838 <li> <p> Some <a href="postscreen.8.html">postscreen(8)</a> configuration parameters implement
 839 stress-dependent behavior. This is supported only when the default
 840 value is stress-dependent (that is, it looks like ${stress?X}${stress:Y}).
 841 Other parameters always evaluate as if the stress value is the empty
 842 string. </p>
 843
 844 <li> <p> See "<a href="#before_220">Tests before the 220 SMTP server
 845 greeting</a>" for details about the logging from these postscreen(8)
 846 tests. </p>
 847
 848 <li> <p> If you run Postfix 2.6 or earlier you must stop and start
 849 the master daemon ("<tt>postfix stop; postfix start</tt>").  This
 850 is needed because the Postfix "pass" master service type did not
 851 work reliably on all systems. </p>
 852
 853 </ul>
 854
 855 <h3> <a name="starttls"> postscreen(8) TLS configuration </a> </h3>
 856
 857 <p> <a href="postscreen.8.html">postscreen(8)</a> TLS support is available for remote SMTP clients
 858 that aren't whitelisted, including clients that need to renew their
 859 temporary whitelist status.  When a remote SMTP client requests TLS
 860 service, <a href="postscreen.8.html">postscreen(8)</a> invisibly hands off the connection to a
 861 <a href="tlsproxy.8.html">tlsproxy(8)</a> process. Then, <a href="tlsproxy.8.html">tlsproxy(8)</a> encrypts and decrypts the
 862 traffic between <a href="postscreen.8.html">postscreen(8)</a> and the remote SMTP client. One
 863 <a href="tlsproxy.8.html">tlsproxy(8)</a> process can handle multiple SMTP sessions. The number
 864 of <a href="tlsproxy.8.html">tlsproxy(8)</a> processes slowly increases with server load, but it
 865 should always be much smaller than the number of <a href="postscreen.8.html">postscreen(8)</a> TLS
 866 sessions.  </p>
 867
 868 <p> TLS support for <a href="postscreen.8.html">postscreen(8)</a> and <a href="tlsproxy.8.html">tlsproxy(8)</a> uses the same
 869 parameters as with <a href="smtpd.8.html">smtpd(8)</a>. We recommend that you keep the relevant
 870 configuration parameters in <a href="postconf.5.html">main.cf</a>.  If you must specify "-o
 871 smtpd_mumble=value" parameter overrides in <a href="master.5.html">master.cf</a> for a
 872 postscreen-protected <a href="smtpd.8.html">smtpd(8)</a> service, then you should specify those
 873 same parameter overrides for the <a href="postscreen.8.html">postscreen(8)</a> and <a href="tlsproxy.8.html">tlsproxy(8)</a>
 874 services. </p>
 875
 876 <h3> <a name="blocking"> Blocking mail with postscreen(8) </a> </h3>
 877
 878 <p> For compatibility with <a href="smtpd.8.html">smtpd(8)</a>, <a href="postscreen.8.html">postscreen(8)</a> implements the
 879 <a href="postconf.5.html#soft_bounce">soft_bounce</a> safety feature. This causes Postfix to reject mail with
 880 a "try again" reply code. </p>
 881
 882 <ul>
 883
 884 <li> <p> To turn this on for all of Postfix, specify "<tt><a href="postconf.5.html#soft_bounce">soft_bounce</a>
 885 = yes</tt>" in <a href="postconf.5.html">main.cf</a>. </p>
 886
 887 <li> <p> To turn this on for <a href="postscreen.8.html">postscreen(8)</a> only, append "<tt>-o
 888 <a href="postconf.5.html#soft_bounce">soft_bounce</a>=yes</tt>" (note: NO SPACES around '=') to the postscreen
 889 entry in <a href="master.5.html">master.cf</a>. <p>
 890
 891 </ul>
 892
 893 <p> Execute "<tt>postfix reload</tt>" to make the change effective. </p>
 894
 895 <p> After testing, do not forget to remove the <a href="postconf.5.html#soft_bounce">soft_bounce</a> feature,
 896 otherwise senders won't receive their non-delivery notification
 897 until many days later.  </p>
 898
 899 <p> To use the <a href="postscreen.8.html">postscreen(8)</a> service to block mail, edit <a href="postconf.5.html">main.cf</a> and
 900 specify one or more of: </p>
 901
 902 <ul>
 903
 904 <li> <p> "<tt><a href="postconf.5.html#postscreen_dnsbl_action">postscreen_dnsbl_action</a> = enforce</tt>", to reject
 905 clients that are on DNS blocklists, and to log the helo/sender/recipient
 906 information. With good DNSBLs this reduces the amount of load on
 907 Postfix SMTP servers dramatically.  </p>
 908
 909 <li> <p> "<tt><a href="postconf.5.html#postscreen_greet_action">postscreen_greet_action</a> = enforce</tt>", to reject
 910 clients that talk before their turn, and to log the helo/sender/recipient
 911 information. This stops over half of all known-to-be illegitimate
 912 connections to Wietse's mail server. It is backup protection for
 913 zombies that haven't yet been blacklisted. </p>
 914
 915 <li> <p> You can also enable "<a href="#after_220">deep protocol
 916 tests</a>", but these are more intrusive than the pregreet or DNSBL
 917 tests. </p>
 918
 919 <p> When a good client passes the "<a href="#after_220">deep
 920 protocol tests</a>", postscreen(8) adds the client to the temporary
 921 whitelist but it cannot hand off the "live" connection to a Postfix
 922 SMTP server process in the middle of the session. Instead, <a href="postscreen.8.html">postscreen(8)</a>
 923 defers mail delivery attempts with a 4XX status, logs the
 924 helo/sender/recipient information, and waits for the client to
 925 disconnect. </p>
 926
 927 <p> When the good client comes back in a later session, it is allowed
 928 to talk directly to a Postfix SMTP server.  See "after_220 <a
 929 href="#after_220">Tests after the 220 SMTP server greeting</a> above
 930 for limitations with AUTH and other features that clients may need.
 931 </p>
 932
 933 <p> An unexpected benefit from "<a href="#after_220">deep protocol
 934 tests</a>" is that some "good" clients don't return after the 4XX
 935 reply; these clients were not so good after all.  Wietse enables
 936 "<a href="#after_220">deep protocol tests</a>" on his own internet-facing
 937 mail server.  </p>
 938
 939 <li> <p> There is also support for permanent blacklisting and
 940 whitelisting; see the description of the <a href="postconf.5.html#postscreen_access_list">postscreen_access_list</a>
 941 parameter for details. </p>
 942
 943 </ul>
 944
 945 <h3> <a name="turnoff"> Turning off postscreen(8) </a> </h3>
 946
 947 <p> To turn off <a href="postscreen.8.html">postscreen(8)</a> and handle mail directly with Postfix
 948 SMTP server processes: </p>
 949
 950 <ol>
 951
 952 <li> <p> Comment out the "<tt>smtp inet ... postscreen</tt>" service
 953 in <a href="master.5.html">master.cf</a>, including any "<tt>-o parameter=value</tt>" entries
 954 that follow. </p>
 955
 956 <pre>
 957 /etc/postfix/<a href="master.5.html">master.cf</a>:
 958     #smtp      inet  n       -       n       -       1       postscreen
 959     #    -o parameter=value ...
 960 </pre>
 961
 962 <li> <p> Comment out the "<tt>dnsblog  unix ... dnsblog</tt>" service
 963 in <a href="master.5.html">master.cf</a>.  </p>
 964
 965 <pre>
 966 /etc/postfix/<a href="master.5.html">master.cf</a>:
 967     #dnsblog   unix  -       -       n       -       0       dnsblog
 968 </pre>
 969
 970 <li> <p> Comment out the "<tt>smtpd pass ... smtpd</tt>" service
 971 in <a href="master.5.html">master.cf</a>, including any "<tt>-o parameter=value</tt>" entries
 972 that follow. </p>
 973
 974 <pre>
 975 /etc/postfix/<a href="master.5.html">master.cf</a>:
 976     #smtpd     pass  -       -       n       -       -       smtpd
 977     #    -o parameter=value ...
 978 </pre>
 979
 980 <li> <p> Comment out the "<tt>tlsproxy unix ... tlsproxy</tt>"
 981 service in <a href="master.5.html">master.cf</a>, including any "<tt>-o parameter=value</tt>"
 982 entries that follow. </p>
 983
 984 <pre>
 985 /etc/postfix/<a href="master.5.html">master.cf</a>:
 986     #tlsproxy  unix  -       -       n       -       0       tlsproxy
 987     #    -o parameter=value ...
 988 </pre>
 989
 990 <li> <p> Uncomment the "<tt>smtp  inet ... smtpd</tt>" service in
 991 <a href="master.5.html">master.cf</a>, including any "<tt>-o parameter=value</tt>" entries that
 992 may follow.  </p>
 993
 994 <pre>
 995 /etc/postfix/<a href="master.5.html">master.cf</a>:
 996     smtp       inet  n       -       n       -       -       smtpd
 997         -o parameter=value ...
 998 </pre>
 999
1000 <li> <p> Read the new configuration with "<tt>postfix reload</tt>".
1001 </p>
1002
1003 </ol>
1004
1005 <h2> <a name="historical"> Historical notes and credits </a> </h2>
1006
1007 <p> Many ideas in <a href="postscreen.8.html">postscreen(8)</a> were explored in earlier work by
1008 Michael Tokarev, in OpenBSD spamd, and in MailChannels Traffic
1009 Control. </p>
1010
1011 <p> Wietse threw together a crude prototype with pregreet and dnsbl
1012 support in June 2009, because he needed something new for a Mailserver
1013 conference presentation in July. Ralf Hildebrandt ran this code on
1014 several servers to collect real-world statistics. This version used
1015 the <a href="dnsblog.8.html">dnsblog(8)</a> ad-hoc DNS client program. </p>
1016
1017 <p> Wietse needed new material for a LISA conference presentation
1018 in November 2010, so he added support for DNSBL weights and filters
1019 in August, followed by a major code rewrite, deep protocol tests,
1020 helo/sender/recipient logging, and stress-adaptive behavior in
1021 September. Ralf Hildebrandt ran this code on several servers to
1022 collect real-world statistics. This version still used the embarrassing
1023 <a href="dnsblog.8.html">dnsblog(8)</a> ad-hoc DNS client program.  </p>
1024
1025 <p> Wietse added STARTTLS support in December 2010. This makes
1026 <a href="postscreen.8.html">postscreen(8)</a> usable for sites that require TLS support.  The
1027 implementation introduces the <a href="tlsproxy.8.html">tlsproxy(8)</a> event-driven TLS proxy
1028 that decrypts/encrypts the sessions for multiple SMTP clients. </p>
1029
1030 </body>
1031
1032 </html>
1033