1
PPoossttffiixx BBoottttlleenneecckk AAnnaallyyssiiss
3
-------------------------------------------------------------------------------
5
PPuurrppoossee ooff tthhiiss ddooccuummeenntt
7
This document describes the qshape(1) program which helps the administrator
8
understand the Postfix queue message distribution sorted by time and by sender
9
or recipient domain. qshape(1) is bundled with the Postfix 2.1 source under the
10
"auxiliary" directory.
12
In order to understand the output of qshape(1), it useful to understand the
13
various Postfix queues. To this end the role of each Postfix queue directory is
14
described briefly in the "Background info: Postfix queue directories" section
15
near the end of this document.
17
This document covers the following topics:
19
* Introducing the qshape tool
20
* Trouble shooting with qshape
21
* Example 1: Healthy queue
22
* Example 2: Deferred queue full of dictionary attack bounces
23
* Example 3: Congestion in the active queue
24
* Example 4: High volume destination backlog
25
* Background info: Postfix queue directories
27
o The "maildrop" queue
29
o The "incoming" queue
31
o The "deferred" queue
35
IInnttrroodduucciinngg tthhee qqsshhaappee ttooooll
37
When mail is draining slowly or the queue is unexpectedly large, run qshape(1)
38
as the super-user (root) to help zero in on the problem. The qshape(1) program
39
displays a tabular view of the Postfix queue contents.
41
* On the horizontal axis, it displays the queue age with fine granularity for
42
recent messages and (geometrically) less fine granularity for older
45
* The vertical axis displays the destination (or with the "-s" switch the
46
sender) domain. Domains with the most messages are listed first.
48
For example, in the output below we see the top 10 lines of the (mostly forged)
49
sender domain distribution for captured spam in the "hold" queue:
51
$ qshape -s hold | head
52
T 5 10 20 40 80 160 320 640 1280 1280+
53
TOTAL 486 0 0 1 0 0 2 4 20 40 419
54
yahoo.com 14 0 0 1 0 0 0 0 1 0 12
55
extremepricecuts.net 13 0 0 0 0 0 0 0 2 0 11
56
ms35.hinet.net 12 0 0 0 0 0 0 0 0 1 11
57
winnersdaily.net 12 0 0 0 0 0 0 0 2 0 10
58
hotmail.com 11 0 0 0 0 0 0 0 0 1 10
59
worldnet.fr 6 0 0 0 0 0 0 0 0 0 6
60
ms41.hinet.net 6 0 0 0 0 0 0 0 0 0 6
61
osn.de 5 0 0 0 0 0 1 0 0 0 4
63
* The "T" column shows the total (in this case sender) count for each domain.
64
The columns with numbers above them, show counts for messages aged fewer
65
than that many minutes, but not younger than the age limit for the previous
66
column. The row labeled "TOTAL" shows the total count for all domains.
68
* In this example, there are 14 messages allegedly from yahoo.com, 1 between
69
10 and 20 minutes old, 1 between 320 and 640 minutes old and 12 older than
70
1280 minutes (1440 minutes in a day).
72
By default, qshape shows statistics for the union of both the incoming and
73
active queues which are the most relevant queues to look at when analyzing
76
One can request an alternate list of queues:
78
$ qshape deferred | less
79
$ qshape incoming active deferred | less
81
this will show the age distribution of the deferred queue or the union of the
82
incoming active and deferred queues.
84
Command line options control the number of display "buckets", the age limit for
85
the smallest bucket, display of parent domain counts and so on. The "-h" option
86
outputs a summary of the available switches.
88
TTrroouubbllee sshhoooottiinngg wwiitthh qqsshhaappee
90
Large numbers in the qshape output represent a large number of messages that
91
are destined to (or alleged to come from) a particular domain. It should be
92
possible to tell at a glance which domains dominate the queue sender or
93
recipient counts, approximately when a burst of mail started, and when it
96
The problem destinations or sender domains appear near the top left corner of
97
the output table. Remember that the active queue can accommodate up to 20000
98
($qmgr_message_active_limit) messages. To check wether this limit has been
101
$ qshape -s active | head (show sender statistics)
103
If the total sender count is below 20000 the active queue is not yet saturated,
104
any high volume sender domains show near the top of the output.
106
The active queue is also limited to at most 20000 recipient addresses
107
($qmgr_message_recipient_limit). To check for exhaustion of this limit use:
109
$ qshape active | head (show recipient statistics)
111
Having found the high volume domains, it is often useful to search the logs for
112
recent messages pertaining to the domains in question.
114
# Find deliveries to example.com
116
$ tail -10000 /var/log/maillog |
117
egrep -i ': to=<.*@example\.com>,' |
120
# Find messages from example.com
122
$ tail -10000 /var/log/maillog |
123
egrep -i ': from=<.*@example\.com>,' |
126
You may want to drill in on some specific queue ids:
128
# Find all messages for a specific queue id.
130
$ tail -10000 /var/log/maillog | egrep ': 2B2173FF68: '
132
Also look for queue manager warning messages in the log. These warnings can
133
suggest strategies to reduce congestion.
135
$ egrep 'qmgr.*(panic|fatal|error|warning):' /var/log/maillog
137
When all else fails try the Postfix mailing list for help, but please don't
138
forget to include the top 10 or 20 lines of qshape(1) output.
140
EExxaammppllee 11:: HHeeaalltthhyy qquueeuuee
142
When looking at just the incoming and active queues, under normal conditions
143
(no congestion) the incoming and active queues are nearly empty. Mail leaves
144
the system almost as quickly as it comes in or is deferred without congestion
147
$ qshape (show incoming and active queue status)
149
T 5 10 20 40 80 160 320 640 1280 1280+
150
TOTAL 5 0 0 0 1 0 0 0 1 1 2
151
meri.uwasa.fi 5 0 0 0 1 0 0 0 1 1 2
153
If one looks at the two queues separately, the incoming queue is empty or
154
perhaps briefly has one or two messages, while the active queue holds more
155
messages and for a somewhat longer time:
159
T 5 10 20 40 80 160 320 640 1280 1280+
160
TOTAL 0 0 0 0 0 0 0 0 0 0 0
164
T 5 10 20 40 80 160 320 640 1280 1280+
165
TOTAL 5 0 0 0 1 0 0 0 1 1 2
166
meri.uwasa.fi 5 0 0 0 1 0 0 0 1 1 2
168
EExxaammppllee 22:: DDeeffeerrrreedd qquueeuuee ffuullll ooff ddiiccttiioonnaarryy aattttaacckk bboouunncceess
170
This is from a server where recipient validation is not yet available for some
171
of the hosted domains. Dictionary attacks on the unvalidated domains result in
172
bounce backscatter. The bounces dominate the queue, but with proper tuning they
173
do not saturate the incoming or active queues. The high volume of deferred mail
174
is not a direct cause for alarm.
176
$ qshape deferred | head
178
T 5 10 20 40 80 160 320 640 1280 1280+
179
TOTAL 2234 4 2 5 9 31 57 108 201 464 1353
180
heyhihellothere.com 207 0 0 1 1 6 6 8 25 68 92
181
pleazerzoneprod.com 105 0 0 0 0 0 0 0 5 44 56
182
groups.msn.com 63 2 1 2 4 4 14 14 14 8 0
183
orion.toppoint.de 49 0 0 0 1 0 2 4 3 16 23
184
kali.com.cn 46 0 0 0 0 1 0 2 6 12 25
185
meri.uwasa.fi 44 0 0 0 0 1 0 2 8 11 22
186
gjr.paknet.com.pk 43 1 0 0 1 1 3 3 6 12 16
187
aristotle.algonet.se 41 0 0 0 0 0 1 2 11 12 15
189
The domains shown are mostly bulk-mailers and all the volume is the tail end of
190
the time distribution, showing that short term arrival rates are moderate.
191
Larger numbers and lower message ages are more indicative of current trouble.
192
Old mail still going nowhere is largely harmless so long as the active and
193
incoming queues are short. We can also see that the groups.msn.com
194
undeliverables are low rate steady stream rather than a concentrated dictionary
195
attack that is now over.
197
$ qshape -s deferred | head
199
T 5 10 20 40 80 160 320 640 1280 1280+
200
TOTAL 2193 4 4 5 8 33 56 104 205 465 1309
201
MAILER-DAEMON 1709 4 4 5 8 33 55 101 198 452 849
202
example.com 263 0 0 0 0 0 0 0 0 2 261
203
example.org 209 0 0 0 0 0 1 3 6 11 188
204
example.net 6 0 0 0 0 0 0 0 0 0 6
205
example.edu 3 0 0 0 0 0 0 0 0 0 3
206
example.gov 2 0 0 0 0 0 0 0 1 0 1
207
example.mil 1 0 0 0 0 0 0 0 0 0 1
209
Looking at the sender distribution, we see that as expected most of the
210
messages are bounces.
212
EExxaammppllee 33:: CCoonnggeessttiioonn iinn tthhee aaccttiivvee qquueeuuee
214
This example is taken from a Feb 2004 discussion on the Postfix Users list.
215
Congestion was reported with the active and incoming queues large and not
216
shrinking despite very large delivery agent process limits. The thread is
217
archived at: http://groups.google.com/groups?th=636626c645f5bbde
219
Using an older version of qshape(1) it was quickly determined that all the
220
messages were for just a few destinations:
222
$ qshape (show incoming and active queue status)
224
T A 5 10 20 40 80 160 320 320+
225
TOTAL 11775 9996 0 0 1 1 42 94 221 1420
226
user.sourceforge.net 7678 7678 0 0 0 0 0 0 0 0
227
lists.sourceforge.net 2313 2313 0 0 0 0 0 0 0 0
228
gzd.gotdns.com 102 0 0 0 0 0 0 0 2 100
230
The "A" column showed the count of messages in the active queue, and the
231
numbered columns showed totals for the deferred queue. At 10000 messages
232
(Postfix 1.x active queue size limit) the active queue is full. The incoming
235
With the trouble destinations clearly identified, the administrator quickly
236
found and fixed the problem. It is substantially harder to glean the same
237
information from the logs. While a careful reading of mailq(1) output should
238
yield similar results, it is much harder to gauge the magnitude of the problem
239
by looking at the queue one message at a time.
241
EExxaammppllee 44:: HHiigghh vvoolluummee ddeessttiinnaattiioonn bbaacckklloogg
243
When a site you send a lot of email to is down or slow, mail messages will
244
rapidly build up in the deferred queue, or worse, in the active queue. The
245
qshape output will show large numbers for the destination domain in all age
246
buckets that overlap the starting time of the problem:
248
$ qshape deferred | head
250
T 5 10 20 40 80 160 320 640 1280 1280+
251
TOTAL 5000 200 200 400 800 1600 1000 200 200 200 200
252
highvolume.com 4000 160 160 320 640 1280 1440 0 0 0 0
255
Here the "highvolume.com" destination is continuing to accumulate deferred
256
mail. The incoming and active queues are fine, but the deferred queue started
257
growing some time between 1 and 2 hours ago and continues to grow.
259
If the high volume destination is not down, but is instead slow, one might see
260
similar congestion in the active queue. Active queue congestion is a greater
261
cause for alarm; one might need to take measures to ensure that the mail is
262
deferred instead or even add an access(5) rule asking the sender to try again
265
If a high volume destination exhibits frequent bursts of consecutive
266
connections refused by all MX hosts or "421 Server busy errors", it is possible
267
for the queue manager to mark the destination as "dead" despite the transient
268
nature of the errors. The destination will be retried again after the
269
expiration of a $minimal_backoff_time timer. If the error bursts are frequent
270
enough it may be that only a small quantity of email is delivered before the
271
destination is again marked "dead".
273
The MTA that has been observed most frequently to exhibit such bursts of errors
274
is Microsoft Exchange, which refuses connections under load. Some proxy virus
275
scanners in front of the Exchange server propagate the refused connection to
276
the client as a "421" error.
278
Note that it is now possible to configure Postfix to exhibit similarly erratic
279
behavior by misconfiguring the anvil(8) server (not included in Postfix 2.1.).
280
Do not use anvil(8) for steady-state rate limiting, its purpose is DoS
281
prevention and the rate limits set should be very generous!
283
In the long run it is hoped that the Postfix dead host detection and
284
concurrency control mechanism will be tuned to be more "noise" tolerant. If one
285
finds oneself needing to deliver a high volume of mail to a destination that
286
exhibits frequent brief bursts of errors, there is a subtle workaround.
288
* In master.cf set up a dedicated clone of the "smtp" transport for the
289
destination in question.
291
* In master.cf configure a reasonable process limit for the transport (a
292
number in the 10-20 range is typical).
294
* IMPORTANT!!! In main.cf configure a very large initial and destination
295
concurrency limit for this transport (say 200).
297
/etc/postfix/main.cf:
298
initial_destination_concurrency = 200
299
transportname_destination_concurrency_limit = 200
301
Where transportname is the name of the master.cf entry in question.
303
The effect of this surprising configuration is that up to 200 consecutive
304
errors are tolerated without marking the destination dead, while the total
305
concurrency remains reasonable (10-20 processes). This trick is only for a very
306
specialized situation: high volume delivery into a channel with multi-error
307
bursts that is capable of high throughput, but is repeatedly throttled by the
310
When a destination is unable to handle the load even after the Postfix process
311
limit is reduced to 1, a desperate measure is to insert brief delays between
314
* In the transport map entry for the problem destination, specify a dead host
315
as the primary nexthop.
317
* In the master.cf entry for the transport specify the problem destination as
318
the fallback_relay and specify a small smtp_connect_timeout value.
320
/etc/postfix/transport:
321
problem.example.com slow:[dead.host]
323
/etc/postfix/master.cf:
324
# service type private unpriv chroot wakeup maxproc command
325
slow unix - - n - 1 smtp
326
-o fallback_relay=problem.example.com
327
-o smtp_connect_timeout=1
329
This solution forces the Postfix smtp(8) client to wait for
330
$smtp_connect_timeout seconds between deliveries. The solution depends on
331
Postfix connection management details, and needs to be updated when SMTP
332
connection caching is introduced.
334
Hopefully a more elegant solution to these problems will be found in the
337
BBaacckkggrroouunndd iinnffoo:: PPoossttffiixx qquueeuuee ddiirreeccttoorriieess
339
The following sections describe Postfix queues: their purpose, what normal
340
behavior looks like, and how to diagnose abnormal behavior.
342
TThhee ""mmaaiillddrroopp"" qquueeuuee
344
Messages that have been submitted via the Postfix sendmail(1) command, but not
345
yet brought into the main Postfix queue by the pickup(8) service, await
346
processing in the "maildrop" queue. Messages can be added to the "maildrop"
347
queue even when the Postfix system is not running. They will begin to be
348
processed once Postfix is started.
350
The "maildrop" queue is drained by the single threaded pickup(8) service
351
scanning the queue directory periodically or when notified of new message
352
arrival by the postdrop(1) program. The postdrop(1) program is a setgid helper
353
that allows the unprivileged Postfix sendmail(1) program to inject mail into
354
the "maildrop" queue and to notify the pickup(8) service of its arrival.
356
All mail that enters the main Postfix queue does so via the cleanup(8) service.
357
The cleanup service is responsible for envelope and header rewriting, header
358
and body regular expression checks, automatic bcc recipient processing and
359
guaranteed insertion of the message into the Postfix "incoming" queue.
361
In the absence of excessive CPU consumption in cleanup(8) header or body
362
regular expression checks or other software consuming all available CPU
363
resources, Postfix performance is disk I/O bound. The rate at which the pickup
364
(8) service can inject messages into the queue is largely determined by disk
365
access times, since the cleanup(8) service must commit the message to stable
366
storage before returning success. The same is true of the postdrop(1) program
367
writing the message to the "maildrop" directory.
369
As the pickup service is single threaded, it can only deliver one message at a
370
time at a rate that does not exceed the reciprocal disk I/O latency (+ CPU if
371
not negligible) of the cleanup service.
373
Congestion in this queue is indicative of an excessive local message submission
374
rate or perhaps excessive CPU consumption in the cleanup(8) service due to
375
excessive body_checks.
377
Note, that once the active queue is full, the cleanup service will attempt to
378
slow down message injection by pausing $in_flow_delay for each message. In this
379
case "maildrop" queue congestion may be a consequence of congestion downstream,
380
rather than a problem in its own right.
382
Note also, that one should not attempt to deliver large volumes of mail via the
383
pickup(8) service. High volume sites must avoid using content filters that
384
reinject scanned mail via Postfix sendmail(1) and postdrop(1).
386
A high arrival rate of locally submitted mail may be an indication of an
387
uncaught forwarding loop, or a run-away notification program. Try to keep the
388
volume of local mail injection to a moderate level.
390
The "postsuper -r" command can place selected messages into the "maildrop"
391
queue for reprocessing. This is most useful for resetting any stale
392
content_filter settings. Requeuing a large number of messages using "postsuper
393
-r" can clearly cause a spike in the size of the "maildrop" queue.
395
TThhee ""hhoolldd"" qquueeuuee
397
The administrator can define "smtpd" access(5) policies, or cleanup(8) header/
398
body checks that cause messages to be automatically diverted from normal
399
processing and placed indefinitely in the "hold" queue. Messages placed in the
400
"hold" queue stay there until the administrator intervenes. No periodic
401
delivery attempts are made for messages in the "hold" queue. The postsuper(1)
402
command can be used to manually release messages into the "deferred" queue.
404
Messages can potentially stay in the "hold" queue for a time exceeding the
405
normal maximal queue lifetime (after which undelivered messages are bounced
406
back to the sender). If such "old" messages need to be released from the "hold"
407
queue, they should typically be moved into the "maildrop" queue, so that the
408
message gets a new timestamp and is given more than one opportunity to be
409
delivered. Messages that are "young" can be moved directly into the "deferred"
412
The "hold" queue plays little role in Postfix performance, and monitoring of
413
the "hold" queue is typically more closely motivated by tracking spam and
414
malware, than by performance issues.
416
TThhee ""iinnccoommiinngg"" qquueeuuee
418
All new mail entering the Postfix queue is written by the cleanup(8) service
419
into the "incoming" queue. New queue files are created owned by the "postfix"
420
user with an access bitmask (or mode) of 0600. Once a queue file is ready for
421
further processing the cleanup(8) service changes the queue file mode to 0700
422
and notifies the queue manager of new mail arrival. The queue manager ignores
423
incomplete queue files whose mode is 0600, as these are still being written by
426
The queue manager scans the incoming queue bringing any new mail into the
427
"active" queue if the active queue resource limits have not been exceeded. By
428
default, the active queue accommodates at most 20000 messages. Once the active
429
queue message limit is reached, the queue manager stops scanning the incoming
430
(and deferred, see below) queue.
432
Under normal conditions the incoming queue is nearly empty (has only mode 0600
433
files), with the queue manager able to import new messages into the active
434
queue as soon as they become available.
436
The incoming queue grows when the message input rate spikes above the rate at
437
which the queue manager can import messages into the active queue. The main
438
factor slowing down the queue manager is transport queries to the trivial-
439
rewrite service. If the queue manager is routinely not keeping up, consider not
440
using "slow" lookup services (MySQL, LDAP, ...) for transport lookups or
441
speeding up the hosts that provide the lookup service.
443
The in_flow_delay parameter is used to clamp the input rate when the queue
444
manager starts to fall behind. The cleanup(8) service will pause for
445
$in_flow_delay seconds before creating a new queue file if it cannot obtain a
446
"token" from the queue manager.
448
Since the number of cleanup(8) processes is limited in most cases by the SMTP
449
server concurrency, the input rate can exceed the output rate by at most "SMTP
450
connection count" / $in_flow_delay messages per second.
452
With a default process limit of 100, and an in_flow_delay of 1s, the coupling
453
is strong enough to limit a single run-away injector to 1 message per second,
454
but is not strong enough to deflect an excessive input rate from many sources
457
If a server is being hammered from multiple directions, consider raising the
458
in_flow_delay to 10 seconds, but only if the incoming queue is growing even
459
while the active queue is not full and the trivial-rewrite service is using a
460
fast transport lookup mechanism.
462
TThhee ""aaccttiivvee"" qquueeuuee
464
The queue manager is a delivery agent scheduler; it works to ensure fast and
465
fair delivery of mail to all destinations within designated resource limits.
467
The active queue is somewhat analogous to an operating system's process run
468
queue. Messages in the active queue are ready to be sent (runnable), but are
469
not necessarily in the process of being sent (running).
471
While most Postfix administrators think of the "active" queue as a directory on
472
disk, the real "active" queue is a set of data structures in the memory of the
473
queue manager process.
475
Messages in the "maildrop", "hold", "incoming" and "deferred" queues (see
476
below) do not occupy memory; they are safely stored on disk waiting for their
477
turn to be processed. The envelope information for messages in the "active"
478
queue is managed in memory, allowing the queue manager to do global scheduling,
479
allocating available delivery agent processes to an appropriate message in the
482
Within the active queue, (multi-recipient) messages are broken up into groups
483
of recipients that share the same transport/nexthop combination; the group size
484
is capped by the transport's recipient concurrency limit.
486
Multiple recipient groups (from one or more messages) are queued for delivery
487
via the common transport/nexthop combination. The destination concurrency limit
488
for the transports caps the number of simultaneous delivery attempts for each
489
nexthop. Transports with a recipient concurrency limit of 1 are special: these
490
are grouped by the actual recipient address rather than the nexthop, thereby
491
enabling per-recipient concurrency limits rather than per-domain concurrency
492
limits. Per-recipient limits are appropriate when performing final delivery to
493
mailboxes rather than when relaying to a remote server.
495
Congestion occurs in the active queue when one or more destinations drain
496
slower than the corresponding message input rate. If a destination is down for
497
some time, the queue manager will mark it dead, and immediately defer all mail
498
for the destination without trying to assign it to a delivery agent. In this
499
case the messages will quickly leave the active queue and end up in the
500
deferred queue. If the destination is instead simply slow, or there is a
501
problem causing an excessive arrival rate the active queue will grow and will
502
become dominated by mail to the congested destination.
504
The only way to reduce congestion is to either reduce the input rate or
505
increase the throughput. Increasing the throughput requires either increasing
506
the concurrency or reducing the latency of deliveries.
508
For high volume sites a key tuning parameter is the number of "smtp" delivery
509
agents allocated to the "smtp" and "relay" transports. High volume sites tend
510
to send to many different destinations, many of which may be down or slow, so a
511
good fraction of the available delivery agents will be blocked waiting for slow
512
sites. Also mail destined across the globe will incur large SMTP command-
513
response latencies, so high message throughput can only be achieved with more
514
concurrent delivery agents.
516
The default "smtp" process limit of 100 is good enough for most sites, and may
517
even need to be lowered for sites with low bandwidth connections (no use
518
increasing concurrency once the network pipe is full). When one finds that the
519
queue is growing on an "idle" system (CPU, disk I/O and network not exhausted)
520
the remaining reason for congestion is insufficient concurrency in the face of
521
a high average latency. If the number of outbound SMTP connections (either
522
ESTABLISHED or SYN_SENT) reaches the process limit, mail is draining slowly and
523
the system and network are not loaded, raise the "smtp" and/or "relay" process
526
Especially for the "relay" transport, consider lower SMTP connection timeouts
527
(1-5 seconds) and higher than default destination concurrency limits. Compute
528
the expected latency when 1 out of N of the MX hosts for a high volume site is
529
down and not responding, and make sure that the configured concurrency divided
530
by this latency exceeds the required steady-state message rate. If the
531
destination is managed by you, consider load balancers in front of groups of MX
532
hosts. Load balancers have higher uptime and will be able to hide individual MX
535
If necessary, dedicate and tune custom transports for high volume destinations.
537
Another common cause of congestion is unwarranted flushing of the entire
538
deferred queue. The deferred queue holds messages that are likely to fail to be
539
delivered and are also likely to be slow to fail delivery (timeouts). This
540
means that the most common reaction to a large deferred queue (flush it!) is
541
more than likely counter- productive, and is likely to make the problem worse.
542
Do not flush the deferred queue unless you expect that most of its content has
543
recently become deliverable (e.g. relayhost back up after an outage)!
545
Note that whenever the queue manager is restarted, there may already be
546
messages in the active queue directory, but the "real" active queue in memory
547
is empty. In order to recover the in-memory state, the queue manager moves all
548
the active queue messages back into the incoming queue, and then uses its
549
normal incoming queue scan to refill the active queue. The process of moving
550
all the messages back and forth, redoing transport table (trivial-rewrite(8)
551
resolve service) lookups, and re-importing the messages back into memory is
552
expensive. At all costs, avoid frequent restarts of the queue manager.
554
TThhee ""ddeeffeerrrreedd"" qquueeuuee
556
When all the deliverable recipients for a message are delivered, and for some
557
recipients delivery failed for a transient reason (it might succeed later), the
558
message is placed in the deferred queue.
560
The queue manager scans the deferred queue periodically. The scan interval is
561
controlled by the queue_run_delay parameter. While a deferred queue scan is in
562
progress, if an incoming queue scan is also in progress (ideally these are
563
brief since the incoming queue should be short), the queue manager alternates
564
between bringing a new "incoming" message and a new "deferred" message into the
565
queue. This "round-robin" strategy prevents starvation of either the incoming
566
or the deferred queues.
568
Each deferred queue scan only brings a fraction of the deferred queue back into
569
the active queue for a retry. This is because each message in the deferred
570
queue is assigned a "cool-off" time when it is deferred. This is done by time-
571
warping the modification times of the queue file into the future. The queue
572
file is not eligible for a retry if its modification time is not yet reached.
574
The "cool-off" time is at least $minimal_backoff_time and at most
575
$maximal_backoff_time. The next retry time is set by doubling the message's age
576
in the queue, and adjusting up or down to lie within the limits. This means
577
that young messages are initially retried more often than old messages.
579
If a high volume site routinely has large deferred queues, it may be useful to
580
adjust the queue_run_delay, minimal_backoff_time and maximal_backoff_time to
581
provide short enough delays on first failure, with perhaps longer delays after
582
multiple failures, to reduce the retransmission rate of old messages and
583
thereby reduce the quantity of previously deferred mail in the active queue.
585
One common cause of large deferred queues is failure to validate recipients at
586
the SMTP input stage. Since spammers routinely launch dictionary attacks from
587
unrepliable sender addresses, the bounces for invalid recipient addresses clog
588
the deferred queue (and at high volumes proportionally clog the active queue).
589
Recipient validation is strongly recommended through use of the
590
local_recipient_maps and relay_recipient_maps parameters.
592
When a host with lots of deferred mail is down for some time, it is possible
593
for the entire deferred queue to reach its retry time simultaneously. This can
594
lead to a very full active queue once the host comes back up. The phenomenon
595
can repeat approximately every maximal_backoff_time seconds if the messages are
596
again deferred after a brief burst of congestion. Ideally, in the future
597
Postfix will add a random offset to the retry time (or use a combination of
598
strategies) to reduce the chances of repeated complete deferred queue flushes.
602
The qshape(1) program was developed by Victor Duchovni of Morgan Stanley, who
603
also wrote the initial version of this document.
added
removed
README_FILES/QSHAPE_README
