1 1.1 tron <!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN" 2 1.1.1.8 christos "https://www.w3.org/TR/html4/loose.dtd"> 3 1.1 tron 4 1.1 tron <html> 5 1.1 tron 6 1.1 tron <head> 7 1.1 tron 8 1.1 tron <title>Postfix Stress-Dependent Configuration</title> 9 1.1 tron 10 1.1.1.6 christos <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> 11 1.1.1.7 christos <link rel='stylesheet' type='text/css' href='postfix-doc.css'> 12 1.1 tron 13 1.1 tron </head> 14 1.1 tron 15 1.1 tron <body> 16 1.1 tron 17 1.1 tron <h1><img src="postfix-logo.jpg" width="203" height="98" ALT="">Postfix 18 1.1 tron Stress-Dependent Configuration</h1> 19 1.1 tron 20 1.1 tron <hr> 21 1.1 tron 22 1.1 tron <h2>Overview </h2> 23 1.1 tron 24 1.1 tron <p> This document describes the symptoms of Postfix SMTP server 25 1.1 tron overload. It presents permanent main.cf changes to avoid overload 26 1.1 tron during normal operation, and temporary main.cf changes to cope with 27 1.1 tron an unexpected burst of mail. This document makes specific suggestions 28 1.1 tron for Postfix 2.5 and later which support stress-adaptive behavior, 29 1.1 tron and for earlier Postfix versions that don't. </p> 30 1.1 tron 31 1.1 tron <p> Topics covered in this document: </p> 32 1.1 tron 33 1.1 tron <ul> 34 1.1 tron 35 1.1 tron <li><a href="#overload"> Symptoms of Postfix SMTP server overload </a> 36 1.1 tron 37 1.1.1.3 tron <li><a href="#adapt"> Automatic stress-adaptive behavior </a> 38 1.1.1.3 tron 39 1.1 tron <li><a href="#concurrency"> Service more SMTP clients at the same time </a> 40 1.1 tron 41 1.1 tron <li><a href="#time"> Spend less time per SMTP client </a> 42 1.1 tron 43 1.1 tron <li><a href="#hangup"> Disconnect suspicious SMTP clients </a> 44 1.1 tron 45 1.1 tron <li><a href="#legacy"> Temporary measures for older Postfix releases </a> 46 1.1 tron 47 1.1 tron <li><a href="#feature"> Detecting support for stress-adaptive behavior </a> 48 1.1 tron 49 1.1 tron <li><a href="#forcing"> Forcing stress-adaptive behavior on or off </a> 50 1.1 tron 51 1.1 tron <li><a href="#other"> Other measures to off-load zombies </a> 52 1.1 tron 53 1.1 tron <li><a href="#credits"> Credits </a> 54 1.1 tron 55 1.1 tron </ul> 56 1.1 tron 57 1.1 tron <h2><a name="overload"> Symptoms of Postfix SMTP server overload </a></h2> 58 1.1 tron 59 1.1 tron <p> Under normal conditions, the Postfix SMTP server responds 60 1.1 tron immediately when an SMTP client connects to it; the time to deliver 61 1.1 tron mail is noticeable only with large messages. Performance degrades 62 1.1 tron dramatically when the number of SMTP clients exceeds the number of 63 1.1 tron Postfix SMTP server processes. When an SMTP client connects while 64 1.1 tron all Postfix SMTP server processes are busy, the client must wait 65 1.1 tron until a server process becomes available. </p> 66 1.1 tron 67 1.1 tron <p> SMTP server overload may be caused by a surge of legitimate 68 1.1 tron mail (example: a DNS registrar opens a new zone for registrations), 69 1.1 tron by mistake (mail explosion caused by a forwarding loop) or by malice 70 1.1 tron (worm outbreak, botnet, or other illegitimate activity). </p> 71 1.1 tron 72 1.1 tron <p> Symptoms of Postfix SMTP server overload are: </p> 73 1.1 tron 74 1.1 tron <ul> 75 1.1 tron 76 1.1 tron <li> <p> Remote SMTP clients experience a long delay before Postfix 77 1.1 tron sends the "220 hostname.example.com ESMTP Postfix" greeting. </p> 78 1.1 tron 79 1.1 tron <ul> 80 1.1 tron 81 1.1 tron <li> <p> NOTE: Broken DNS configurations can also cause lengthy 82 1.1 tron delays before Postfix sends "220 hostname.example.com ...". These 83 1.1 tron delays also exist when Postfix is NOT overloaded. </p> 84 1.1 tron 85 1.1 tron <li> <p> NOTE: To avoid "overload" delays for end-user mail 86 1.1 tron clients, enable the "submission" service entry in master.cf (present 87 1.1 tron since Postfix 2.1), and tell users to connect to this instead of 88 1.1 tron the public SMTP service. </p> 89 1.1 tron 90 1.1 tron </ul> 91 1.1 tron 92 1.1 tron <li> <p> The Postfix SMTP server logs an increased number of "lost 93 1.1 tron connection after CONNECT" events. This happens because remote SMTP 94 1.1 tron clients disconnect before Postfix answers the connection. </p> 95 1.1 tron 96 1.1 tron <ul> 97 1.1 tron 98 1.1 tron <li> <p> NOTE: A portscan for open SMTP ports can also result in 99 1.1 tron "lost connection ..." logfile messages. </p> 100 1.1 tron 101 1.1 tron </ul> 102 1.1 tron 103 1.1 tron <li> <p> Postfix 2.3 and later logs a warning that all server ports 104 1.1 tron are busy: </p> 105 1.1 tron 106 1.1 tron <pre> 107 1.1 tron Oct 3 20:39:27 spike postfix/master[28905]: warning: service "smtp" 108 1.1 tron (25) has reached its process limit "30": new clients may experience 109 1.1 tron noticeable delays 110 1.1 tron Oct 3 20:39:27 spike postfix/master[28905]: warning: to avoid this 111 1.1 tron condition, increase the process count in master.cf or reduce the 112 1.1 tron service time per client 113 1.1.1.3 tron Oct 3 20:39:27 spike postfix/master[28905]: warning: see 114 1.1.1.8 christos <a href="https://www.postfix.org/STRESS_README.html">https://www.postfix.org/STRESS_README.html</a> for examples of 115 1.1.1.3 tron stress-adapting configuration settings 116 1.1 tron </pre> 117 1.1 tron 118 1.1 tron </ul> 119 1.1 tron 120 1.1 tron <p> Legitimate mail that doesn't get through during an episode of 121 1.1 tron Postfix SMTP server overload is not necessarily lost. It should 122 1.1 tron still arrive once the situation returns to normal, as long as the 123 1.1 tron overload condition is temporary. </p> 124 1.1 tron 125 1.1.1.3 tron <h2><a name="adapt"> Automatic stress-adaptive behavior </a></h2> 126 1.1.1.3 tron 127 1.1.1.3 tron <p> Postfix version 2.5 introduces automatic stress-adaptive behavior. 128 1.1.1.3 tron It works as follows. When a "public" network service such as the 129 1.1.1.3 tron SMTP server runs into an "all server ports are busy" condition, the 130 1.1.1.3 tron Postfix master(8) daemon logs a warning, restarts the service 131 1.1.1.3 tron (without interrupting existing network sessions), and runs the 132 1.1.1.3 tron service with "-o stress=yes" on the server process command line: 133 1.1.1.3 tron </p> 134 1.1.1.3 tron 135 1.1.1.3 tron <blockquote> 136 1.1.1.3 tron <pre> 137 1.1.1.3 tron 80821 ?? S 0:00.24 smtpd -n smtp -t inet -u -c -o stress=yes 138 1.1.1.3 tron </pre> 139 1.1.1.3 tron </blockquote> 140 1.1.1.3 tron 141 1.1.1.3 tron <p> Normally, the Postfix master(8) daemon runs such a service with 142 1.1.1.3 tron "-o stress=" on the command line (i.e. with an empty parameter 143 1.1.1.3 tron value): </p> 144 1.1.1.3 tron 145 1.1.1.3 tron <blockquote> 146 1.1.1.3 tron <pre> 147 1.1.1.3 tron 83326 ?? S 0:00.28 smtpd -n smtp -t inet -u -c -o stress= 148 1.1.1.3 tron </pre> 149 1.1.1.3 tron </blockquote> 150 1.1.1.3 tron 151 1.1.1.5 christos <p> You won't see "-o stress" command-line parameters with services 152 1.1.1.5 christos that have local clients only. These include services internal to 153 1.1.1.3 tron Postfix such as the queue manager, and services that listen on a 154 1.1.1.3 tron loopback interface only, such as after-filter SMTP services. </p> 155 1.1.1.3 tron 156 1.1.1.3 tron <p> The "stress" parameter value is the key to making main.cf 157 1.1.1.3 tron parameter settings stress adaptive. The following settings are the 158 1.1.1.3 tron default with Postfix 2.6 and later. </p> 159 1.1.1.3 tron 160 1.1.1.3 tron <blockquote> 161 1.1.1.3 tron <pre> 162 1.1.1.4 christos 1 smtpd_timeout = ${stress?{10}:{300}}s 163 1.1.1.4 christos 2 smtpd_hard_error_limit = ${stress?{1}:{20}} 164 1.1.1.4 christos 3 smtpd_junk_command_limit = ${stress?{1}:{100}} 165 1.1.1.3 tron 4 # Parameters added after Postfix 2.6: 166 1.1.1.4 christos 5 smtpd_per_record_deadline = ${stress?{yes}:{no}} 167 1.1.1.4 christos 6 smtpd_starttls_timeout = ${stress?{10}:{300}}s 168 1.1.1.4 christos 7 address_verify_poll_count = ${stress?{1}:{3}} 169 1.1.1.3 tron </pre> 170 1.1.1.3 tron </blockquote> 171 1.1.1.3 tron 172 1.1.1.4 christos <p> Postfix versions before 3.0 use the older form ${stress?x}${stress:y} 173 1.1.1.4 christos instead of the newer form ${stress?{x}:{y}}. </p> 174 1.1.1.4 christos 175 1.1.1.5 christos <p> The syntax of ${name?{value}:{value}}, ${name?value} and 176 1.1.1.5 christos ${name:value} is explained at the beginning of the postconf(5) 177 1.1.1.5 christos manual page. </p> 178 1.1.1.5 christos 179 1.1.1.3 tron <p> Translation: <p> 180 1.1.1.3 tron 181 1.1.1.3 tron <ul> 182 1.1.1.3 tron 183 1.1.1.3 tron <li> <p> Line 1: under conditions of stress, use an smtpd_timeout 184 1.1.1.3 tron value of 10 seconds instead of the default 300 seconds. Experience 185 1.1.1.3 tron on the postfix-users list from a variety of sysadmins shows that 186 1.1.1.3 tron reducing the "normal" smtpd_timeout to 60s is unlikely to affect 187 1.1.1.3 tron legitimate clients. However, it is unlikely to become the Postfix 188 1.1.1.3 tron default because it's not RFC compliant. Setting smtpd_timeout to 189 1.1.1.3 tron 10s or even 5s under stress will still allow most 190 1.1.1.3 tron legitimate clients to connect and send mail, but may delay mail 191 1.1.1.3 tron from some clients. No mail should be lost, as long as this measure 192 1.1.1.3 tron is used only temporarily. </p> 193 1.1.1.3 tron 194 1.1.1.3 tron <li> <p> Line 2: under conditions of stress, use an smtpd_hard_error_limit 195 1.1.1.5 christos of 1 instead of the default 20. This disconnects clients 196 1.1.1.3 tron after a single error, giving other clients a chance to connect. 197 1.1.1.3 tron However, this may cause significant delays with legitimate mail, 198 1.1.1.3 tron such as a mailing list that contains a few no-longer-active user 199 1.1.1.3 tron names that didn't bother to unsubscribe. No mail should be lost, 200 1.1.1.3 tron as long as this measure is used only temporarily. </p> 201 1.1.1.3 tron 202 1.1.1.3 tron <li> <p> Line 3: under conditions of stress, use an 203 1.1.1.3 tron smtpd_junk_command_limit of 1 instead of the default 100. This 204 1.1.1.3 tron prevents clients from keeping connections open by repeatedly 205 1.1.1.3 tron sending HELO, EHLO, NOOP, RSET, VRFY or ETRN commands. </p> 206 1.1.1.3 tron 207 1.1.1.3 tron <li> <p> Line 5: under conditions of stress, change the behavior 208 1.1.1.3 tron of smtpd_timeout and smtpd_starttls_timeout, from a time limit per 209 1.1.1.3 tron read or write system call, to a time limit to send or receive a 210 1.1.1.3 tron complete record (an SMTP command line, SMTP response line, SMTP 211 1.1.1.3 tron message content line, or TLS protocol message). </p> 212 1.1.1.3 tron 213 1.1.1.3 tron <li> <p> Line 6: under conditions of stress, reduce the time limit 214 1.1.1.3 tron for TLS protocol handshake messages to 10 seconds, from the default 215 1.1.1.3 tron value of 300 seconds. See also the smtpd_timeout discussion above. 216 1.1.1.3 tron </p> 217 1.1.1.3 tron 218 1.1.1.3 tron <li> <p> Line 7: under conditions of stress, do not wait up to 6 219 1.1.1.3 tron seconds for the completion of an address verification probe. If the 220 1.1.1.3 tron result is not already in the address verification cache, reply 221 1.1.1.3 tron immediately with $unverified_recipient_tempfail_action or 222 1.1.1.3 tron $unverified_sender_tempfail_action. No mail should be lost, as long 223 1.1.1.3 tron as this measure is used only temporarily. </p> 224 1.1.1.3 tron 225 1.1.1.3 tron </ul> 226 1.1.1.3 tron 227 1.1.1.3 tron <p> NOTE: Please keep in mind that the stress-adaptive feature is 228 1.1.1.3 tron a fairly desperate measure to keep <b>some</b> legitimate mail 229 1.1.1.3 tron flowing under overload conditions. If a site is reaching the SMTP 230 1.1.1.3 tron server process limit when there isn't an attack or bot flood 231 1.1.1.3 tron occurring, then either the process limit needs to be raised or more 232 1.1.1.3 tron hardware needs to be added. </p> 233 1.1.1.3 tron 234 1.1 tron <h2><a name="concurrency"> Service more SMTP clients at the same time </a> </h2> 235 1.1 tron 236 1.1.1.3 tron <p> This section and the ones that follow discuss permanent measures 237 1.1.1.3 tron against mail server overload. </p> 238 1.1.1.3 tron 239 1.1 tron <p> One measure to avoid the "all server processes busy" condition 240 1.1 tron is to service more SMTP clients simultaneously. For this you need 241 1.1 tron to increase the number of Postfix SMTP server processes. This will 242 1.1 tron improve the 243 1.1 tron responsiveness for remote SMTP clients, as long as the server machine 244 1.1 tron has enough hardware and software resources to run the additional 245 1.1 tron processes, and as long as the file system can keep up with the 246 1.1 tron additional load. </p> 247 1.1 tron 248 1.1 tron <ul> 249 1.1 tron 250 1.1 tron <li> <p> You increase the number of SMTP server processes either 251 1.1 tron by increasing the default_process_limit in main.cf (line 3 below), 252 1.1 tron or by increasing the SMTP server's "maxproc" field in master.cf 253 1.1 tron (line 10 below). Either way, you need to issue a "postfix reload" 254 1.1 tron command to make the change effective. </p> 255 1.1 tron 256 1.1 tron <li> <p> Process limits above 1000 require Postfix version 2.4 or 257 1.1 tron later, and an operating system that supports kernel-based event 258 1.1 tron filters (BSD kqueue(2), Linux epoll(4), or Solaris /dev/poll). 259 1.1 tron </p> 260 1.1 tron 261 1.1 tron <li> <p> More processes use more memory. You can reduce the Postfix 262 1.1 tron memory footprint by using cdb: 263 1.1 tron lookup tables instead of Berkeley DB's hash: or btree: tables. </p> 264 1.1 tron 265 1.1 tron <pre> 266 1.1 tron 1 /etc/postfix/main.cf: 267 1.1 tron 2 # Raise the global process limit, 100 since Postfix 2.0. 268 1.1 tron 3 default_process_limit = 200 269 1.1 tron 4 270 1.1 tron 5 /etc/postfix/master.cf: 271 1.1 tron 6 # ============================================================= 272 1.1 tron 7 # service type private unpriv chroot wakeup maxproc command 273 1.1 tron 8 # ============================================================= 274 1.1 tron 9 # Raise the SMTP service process limit only. 275 1.1 tron 10 smtp inet n - n - 200 smtpd 276 1.1 tron </pre> 277 1.1 tron 278 1.1 tron <li> <p> NOTE: older versions of the SMTPD_POLICY_README document 279 1.1 tron contain a mistake: they configure a fixed number of policy daemon 280 1.1 tron processes. When you raise the SMTP server's "maxproc" field in 281 1.1 tron master.cf, SMTP server processes will report problems when connecting 282 1.1 tron to policy server processes, because there aren't enough of them. 283 1.1 tron Examples of errors are "connection refused" or "operation timed 284 1.1 tron out". </p> 285 1.1 tron 286 1.1 tron <p> To fix, edit master.cf and specify a zero "maxproc" field 287 1.1 tron in all policy server entries; see line 6 in the example below. 288 1.1 tron Issue a "postfix reload" command to make the change effective. </p> 289 1.1 tron 290 1.1 tron <pre> 291 1.1 tron 1 /etc/postfix/master.cf: 292 1.1 tron 2 # ============================================================= 293 1.1 tron 3 # service type private unpriv chroot wakeup maxproc command 294 1.1 tron 4 # ============================================================= 295 1.1 tron 5 # Disable the policy service process limit. 296 1.1 tron 6 policy unix - n n - 0 spawn 297 1.1 tron 7 user=nobody argv=/some/where/policy-server 298 1.1 tron </pre> 299 1.1 tron 300 1.1 tron </ul> 301 1.1 tron 302 1.1 tron <h2><a name="time"> Spend less time per SMTP client </a></h2> 303 1.1 tron 304 1.1 tron <p> When increasing the number of SMTP server processes is not 305 1.1 tron practical, you can improve Postfix server responsiveness by eliminating 306 1.1 tron delays. When Postfix spends less time per SMTP session, the same 307 1.1 tron number of SMTP server processes can service more clients in a given 308 1.1 tron amount of time. </p> 309 1.1 tron 310 1.1 tron <ul> 311 1.1 tron 312 1.1 tron <li> <p> Eliminate non-functional RBL lookups (blocklists that are 313 1.1 tron no longer in operation). These lookups can degrade performance. 314 1.1 tron Postfix logs a warning when an RBL server does not respond. </p> 315 1.1 tron 316 1.1 tron <li> <p> Eliminate redundant RBL lookups (people often use multiple 317 1.1 tron Spamhaus RBLs that include each other). To find out whether RBLs 318 1.1 tron include other RBLs, look up the websites that document the RBL's 319 1.1 tron policies. </p> 320 1.1 tron 321 1.1 tron <li> <p> Eliminate header_checks and body_checks, and keep just a few 322 1.1 tron emergency patterns to block the latest worm explosion or backscatter 323 1.1 tron mail. See BACKSCATTER_README for examples of the latter. 324 1.1 tron 325 1.1 tron <li> <p> Group your header_checks and body_checks patterns to avoid 326 1.1 tron unnecessary pattern matching operations: 327 1.1 tron 328 1.1 tron <pre> 329 1.1 tron 1 /etc/postfix/header_checks: 330 1.1 tron 2 if /^Subject:/ 331 1.1 tron 3 /^Subject: virus found in mail from you/ reject 332 1.1 tron 4 /^Subject: ..other../ reject 333 1.1 tron 5 endif 334 1.1 tron 6 335 1.1 tron 7 if /^Received:/ 336 1.1 tron 8 /^Received: from (postfix\.org) / reject forged client name in received header: $1 337 1.1 tron 9 /^Received: from ..other../ reject .... 338 1.1 tron 10 endif 339 1.1 tron </pre> 340 1.1 tron 341 1.1 tron </ul> 342 1.1 tron 343 1.1 tron <h2><a name="hangup"> Disconnect suspicious SMTP clients </a></h2> 344 1.1 tron 345 1.1 tron <p> Under conditions of overload you can improve Postfix SMTP server 346 1.1 tron responsiveness by hanging up on suspicious clients, so that other 347 1.1 tron clients get a chance to talk to Postfix. </p> 348 1.1 tron 349 1.1 tron <ul> 350 1.1 tron 351 1.1 tron <li> <p> Use "521" SMTP reply codes (Postfix 2.6 and later) or "421" 352 1.1 tron (Postfix 2.3-2.5) to hang up on clients that that match botnet-related 353 1.1 tron RBLs (see next bullet) or that match selected non-RBL restrictions 354 1.1 tron such as SMTP access maps. The Postfix SMTP server will reject mail 355 1.1 tron and disconnect without waiting for the remote SMTP client to send 356 1.1 tron a QUIT command. </p> 357 1.1 tron 358 1.1.1.6 christos <li> <p> To hang up connections from denylisted zombies, you can 359 1.1 tron set specific Postfix SMTP server reject codes for specific RBLs, 360 1.1 tron and for individual responses from specific RBLs. We'll use 361 1.1 tron zen.spamhaus.org as an example; by the time you read this document, 362 1.1 tron details may have changed. Right now, their documents say that a 363 1.1 tron response of 127.0.0.10 or 127.0.0.11 indicates a dynamic client IP 364 1.1 tron address, which means that the machine is probably running a bot of 365 1.1 tron some kind. To give a 521 response instead of the default 554 366 1.1 tron response, use something like: </p> 367 1.1 tron 368 1.1 tron <pre> 369 1.1 tron 1 /etc/postfix/main.cf: 370 1.1 tron 2 smtpd_client_restrictions = 371 1.1 tron 3 permit_mynetworks 372 1.1 tron 4 reject_rbl_client zen.spamhaus.org=127.0.0.10 373 1.1 tron 5 reject_rbl_client zen.spamhaus.org=127.0.0.11 374 1.1 tron 6 reject_rbl_client zen.spamhaus.org 375 1.1 tron 7 376 1.1 tron 8 rbl_reply_maps = hash:/etc/postfix/rbl_reply_maps 377 1.1 tron 9 378 1.1 tron 10 /etc/postfix/rbl_reply_maps: 379 1.1 tron 11 # With Postfix 2.3-2.5 use "421" to hang up connections. 380 1.1 tron 12 zen.spamhaus.org=127.0.0.10 521 4.7.1 Service unavailable; 381 1.1 tron 13 $rbl_class [$rbl_what] blocked using 382 1.1 tron 14 $rbl_domain${rbl_reason?; $rbl_reason} 383 1.1 tron 15 384 1.1 tron 16 zen.spamhaus.org=127.0.0.11 521 4.7.1 Service unavailable; 385 1.1 tron 17 $rbl_class [$rbl_what] blocked using 386 1.1 tron 18 $rbl_domain${rbl_reason?; $rbl_reason} 387 1.1 tron </pre> 388 1.1 tron 389 1.1 tron <p> Although the above example shows three RBL lookups (lines 4-6), 390 1.1 tron Postfix will only do a single DNS query, so it does not affect the 391 1.1 tron performance. </p> 392 1.1 tron 393 1.1 tron <li> <p> With Postfix 2.3-2.5, use reply code 421 (521 will not 394 1.1 tron cause Postfix to disconnect). The down-side of replying with 421 395 1.1 tron is that it works only for zombies and other malware. If the client 396 1.1 tron is running a real MTA, then it may connect again several times until 397 1.1 tron the mail expires in its queue. When this is a problem, stick with 398 1.1 tron the default 554 reply, and use "smtpd_hard_error_limit = 1" as 399 1.1 tron described below. </p> 400 1.1 tron 401 1.1 tron <li> <p> You can automatically turn on the above overload measure 402 1.1 tron with Postfix 2.5 and later, or with earlier releases that contain 403 1.1 tron the stress-adaptive behavior source code patch from the mirrors 404 1.1.1.8 christos listed at https://www.postfix.org/download.html. Simply replace line 405 1.1 tron above 8 with: </p> 406 1.1 tron 407 1.1 tron <pre> 408 1.1 tron 8 rbl_reply_maps = ${stress?hash:/etc/postfix/rbl_reply_maps} 409 1.1 tron </pre> 410 1.1 tron 411 1.1 tron </ul> 412 1.1 tron 413 1.1 tron <p> More information about automatic stress-adaptive behavior is 414 1.1 tron in section "<a href="#adapt">Automatic stress-adaptive behavior</a>". 415 1.1 tron </p> 416 1.1 tron 417 1.1 tron <h2><a name="legacy"> Temporary measures for older Postfix releases </a></h2> 418 1.1 tron 419 1.1.1.5 christos <p> See the section "<a href="#adapt">Automatic stress-adaptive 420 1.1.1.5 christos behavior</a>" if you are running Postfix version 2.5 or later, or 421 1.1 tron if you have applied the source code patch for stress-adaptive 422 1.1.1.8 christos behavior from the mirrors listed at https://www.postfix.org/download.html. 423 1.1 tron </p> 424 1.1 tron 425 1.1 tron <p> The following measures can be applied temporarily during overload. 426 1.1 tron They still allow <b>most</b> legitimate clients to connect and send 427 1.1 tron mail, but may affect some legitimate clients. </p> 428 1.1 tron 429 1.1 tron <ul> 430 1.1 tron 431 1.1 tron <li> <p> Reduce smtpd_timeout (default: 300s). Experience on the 432 1.1 tron postfix-users list from a variety of sysadmins shows that reducing 433 1.1 tron the "normal" smtpd_timeout to 60s is unlikely to affect legitimate 434 1.1 tron clients. However, it is unlikely to become the Postfix default 435 1.1 tron because it's not RFC compliant. Setting smtpd_timeout to 10s (line 436 1.1 tron 2 below) or even 5s under stress will still allow <b>most</b> 437 1.1 tron legitimate clients to connect and send mail, but may delay mail 438 1.1 tron from some clients. No mail should be lost, as long as this measure 439 1.1 tron is used only temporarily. </p> 440 1.1 tron 441 1.1 tron <li> <p> Reduce smtpd_hard_error_limit (default: 20). Setting this 442 1.1 tron to 1 under stress (line 3 below) helps by disconnecting clients 443 1.1 tron after a single error, giving other clients a chance to connect. 444 1.1 tron However, this may cause significant delays with legitimate mail, 445 1.1 tron such as a mailing list that contains a few no-longer-active user 446 1.1 tron names that didn't bother to unsubscribe. No mail should be lost, 447 1.1 tron as long as this measure is used only temporarily. </p> 448 1.1 tron 449 1.1 tron <li> <p> Use an smtpd_junk_command_limit of 1 instead of the default 450 1.1 tron 100. This prevents clients from keeping idle connections open by 451 1.1 tron repeatedly sending NOOP or RSET commands. </p> 452 1.1 tron 453 1.1 tron </ul> 454 1.1 tron 455 1.1 tron <blockquote> 456 1.1 tron <pre> 457 1.1 tron 1 /etc/postfix/main.cf: 458 1.1 tron 2 smtpd_timeout = 10 459 1.1 tron 3 smtpd_hard_error_limit = 1 460 1.1 tron 4 smtpd_junk_command_limit = 1 461 1.1 tron </pre> 462 1.1 tron </blockquote> 463 1.1 tron 464 1.1 tron <p> With these measures, no mail should be lost, as long 465 1.1 tron as these measures are used only temporarily. The next section of 466 1.1 tron this document introduces a way to automate this process. </p> 467 1.1 tron 468 1.1 tron <h2><a name="feature"> Detecting support for stress-adaptive behavior </a></h2> 469 1.1 tron 470 1.1 tron <p> To find out if your Postfix installation supports stress-adaptive 471 1.1 tron behavior, use the "ps" command, and look for the smtpd processes. 472 1.1 tron Postfix has stress-adaptive support when you see "-o stress=" or 473 1.1 tron "-o stress=yes" command-line options. Remember that Postfix never 474 1.1 tron enables stress-adaptive behavior on servers that listen on local 475 1.1 tron addresses only. </p> 476 1.1 tron 477 1.1 tron <p> The following example is for FreeBSD or Linux. On Solaris, HP-UX 478 1.1 tron and other System-V flavors, use "ps -ef" instead of "ps ax". </p> 479 1.1 tron 480 1.1 tron <blockquote> 481 1.1 tron <pre> 482 1.1 tron $ ps ax|grep smtpd 483 1.1 tron 83326 ?? S 0:00.28 smtpd -n smtp -t inet -u -c -o stress= 484 1.1 tron 84345 ?? Ss 0:00.11 /usr/bin/perl /usr/libexec/postfix/smtpd-policy.pl 485 1.1 tron </pre> 486 1.1 tron </blockquote> 487 1.1 tron 488 1.1 tron <p> You can't use postconf(1) to detect stress-adaptive support. 489 1.1 tron The postconf(1) command ignores the existence of the stress parameter 490 1.1 tron in main.cf, because the parameter has no effect there. Command-line 491 1.1 tron "-o parameter" settings always take precedence over main.cf parameter 492 1.1 tron settings. <p> 493 1.1 tron 494 1.1 tron <p> If you configure stress-adaptive behavior in main.cf when it 495 1.1 tron isn't supported, nothing bad will happen. The processes will run 496 1.1 tron as if the stress parameter always has an empty value. </p> 497 1.1 tron 498 1.1 tron <h2><a name="forcing"> Forcing stress-adaptive behavior on or off </a></h2> 499 1.1 tron 500 1.1 tron <p> You can manually force stress-adaptive behavior on, by adding 501 1.1 tron a "-o stress=yes" command-line option in master.cf. This can be 502 1.1 tron useful for testing overrides on the SMTP service. Issue "postfix 503 1.1 tron reload" to make the change effective. </p> 504 1.1 tron 505 1.1 tron <p> Note: setting the stress parameter in main.cf has no effect for 506 1.1 tron services that accept remote connections. </p> 507 1.1 tron 508 1.1 tron <blockquote> 509 1.1 tron <pre> 510 1.1 tron 1 /etc/postfix/master.cf: 511 1.1 tron 2 # ============================================================= 512 1.1 tron 3 # service type private unpriv chroot wakeup maxproc command 513 1.1 tron 4 # ============================================================= 514 1.1 tron 5 # 515 1.1 tron 6 smtp inet n - n - - smtpd 516 1.1 tron 7 -o stress=yes 517 1.1 tron 8 -o . . . 518 1.1 tron </pre> 519 1.1 tron </blockquote> 520 1.1 tron 521 1.1 tron <p> To permanently force stress-adaptive behavior off with a specific 522 1.1 tron service, specify "-o stress=" on its master.cf command line. This 523 1.1 tron may be desirable for the "submission" service. Issue "postfix reload" 524 1.1 tron to make the change effective. </p> 525 1.1 tron 526 1.1 tron <p> Note: setting the stress parameter in main.cf has no effect for 527 1.1 tron services that accept remote connections. </p> 528 1.1 tron 529 1.1 tron <blockquote> 530 1.1 tron <pre> 531 1.1 tron 1 /etc/postfix/master.cf: 532 1.1 tron 2 # ============================================================= 533 1.1 tron 3 # service type private unpriv chroot wakeup maxproc command 534 1.1 tron 4 # ============================================================= 535 1.1 tron 5 # 536 1.1 tron 6 submission inet n - n - - smtpd 537 1.1 tron 7 -o stress= 538 1.1 tron 8 -o . . . 539 1.1 tron </pre> 540 1.1 tron </blockquote> 541 1.1 tron 542 1.1 tron <h2><a name="other"> Other measures to off-load zombies </a> </h2> 543 1.1 tron 544 1.1.1.2 tron <p> The postscreen(8) daemon, introduced with Postfix 2.8, provides 545 1.1.1.2 tron additional protection against mail server overload. One postscreen(8) 546 1.1.1.2 tron process handles multiple inbound SMTP connections, and decides which 547 1.1.1.6 christos clients may talk to a Postfix SMTP server process. By keeping 548 1.1.1.2 tron spambots away, postscreen(8) leaves more SMTP server processes 549 1.1.1.2 tron available for legitimate clients, and delays the onset of server 550 1.1.1.2 tron overload conditions. </p> 551 1.1 tron 552 1.1 tron <h2><a name="credits"> Credits </a></h2> 553 1.1 tron 554 1.1 tron <ul> 555 1.1 tron 556 1.1 tron <li> Thanks to the postfix-users mailing list members for sharing 557 1.1 tron early experiences with the stress-adaptive feature. 558 1.1 tron 559 1.1 tron <li> The RBL example and several other paragraphs of text were 560 1.1 tron adapted from postfix-users postings by Noel Jones. 561 1.1 tron 562 1.1 tron <li> Wietse implemented stress-adaptive behavior as the smallest 563 1.1 tron possible patch while he should be working on other things. 564 1.1 tron 565 1.1 tron </ul> 566 1.1 tron 567 1.1 tron </body> </html> 568
Indexes created Mon Aug 10 00:24:53 UTC 2026