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 </ul>
 154
 155 <h3> <a name="perm_white_black"> Permanent white/blacklist test </a> </h3>
 156
 157 <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>)
 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>
 161
 162 <p> Example: </p>
 163
 164 <pre>
 165 /etc/postfix/<a href="postconf.5.html">main.cf</a>:
 166     <a href="postconf.5.html#postscreen_access_list">postscreen_access_list</a> = <a href="postconf.5.html#permit_mynetworks">permit_mynetworks</a>,
 167         <a href="cidr_table.5.html">cidr</a>:/etc/postfix/postscreen_access.cidr
 168
 169 /etc/postfix/postscreen_access.<a href="cidr_table.5.html">cidr</a>:
 170    # Rules are evaluated in the order as specified.
 171    # Blacklist 192.168.* except 192.168.0.1.
 172    192.168.0.1          permit
 173    192.168.0.0/16       reject
 174 </pre>
 175
 176 <p> See the <a href="postconf.5.html#postscreen_access_list">postscreen_access_list</a> manpage documentation for more
 177 details.  </p>
 178
 179 <p> When the SMTP client address matches a "permit" action,
 180 <a href="postscreen.8.html">postscreen(8)</a> logs this with the client address and port number as:
 181 </p>
 182
 183 <pre>
 184     <b>WHITELISTED</b> <i>[address]:port</i>
 185 </pre>
 186
 187 <p> The whitelist action is not configurable: immediately hand off the
 188 connection to a Postfix SMTP server process. </p>
 189
 190 <p> When the SMTP client address matches a "reject" action,
 191 <a href="postscreen.8.html">postscreen(8)</a> logs this with the client address and port number as:
 192 </p>
 193
 194 <pre>
 195     <b>BLACKLISTED</b> <i>[address]:port</i>
 196 </pre>
 197
 198 <p> The <a href="postconf.5.html#postscreen_blacklist_action">postscreen_blacklist_action</a> 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>
 201
 202 <h3> <a name="temp_white"> Temporary whitelist test </a> </h3>
 203
 204 <p> The <a href="postscreen.8.html">postscreen(8)</a> daemon maintains a <i>temporary</i>
 205 whitelist for SMTP client IP addresses that have passed all
 206 the tests described below. The <a href="postconf.5.html#postscreen_cache_map">postscreen_cache_map</a> 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>
 210
 211 <p> When the SMTP client address appears on the temporary
 212 whitelist, <a href="postscreen.8.html">postscreen(8)</a> logs this with the client address and port
 213 number as: </p>
 214
 215 <pre>
 216     <b>PASS OLD</b> <i>[address]:port</i>
 217 </pre>
 218
 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>
 224
 225 <h2> <a name="before_220"> Tests before the 220 SMTP server greeting </a> </h2>
 226
 227 <p> The <a href="postconf.5.html#postscreen_greet_wait">postscreen_greet_wait</a> parameter specifies a short time
 228 interval before the "220 <i>text</i>..." server greeting, where
 229 <a href="postscreen.8.html">postscreen(8)</a> can run a number of tests in parallel. </p>
 230
 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 <a href="postscreen.8.html">postscreen(8)</a> never even existed (except of course
 236 for the short <a href="postconf.5.html#postscreen_greet_wait">postscreen_greet_wait</a> delay).  </p>
 237
 238 <ul>
 239
 240 <li> <a href="#pregreet"> Pregreet test </a>
 241
 242 <li> <a href="#dnsbl"> DNS White/blacklist test </a>
 243
 244 <li> <a href="#fail_before_220">When tests fail before the 220 SMTP server greeting</a>
 245
 246 </ul>
 247
 248 <h3> <a name="pregreet"> Pregreet test </a> </h3>
 249
 250 <p> The SMTP protocol is a classic example of a protocol where the
 251 server speaks before the client. <a href="postscreen.8.html">postscreen(8)</a> detects zombies
 252 that are in a hurry and that speak before their turn. This test is
 253 enabled by default. </p>
 254
 255 <p> The <a href="postconf.5.html#postscreen_greet_banner">postscreen_greet_banner</a> parameter specifies the <i>text</i>
 256 portion of a "220-<i>text</i>..." teaser banner (default: $<a href="postconf.5.html#smtpd_banner">smtpd_banner</a>).
 257 Note that this becomes the first part of a multi-line server greeting.
 258 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>
 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>
 262
 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 <a href="postconf.5.html#postscreen_access_list">postscreen_access_list</a> feature or else specify
 266 an empty teaser banner: </p>
 267
 268 <pre>
 269 /etc/postfix/<a href="postconf.5.html">main.cf</a>:
 270     # Exclude broken clients by whitelisting. Clients in <a href="postconf.5.html#mynetworks">mynetworks</a>
 271     # should always be whitelisted.
 272     <a href="postconf.5.html#postscreen_access_list">postscreen_access_list</a> = <a href="postconf.5.html#permit_mynetworks">permit_mynetworks</a>,
 273         <a href="cidr_table.5.html">cidr</a>:/etc/postfix/postscreen_access.cidr
 274
 275 /etc/postfix/postscreen_access.<a href="cidr_table.5.html">cidr</a>:
 276     192.168.254.0/24 permit
 277 </pre>
 278
 279 <pre>
 280 /etc/postfix/<a href="postconf.5.html">main.cf</a>:
 281     # Disable the teaser banner (try whitelisting first if you can).
 282     <a href="postconf.5.html#postscreen_greet_banner">postscreen_greet_banner</a> =
 283 </pre>
 284
 285 <p> When an SMTP client sends a command before the
 286 <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:
 287 </p>
 288
 289 <pre>
 290     <b>PREGREET</b> <i>count</i> <b>after</b> <i>time</i> <b>from</b> <i>[address]:port text...</i>
 291 </pre>
 292
 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 <a href="postconf.5.html#postscreen_greet_wait">postscreen_greet_wait</a> 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>
 299
 300 <p> The <a href="postconf.5.html#postscreen_greet_action">postscreen_greet_action</a> 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>
 303
 304 <h3> <a name="dnsbl"> DNS White/blacklist test </a> </h3>
 305
 306 <p> The <a href="postconf.5.html#postscreen_dnsbl_sites">postscreen_dnsbl_sites</a> 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>
 311
 312 <blockquote>
 313 <p>
 314 CAUTION: when postscreen rejects mail, its SMTP reply contains the
 315 DNSBL domain name. Use the <a href="postconf.5.html#postscreen_dnsbl_reply_map">postscreen_dnsbl_reply_map</a> feature to
 316 hide "password" information in DNSBL domain names.
 317 </p>
 318 </blockquote>
 319
 320 <p> When the <a href="postconf.5.html#postscreen_greet_wait">postscreen_greet_wait</a> time has elapsed, and the combined
 321 DNSBL score is equal to or greater than the <a href="postconf.5.html#postscreen_dnsbl_threshold">postscreen_dnsbl_threshold</a>
 322 parameter value, <a href="postscreen.8.html">postscreen(8)</a> logs this as: </p>
 323
 324 <pre>
 325     <b>DNSBL rank</b> <i>count</i> <b>for</b> <i>[address]:port</i>
 326 </pre>
 327
 328 <p> Translation: the SMTP client at <i>[address]:port</i> has a combined
 329 DNSBL score of <i>count</i>. </p>
 330
 331 <p> The <a href="postconf.5.html#postscreen_dnsbl_action">postscreen_dnsbl_action</a> 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>
 335
 336 <h3> <a name="fail_before_220">When tests fail before the 220 SMTP server greeting</a> </h3>
 337
 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 <a href="postconf.5.html#postscreen_blacklist_action">postscreen_blacklist_action</a>, <a href="postconf.5.html#postscreen_greet_action">postscreen_greet_action</a>,
 341 or <a href="postconf.5.html#postscreen_dnsbl_action">postscreen_dnsbl_action</a>, respectively. </p>
 342
 343 <dl>
 344
 345 <dt> <b>ignore</b> (default) </dt>
 346
 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
 350 mail. </dd>
 351
 352 <dt> <b>enforce</b> </dt>
 353
 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>
 357
 358 <dt> <b>drop</b> </dt>
 359
 360 <dd> Drop the connection immediately with a 521 SMTP reply.  Repeat
 361 this test the next time the client connects. </dd>
 362
 363 </dl>
 364
 365 <h2> <a name="after_220">Tests after the 220 SMTP server greeting</a> </h2>
 366
 367 <p> In this phase of the protocol, <a href="postscreen.8.html">postscreen(8)</a> implements a
 368 number of "deep protocol" tests. These tests use an SMTP protocol
 369 engine that is built into the <a href="postscreen.8.html">postscreen(8)</a> server. </p>
 370
 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>
 374
 375 <ul>
 376
 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, <a href="postscreen.8.html">postscreen(8)</a>
 381 defers mail delivery attempts with a 4XX status, logs the
 382 helo/sender/recipient information, and waits for the client to
 383 disconnect. </p>
 384
 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, <a href="postscreen.8.html">postscreen(8)</a> gives deep protocol tests
 388 a relatively long expiration time. </p>
 389
 390 <li> <p> <a href="postscreen.8.html">postscreen(8)</a>'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>
 395
 396 </ul>
 397
 398 <p> End-user clients should connect directly to the submission
 399 service, so that they never have to deal with <a href="postscreen.8.html">postscreen(8)</a>'s tests.
 400 </p>
 401
 402 <ul>
 403
 404 <li> <a href="#pipelining">Command pipelining test</a>
 405
 406 <li> <a href="#non_smtp">Non-SMTP command test</a>
 407
 408 <li> <a href="#barelf">Bare newline test</a>
 409
 410 <li> <a href="#fail_after_220">When tests fail after the 220 SMTP server greeting</a>
 411
 412 </ul>
 413
 414 <h3> <a name="pipelining">Command pipelining test</a> </h3>
 415
 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, <a href="postscreen.8.html">postscreen(8)</a> 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>
 422
 423 <p> With "<a href="postconf.5.html#postscreen_pipelining_enable">postscreen_pipelining_enable</a> = yes", <a href="postscreen.8.html">postscreen(8)</a> detects
 424 zombies that send multiple commands, instead of sending one command
 425 and waiting for the server to reply.  </p>
 426
 427 <p> This test is opportunistically enabled when <a href="postscreen.8.html">postscreen(8)</a> has
 428 to use the built-in SMTP engine anyway. This is to make <a href="postscreen.8.html">postscreen(8)</a>
 429 logging more informative. </p>
 430
 431 <p> When a client sends multiple commands, <a href="postscreen.8.html">postscreen(8)</a> logs this
 432 as: </p>
 433
 434 <pre>
 435     <b>COMMAND PIPELINING from</b> <i>[address]:port</i> <b>after</b> <i>command</i>: <i>text</i>
 436 </pre>
 437
 438 <p> Translation: the SMTP client at <i>[address]:port</i> sent
 439 multiple SMTP commands, instead of sending one command and then
 440 waiting for the server to reply. This happened after the client
 441 sent <i>command</i>. The <i>text</i> shows part of the input that
 442 was sent too early; it is not logged with Postfix 2.8. </p>
 443
 444 <p> The <a href="postconf.5.html#postscreen_pipelining_action">postscreen_pipelining_action</a> parameter specifies the action
 445 that is taken next.  See "<a href="#fail_after_220">When tests fail
 446 after the 220 SMTP server greeting</a>" below. </p>
 447
 448 <h3> <a name="non_smtp">Non-SMTP command test</a> </h3>
 449
 450 <p> Some spambots send their mail through open proxies. A symptom
 451 of this is the usage of commands such as CONNECT and other non-SMTP
 452 commands. Just like the Postfix SMTP server's <a href="postconf.5.html#smtpd_forbidden_commands">smtpd_forbidden_commands</a>
 453 feature, <a href="postscreen.8.html">postscreen(8)</a> has an equivalent <a href="postconf.5.html#postscreen_forbidden_commands">postscreen_forbidden_commands</a>
 454 feature to block these clients. postscreen(8)'s <a href="#after_220">deep
 455 protocol test</a> for this is disabled by default.  </p>
 456
 457 <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>
 458 detects zombies that send commands specified with the
 459 <a href="postconf.5.html#postscreen_forbidden_commands">postscreen_forbidden_commands</a> parameter. This also detects commands
 460 with the syntax of a message header label. The latter is a symptom
 461 that the client is sending message content after ignoring all the
 462 responses from <a href="postscreen.8.html">postscreen(8)</a> that reject mail. </p>
 463
 464 <p> This test is opportunistically enabled when <a href="postscreen.8.html">postscreen(8)</a> has
 465 to use the built-in SMTP engine anyway. This is to make <a href="postscreen.8.html">postscreen(8)</a>
 466 logging more informative.  </p>
 467
 468 <p> When a client sends non-SMTP commands, <a href="postscreen.8.html">postscreen(8)</a> logs this
 469 as: </p>
 470
 471 <pre>
 472     <b>NON-SMTP COMMAND from</b> <i>[address]:port command</i>
 473 </pre>
 474
 475 <p> Translation: the SMTP client at <i>[address]:port</i> sent a
 476 <i>command</i> that matches the <a href="postconf.5.html#postscreen_forbidden_commands">postscreen_forbidden_commands</a>
 477 parameter, or that has the syntax of a message header label. </p>
 478
 479 <p> The <a href="postconf.5.html#postscreen_non_smtp_command_action">postscreen_non_smtp_command_action</a> parameter specifies
 480 the action that is taken next.  See "<a href="#fail_after_220">When
 481 tests fail after the 220 SMTP server greeting</a>" below. </p>
 482
 483 <h3> <a name="barelf">Bare newline test</a> </h3>
 484
 485 <p> SMTP is a line-oriented protocol: lines have a limited length,
 486 and are terminated with &lt;CR&gt;&lt;LF&gt;. Lines ending in a
 487 "bare" &lt;LF&gt;, that is newline not preceded by carriage return,
 488 are not allowed in SMTP.  postscreen(8)'s <a href="#after_220">deep
 489 protocol test</a> for this is disabled by default.  </p>
 490
 491 <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>
 492 detects clients that send lines ending in bare newline characters.
 493 </p>
 494
 495 <p> This test is opportunistically enabled when <a href="postscreen.8.html">postscreen(8)</a> has
 496 to use the built-in SMTP engine anyway. This is to make <a href="postscreen.8.html">postscreen(8)</a>
 497 logging more informative.  </p>
 498
 499 <p> When a client sends bare newline characters, <a href="postscreen.8.html">postscreen(8)</a> logs
 500 this as:
 501 </p>
 502
 503 <pre>
 504     <b>BARE NEWLINE from</b> <i>[address]:port</i>
 505 </pre>
 506
 507 <p> Translation: the SMTP client at <i>[address]:port</i> sent a bare
 508 newline character, that is newline not preceded by carriage
 509 return. </p>
 510
 511 <p> The <a href="postconf.5.html#postscreen_bare_newline_action">postscreen_bare_newline_action</a> parameter specifies the
 512 action that is taken next.  See "<a href="#fail_after_220">When
 513 tests fail after the 220 SMTP server greeting</a>" below. </p>
 514
 515 <h3> <a name="fail_after_220">When tests fail after the 220 SMTP server greeting</a> </h3>
 516
 517 <p> When the client fails the pipelining, non-SMTP command or bare
 518 newline tests, the action is specified with <a href="postconf.5.html#postscreen_pipelining_action">postscreen_pipelining_action</a>,
 519 <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>,
 520 respectively. </p>
 521
 522 <dl>
 523
 524 <dt> <b>ignore</b> (default for bare newline) </dt>
 525
 526 <dd> Ignore the failure of this test. Allow other tests to complete.
 527 Do NOT repeat this test before the result from some other test
 528 expires.
 529
 530 This option is useful for testing and collecting statistics without
 531 blocking mail permanently. </dd>
 532
 533 <dt> <b>enforce</b> (default for pipelining) </dt>
 534
 535 <dd> Allow other tests to complete.  Reject attempts to deliver
 536 mail with a 550 SMTP reply, and log the helo/sender/recipient
 537 information.  Repeat this test the next time the client connects.
 538 </dd>
 539
 540 <dt> <b>drop</b> (default for non-SMTP commands) </dt>
 541
 542 <dd> Drop the connection immediately with a 521 SMTP reply.  Repeat
 543 this test the next time the client connects.  This action is
 544 compatible with the Postfix SMTP server's <a href="postconf.5.html#smtpd_forbidden_commands">smtpd_forbidden_commands</a>
 545 feature. </dd>
 546
 547 </dl>
 548
 549 <h2> <a name="other_error">Other errors</a> </h2>
 550
 551 <p> When an SMTP client hangs up unexpectedly during any tests,
 552 <a href="postscreen.8.html">postscreen(8)</a> logs this as: </p>
 553
 554 <pre>
 555     <b>HANGUP after</b> <i>time</i> <b>from</b> <i>[address]:port</i> <b>in</b> <i>test name</i>
 556 </pre>
 557
 558 <p> Translation: the SMTP client at <i>[address]:port</i> disconnected
 559 unexpectedly, <i>time</i> seconds after the start of the
 560 test named <i>test name</i>. </p>
 561
 562 <!--
 563
 564 <p> While an unexpired penalty is in effect, an SMTP client is not
 565 allowed to pass any tests, and  <a href="postscreen.8.html">postscreen(8)</a> logs each connection
 566 with the remaining amount of penalty time as: </p>
 567
 568 <pre>
 569     <b>PENALTY</b> <i>time</i> <b>for</b> <i>[address]:port</i>
 570 </pre>
 571
 572 <p> During this time, all attempts by the client to deliver mail
 573 will be deferred with a 450 SMTP status.  </p>
 574
 575 -->
 576
 577 <p> The following errors are reported by the built-in SMTP engine.
 578 This engine never accepts mail, therefore it has per-session limits
 579 on the number of commands and on the session length. </p>
 580
 581 <pre>
 582     <b>COMMAND TIME LIMIT</b> <b>from</b> <i>[address]:port</i>
 583 </pre>
 584
 585 <p> Translation: the SMTP client at <i>[address]:port</i> reached the
 586 per-command time limit as specified with the <a href="postconf.5.html#postscreen_command_time_limit">postscreen_command_time_limit</a>
 587 parameter.  The session is terminated immediately. </p>
 588
 589 <pre>
 590     <b>COMMAND COUNT LIMIT from</b> <i>[address]:port</i>
 591 </pre>
 592
 593 <p> Translation: the SMTP client at <i>[address]:port</i> reached the
 594 per-session command count limit as specified with the
 595 <a href="postconf.5.html#postscreen_command_count_limit">postscreen_command_count_limit</a> parameter.  The session is terminated
 596 immediately. </p>
 597
 598 <pre>
 599     <b>COMMAND LENGTH LIMIT from</b> <i>[address]:port</i>
 600 </pre>
 601
 602 <p> Translation: the SMTP client at <i>[address]:port</i> reached the
 603 per-command length limit, as specified with the <a href="postconf.5.html#line_length_limit">line_length_limit</a>
 604 parameter.  The session is terminated immediately. </p>
 605
 606 <p> When an SMTP client makes too many connections at the same time,
 607 or when all <a href="postscreen.8.html">postscreen(8)</a> ports are busy, <a href="postscreen.8.html">postscreen(8)</a> rejects the
 608 connection with a 421 status code and logs: </p>
 609
 610 <pre>
 611     <b>NOQUEUE: reject: CONNECT from</b> <i>[address]:port</i><b>: too many connections</b>
 612     <b>NOQUEUE: reject: CONNECT from</b> <i>[address]:port</i><b>: all server ports busy</b>
 613 </pre>
 614
 615 <p> The <a href="postconf.5.html#postscreen_client_connection_count_limit">postscreen_client_connection_count_limit</a> and
 616 <a href="postconf.5.html#postscreen_pre_queue_limit">postscreen_pre_queue_limit</a> parameters control these limits.  </p>
 617
 618 <h2> <a name="victory">When all tests succeed</a> </h2>
 619
 620 <p> When a new SMTP client passes all tests (i.e. it is not whitelisted
 621 via some mechanism), <a href="postscreen.8.html">postscreen(8)</a> logs this as: </p>
 622
 623 <pre>
 624     <b>PASS NEW</b> <i>[address]:port</i>
 625 </pre>
 626
 627 <p> Where <i>[address]:port</i> are the client IP address and port.
 628 Then, <a href="postscreen.8.html">postscreen(8)</a>
 629 creates a temporary whitelist entry that excludes the client IP
 630 address from further tests until the temporary whitelist entry
 631 expires, as controlled with the postscreen_*_ttl parameters. </p>
 632
 633 <p> When no "<a href="#after_220">deep protocol tests</a>" are
 634 configured, <a href="postscreen.8.html">postscreen(8)</a> hands off the "live" connection to a Postfix
 635 SMTP server process.  The client can then continue as if <a href="postscreen.8.html">postscreen(8)</a>
 636 never even existed (except for the short <a href="postconf.5.html#postscreen_greet_wait">postscreen_greet_wait</a> delay).
 637 </p>
 638
 639 <p> When any "<a href="#after_220">deep protocol tests</a>" are
 640 configured, <a href="postscreen.8.html">postscreen(8)</a> cannot hand off the "live" connection to
 641 a Postfix SMTP server process in the middle of the session.  Instead,
 642 <a href="postscreen.8.html">postscreen(8)</a> defers mail delivery attempts with a 4XX status, logs
 643 the helo/sender/recipient information, and waits for the client to
 644 disconnect.  The next time the client connects it will be allowed
 645 to talk to a Postfix SMTP server process to deliver its mail.
 646 <a href="postscreen.8.html">postscreen(8)</a> mitigates the impact of this limitation by giving
 647 <a href="#after_220">deep protocol tests</a> a long expiration
 648 time. </p>
 649
 650 <h2> <a name="config"> Configuring the postscreen(8) service</a>
 651 </h2>
 652
 653 <p> <a href="postscreen.8.html">postscreen(8)</a> has been tested on FreeBSD [4-8], Linux 2.[4-6]
 654 and Solaris 9 systems. </p>
 655
 656 <ul>
 657
 658 <li> <a href="#enable"> Turning on postscreen(8) without blocking
 659 mail</a>
 660
 661 <li> <a href="#starttls"> postscreen(8) TLS configuration </a>
 662
 663 <li> <a href="#blocking"> Blocking mail with postscreen(8) </a>
 664
 665 <li> <a href="#turnoff"> Turning off postscreen(8) </a>
 666
 667 </ul>
 668
 669 <h3> <a name="enable"> Turning on postscreen(8) without blocking mail</a> </h3>
 670
 671 <p> To enable the <a href="postscreen.8.html">postscreen(8)</a> service and log client information
 672 without blocking mail: </p>
 673
 674 <ol>
 675
 676 <li> <p> Make sure that local clients and systems with non-standard
 677 SMTP implementations are excluded from any <a href="postscreen.8.html">postscreen(8)</a> tests. The
 678 default is to exclude all clients in <a href="postconf.5.html#mynetworks">mynetworks</a>. To exclude additional
 679 clients, for example, third-party performance monitoring tools (these
 680 tend to have broken SMTP implementations): </p>
 681
 682 <pre>
 683 /etc/postfix/<a href="postconf.5.html">main.cf</a>:
 684     # Exclude broken clients by whitelisting. Clients in <a href="postconf.5.html#mynetworks">mynetworks</a>
 685     # should always be whitelisted.
 686     <a href="postconf.5.html#postscreen_access_list">postscreen_access_list</a> = <a href="postconf.5.html#permit_mynetworks">permit_mynetworks</a>,
 687         <a href="cidr_table.5.html">cidr</a>:/etc/postfix/postscreen_access.cidr
 688
 689 /etc/postfix/postscreen_access.<a href="cidr_table.5.html">cidr</a>:
 690     192.168.254.0/24 permit
 691 </pre>
 692
 693 <li> <p> Comment out the "<tt>smtp  inet ... smtpd</tt>" service
 694 in <a href="master.5.html">master.cf</a>, including any "<tt>-o parameter=value</tt>" entries
 695 that follow.  </p>
 696
 697 <pre>
 698 /etc/postfix/<a href="master.5.html">master.cf</a>:
 699     #smtp      inet  n       -       n       -       -       smtpd
 700     #    -o parameter=value ...
 701 </pre>
 702
 703 <li> <p> Uncomment the new "<tt>smtpd pass ... smtpd</tt>" service
 704 in <a href="master.5.html">master.cf</a>, and duplicate any "<tt>-o parameter=value</tt>" entries
 705 from the smtpd service that was commented out in the previous step.
 706 </p>
 707
 708 <pre>
 709 /etc/postfix/<a href="master.5.html">master.cf</a>:
 710     smtpd     pass  -       -       n       -       -       smtpd
 711         -o parameter=value ...
 712 </pre>
 713
 714 <li> <p> Uncomment the new "<tt>smtp inet ... postscreen</tt>"
 715 service in <a href="master.5.html">master.cf</a>. </p>
 716
 717 <pre>
 718 /etc/postfix/<a href="master.5.html">master.cf</a>:
 719     smtp      inet  n       -       n       -       1       postscreen
 720 </pre>
 721
 722 <li> <p> Uncomment the new "<tt>tlsproxy unix ... tlsproxy</tt>"
 723 service in <a href="master.5.html">master.cf</a>.  This service implements STARTTLS support for
 724 <a href="postscreen.8.html">postscreen(8)</a>. </p>
 725
 726 <pre>
 727 /etc/postfix/<a href="master.5.html">master.cf</a>:
 728     tlsproxy  unix  -       -       n       -       0       tlsproxy
 729 </pre>
 730
 731 <li> <p> Uncomment the new "<tt>dnsblog  unix ... dnsblog</tt>"
 732 service in <a href="master.5.html">master.cf</a>.  This service does DNSBL lookups for <a href="postscreen.8.html">postscreen(8)</a>
 733 and logs results. </p>
 734
 735 <pre>
 736 /etc/postfix/<a href="master.5.html">master.cf</a>:
 737     dnsblog   unix  -       -       n       -       0       dnsblog
 738 </pre>
 739
 740 <li> <p> To enable DNSBL lookups, list some DNS blocklist sites in
 741 <a href="postconf.5.html">main.cf</a>, separated by whitespace. Different sites can have different
 742 weights. For example:
 743
 744 <pre>
 745 /etc/postfix/<a href="postconf.5.html">main.cf</a>:
 746     <a href="postconf.5.html#postscreen_dnsbl_threshold">postscreen_dnsbl_threshold</a> = 2
 747     <a href="postconf.5.html#postscreen_dnsbl_sites">postscreen_dnsbl_sites</a> = zen.spamhaus.org*2
 748         bl.spamcop.net*1 b.barracudacentral.org*1
 749 </pre>
 750
 751 <p> Note: if your DNSBL queries have a "secret" in the domain name,
 752 you must censor this information from the <a href="postscreen.8.html">postscreen(8)</a> SMTP replies.
 753 For example: </p>
 754
 755 <pre>
 756 /etc/postfix/<a href="postconf.5.html">main.cf</a>:
 757     <a href="postconf.5.html#postscreen_dnsbl_reply_map">postscreen_dnsbl_reply_map</a> = texthash:/etc/postfix/dnsbl_reply
 758 </pre>
 759
 760 <pre>
 761 /etc/postfix/dnsbl_reply:
 762     # Secret DNSBL name        Name in <a href="postscreen.8.html">postscreen(8)</a> replies
 763     secret.zen.spamhaus.org    zen.spamhaus.org
 764 </pre>
 765
 766 <p> The texthash: format is similar to hash: except that there is
 767 no need to run <a href="postmap.1.html">postmap(1)</a> before the file can be used, and that it
 768 does not detect changes after the file is read. It is new with
 769 Postfix version 2.8. </p>
 770
 771 <li> <p> Read the new configuration with "<tt>postfix reload</tt>".
 772 </p>
 773
 774 </ol>
 775
 776 <p> Notes: </p>
 777
 778 <ul>
 779
 780 <li> <p> Some <a href="postscreen.8.html">postscreen(8)</a> configuration parameters implement
 781 stress-dependent behavior. This is supported only when the default
 782 value is stress-dependent (that is, it looks like ${stress?X}${stress:Y}).
 783 Other parameters always evaluate as if the stress value is the empty
 784 string. </p>
 785
 786 <li> <p> See "<a href="#before_220">Tests before the 220 SMTP server
 787 greeting</a>" for details about the logging from these postscreen(8)
 788 tests. </p>
 789
 790 <li> <p> If you run Postfix 2.6 or earlier you must stop and start
 791 the master daemon ("<tt>postfix stop; postfix start</tt>").  This
 792 is needed because the Postfix "pass" master service type did not
 793 work reliably on all systems. </p>
 794
 795 </ul>
 796
 797 <h3> <a name="starttls"> postscreen(8) TLS configuration </a> </h3>
 798
 799 <p> <a href="postscreen.8.html">postscreen(8)</a> TLS support is available for remote SMTP clients
 800 that aren't whitelisted, including clients that need to renew their
 801 temporary whitelist status.  When a remote SMTP client requests TLS
 802 service, <a href="postscreen.8.html">postscreen(8)</a> invisibly hands off the connection to a
 803 <a href="tlsproxy.8.html">tlsproxy(8)</a> process. Then, <a href="tlsproxy.8.html">tlsproxy(8)</a> encrypts and decrypts the
 804 traffic between <a href="postscreen.8.html">postscreen(8)</a> and the remote SMTP client. One
 805 <a href="tlsproxy.8.html">tlsproxy(8)</a> process can handle multiple SMTP sessions. The number
 806 of <a href="tlsproxy.8.html">tlsproxy(8)</a> processes slowly increases with server load, but it
 807 should always be much smaller than the number of <a href="postscreen.8.html">postscreen(8)</a> TLS
 808 sessions.  </p>
 809
 810 <p> TLS support for <a href="postscreen.8.html">postscreen(8)</a> and <a href="tlsproxy.8.html">tlsproxy(8)</a> uses the same
 811 parameters as with <a href="smtpd.8.html">smtpd(8)</a>. We recommend that you keep the relevant
 812 configuration parameters in <a href="postconf.5.html">main.cf</a>.  If you must specify "-o
 813 smtpd_mumble=value" parameter overrides in <a href="master.5.html">master.cf</a> for a
 814 postscreen-protected <a href="smtpd.8.html">smtpd(8)</a> service, then you should specify those
 815 same parameter overrides for the <a href="postscreen.8.html">postscreen(8)</a> and <a href="tlsproxy.8.html">tlsproxy(8)</a>
 816 services. </p>
 817
 818 <h3> <a name="blocking"> Blocking mail with postscreen(8) </a> </h3>
 819
 820 <p> For compatibility with <a href="smtpd.8.html">smtpd(8)</a>, <a href="postscreen.8.html">postscreen(8)</a> implements the
 821 <a href="postconf.5.html#soft_bounce">soft_bounce</a> safety feature. This causes Postfix to reject mail with
 822 a "try again" reply code. </p>
 823
 824 <ul>
 825
 826 <li> <p> To turn this on for all of Postfix, specify "<tt><a href="postconf.5.html#soft_bounce">soft_bounce</a>
 827 = yes</tt>" in <a href="postconf.5.html">main.cf</a>. </p>
 828
 829 <li> <p> To turn this on for <a href="postscreen.8.html">postscreen(8)</a> only, append "<tt>-o
 830 <a href="postconf.5.html#soft_bounce">soft_bounce</a>=yes</tt>" (note: NO SPACES around '=') to the postscreen
 831 entry in <a href="master.5.html">master.cf</a>. <p>
 832
 833 </ul>
 834
 835 <p> Execute "<tt>postfix reload</tt>" to make the change effective. </p>
 836
 837 <p> After testing, do not forget to remove the <a href="postconf.5.html#soft_bounce">soft_bounce</a> feature,
 838 otherwise senders won't receive their non-delivery notification
 839 until many days later.  </p>
 840
 841 <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
 842 specify one or more of: </p>
 843
 844 <ul>
 845
 846 <li> <p> "<tt><a href="postconf.5.html#postscreen_dnsbl_action">postscreen_dnsbl_action</a> = enforce</tt>", to reject
 847 clients that are on DNS blocklists, and to log the helo/sender/recipient
 848 information. With good DNSBLs this reduces the amount of load on
 849 Postfix SMTP servers dramatically.  </p>
 850
 851 <li> <p> "<tt><a href="postconf.5.html#postscreen_greet_action">postscreen_greet_action</a> = enforce</tt>", to reject
 852 clients that talk before their turn, and to log the helo/sender/recipient
 853 information. This stops over half of all known-to-be illegitimate
 854 connections to Wietse's mail server. It is backup protection for
 855 zombies that haven't yet been blacklisted. </p>
 856
 857 <li> <p> You can also enable "<a href="#after_220">deep protocol
 858 tests</a>", but these are more intrusive than the pregreet or DNSBL
 859 tests. </p>
 860
 861 <p> When a good client passes the "<a href="#after_220">deep
 862 protocol tests</a>", postscreen(8) adds the client to the temporary
 863 whitelist but it cannot hand off the "live" connection to a Postfix
 864 SMTP server process in the middle of the session. Instead, <a href="postscreen.8.html">postscreen(8)</a>
 865 defers mail delivery attempts with a 4XX status, logs the
 866 helo/sender/recipient information, and waits for the client to
 867 disconnect. </p>
 868
 869 <p> When the good client comes back in a later session, it is allowed
 870 to talk directly to a Postfix SMTP server.  See "after_220 <a
 871 href="#after_220">Tests after the 220 SMTP server greeting</a> above
 872 for limitations with AUTH and other features that clients may need.
 873 </p>
 874
 875 <p> An unexpected benefit from "<a href="#after_220">deep protocol
 876 tests</a>" is that some "good" clients don't return after the 4XX
 877 reply; these clients were not so good after all.  Wietse enables
 878 "<a href="#after_220">deep protocol tests</a>" on his own internet-facing
 879 mail server.  </p>
 880
 881 <li> <p> There is also support for permanent blacklisting and
 882 whitelisting; see the description of the <a href="postconf.5.html#postscreen_access_list">postscreen_access_list</a>
 883 parameter for details. </p>
 884
 885 </ul>
 886
 887 <h3> <a name="turnoff"> Turning off postscreen(8) </a> </h3>
 888
 889 <p> To turn off <a href="postscreen.8.html">postscreen(8)</a> and handle mail directly with Postfix
 890 SMTP server processes: </p>
 891
 892 <ol>
 893
 894 <li> <p> Comment out the "<tt>smtp inet ... postscreen</tt>" service
 895 in <a href="master.5.html">master.cf</a>, including any "<tt>-o parameter=value</tt>" entries
 896 that follow. </p>
 897
 898 <pre>
 899 /etc/postfix/<a href="master.5.html">master.cf</a>:
 900     #smtp      inet  n       -       n       -       1       postscreen
 901     #    -o parameter=value ...
 902 </pre>
 903
 904 <li> <p> Comment out the "<tt>dnsblog  unix ... dnsblog</tt>" service
 905 in <a href="master.5.html">master.cf</a>.  </p>
 906
 907 <pre>
 908 /etc/postfix/<a href="master.5.html">master.cf</a>:
 909     #dnsblog   unix  -       -       n       -       0       dnsblog
 910 </pre>
 911
 912 <li> <p> Comment out the "<tt>smtpd pass ... smtpd</tt>" service
 913 in <a href="master.5.html">master.cf</a>, including any "<tt>-o parameter=value</tt>" entries
 914 that follow. </p>
 915
 916 <pre>
 917 /etc/postfix/<a href="master.5.html">master.cf</a>:
 918     #smtpd     pass  -       -       n       -       -       smtpd
 919     #    -o parameter=value ...
 920 </pre>
 921
 922 <li> <p> Comment out the "<tt>tlsproxy unix ... tlsproxy</tt>"
 923 service in <a href="master.5.html">master.cf</a>, including any "<tt>-o parameter=value</tt>"
 924 entries that follow. </p>
 925
 926 <pre>
 927 /etc/postfix/<a href="master.5.html">master.cf</a>:
 928     #tlsproxy  unix  -       -       n       -       0       tlsproxy
 929     #    -o parameter=value ...
 930 </pre>
 931
 932 <li> <p> Uncomment the "<tt>smtp  inet ... smtpd</tt>" service in
 933 <a href="master.5.html">master.cf</a>, including any "<tt>-o parameter=value</tt>" entries that
 934 may follow.  </p>
 935
 936 <pre>
 937 /etc/postfix/<a href="master.5.html">master.cf</a>:
 938     smtp       inet  n       -       n       -       -       smtpd
 939         -o parameter=value ...
 940 </pre>
 941
 942 <li> <p> Read the new configuration with "<tt>postfix reload</tt>".
 943 </p>
 944
 945 </ol>
 946
 947 <h2> <a name="historical"> Historical notes and credits </a> </h2>
 948
 949 <p> Many ideas in <a href="postscreen.8.html">postscreen(8)</a> were explored in earlier work by
 950 Michael Tokarev, in OpenBSD spamd, and in MailChannels Traffic
 951 Control. </p>
 952
 953 <p> Wietse threw together a crude prototype with pregreet and dnsbl
 954 support in June 2009, because he needed something new for a Mailserver
 955 conference presentation in July. Ralf Hildebrandt ran this code on
 956 several servers to collect real-world statistics. This version used
 957 the <a href="dnsblog.8.html">dnsblog(8)</a> ad-hoc DNS client program. </p>
 958
 959 <p> Wietse needed new material for a LISA conference presentation
 960 in November 2010, so he added support for DNSBL weights and filters
 961 in August, followed by a major code rewrite, deep protocol tests,
 962 helo/sender/recipient logging, and stress-adaptive behavior in
 963 September. Ralf Hildebrandt ran this code on several servers to
 964 collect real-world statistics. This version still used the embarrassing
 965 <a href="dnsblog.8.html">dnsblog(8)</a> ad-hoc DNS client program.  </p>
 966
 967 <p> Wietse added STARTTLS support in December 2010. This makes
 968 <a href="postscreen.8.html">postscreen(8)</a> usable for sites that require TLS support.  The
 969 implementation introduces the <a href="tlsproxy.8.html">tlsproxy(8)</a> event-driven TLS proxy
 970 that decrypts/encrypts the sessions for multiple SMTP clients. </p>
 971
 972 </body>
 973
 974 </html>
 975