2
0
mirror of https://github.com/vdukhovni/postfix synced 2025-08-29 13:18:12 +00:00

postfix-2.6.0-RC1

This commit is contained in:
Wietse Venema 2009-04-15 00:00:00 -05:00 committed by Viktor Dukhovni
parent d41ba831a2
commit 3aaebc8ac7
18 changed files with 577 additions and 372 deletions

View File

@ -15080,3 +15080,14 @@ Apologies for any names omitted.
compatibility. Adding such headers to remote mail can break compatibility. Adding such headers to remote mail can break
DKIM signatures that cover headers that are not present. DKIM signatures that cover headers that are not present.
File: cleanup/cleanup_message.c. File: cleanup/cleanup_message.c.
20090415
Workaround: to avoid unnecessary "fatal" delivery agent
exits, delivery agents retry getting a shared lock on a
queue file. This is necessary since the queue manager's
behavior was changed years ago to refill the in-memory
recipient list before it was completely empty. File:
global/deliver_request.c.
Documentation: updated STRESS_README.

View File

@ -12,6 +12,7 @@ GGeenneerraall ccoonnffiigguurraattiioonn
* TLS_README: TLS Encryption and authentication * TLS_README: TLS Encryption and authentication
* TLS_LEGACY_README: Legacy TLS support * TLS_LEGACY_README: Legacy TLS support
* IPV6_README: IP Version 6 Support * IPV6_README: IP Version 6 Support
* MULTI_INSTANCE_README: Multiple-instance management
* INSTALL: Installation from source code * INSTALL: Installation from source code
PPrroobblleemm ssoollvviinngg PPrroobblleemm ssoollvviinngg

View File

@ -88,9 +88,9 @@ Notes:
attribute, sends the attribute with an empty value ("name="), or sends a attribute, sends the attribute with an empty value ("name="), or sends a
zero value ("name=0") in the case of a numerical attribute. zero value ("name=0") in the case of a numerical attribute.
* The "recipient" attribute is available only in the "RCPT TO" stage, and in * The "recipient" attribute is available in the "RCPT TO" stage. It is also
the "DATA" and "END-OF-MESSAGE" stages when Postfix accepted only one available in the "DATA" and "END-OF-MESSAGE" stages if Postfix accepted
recipient for the current message. only one recipient for the current message.
* The "recipient_count" attribute (Postfix 2.3 and later) is non-zero only in * The "recipient_count" attribute (Postfix 2.3 and later) is non-zero only in
the "DATA" and "END-OF-MESSAGE" stages. It specifies the number of the "DATA" and "END-OF-MESSAGE" stages. It specifies the number of

View File

@ -4,12 +4,11 @@ PPoossttffiixx SSttrreessss--DDeeppeennddeenntt CCoonn
OOvveerrvviieeww OOvveerrvviieeww
This document describes the symptoms of Postfix SMTP server overload, and how This document describes the symptoms of Postfix SMTP server overload. It
to avoid the condition under normal conditions. When the condition is caused by presents permanent main.cf changes to avoid overload during normal operation,
botnets or other malware, the document suggests configuration settings that and temporary main.cf changes to cope with an unexpected burst of mail. This
help to minimize the impact on legitimate mail. Finally, the document document makes specific suggestions for Postfix 2.5 and later which support
introduces stress-adaptive behavior, introduced with Postfix 2.5, and how it stress-adaptive behavior, and for earlier Postfix versions that don't.
can be used to automatically switch configuration settings under overload.
Topics covered in this document: Topics covered in this document:
@ -17,42 +16,46 @@ Topics covered in this document:
* Service more SMTP clients at the same time * Service more SMTP clients at the same time
* Spend less time per SMTP client * Spend less time per SMTP client
* Disconnect suspicious SMTP clients * Disconnect suspicious SMTP clients
* Take desperate measures * Temporary measures for older Postfix releases
* Make Postfix behavior stress-adaptive * Automatic stress-adaptive behavior
* Detecting support for stress-adaptive behavior * Detecting support for stress-adaptive behavior
* Forcing stress-adaptive behavior on or off * Forcing stress-adaptive behavior on or off
* Other measures to off-load zombies
* Credits * Credits
SSyymmppttoommss ooff PPoossttffiixx SSMMTTPP sseerrvveerr oovveerrllooaadd SSyymmppttoommss ooff PPoossttffiixx SSMMTTPP sseerrvveerr oovveerrllooaadd
Under normal conditions, Postfix responds immediately when a remote SMTP client Under normal conditions, the Postfix SMTP server responds immediately when an
connects. The time needed to deliver mail should be noticeable only with very SMTP client connects to it; the time to deliver mail is noticeable only with
large messages. Performance degrades more dramatically when the number of large messages. Performance degrades dramatically when the number of SMTP
remote SMTP clients exceeds the number of Postfix SMTP server processes. When a clients exceeds the number of Postfix SMTP server processes. When an SMTP
client connects while all server processes are busy, the client must wait until client connects while all Postfix SMTP server processes are busy, the client
a server process becomes available. must wait until a server process becomes available.
Overload may be caused by a legitimate mail (example: a DNS registrar opens a SMTP server overload may be caused by a surge of legitimate mail (example: a
new zone for registrations), by mistake (mail explosion caused by a forwarding DNS registrar opens a new zone for registrations), by mistake (mail explosion
loop) or by illegitimate mail (worm outbreak, botnet, or other malware caused by a forwarding loop) or by malice (worm outbreak, botnet, or other
activity). Symptoms of Postfix SMTP mail server overload are: illegitimate activity).
Symptoms of Postfix SMTP server overload are:
* Remote SMTP clients experience a long delay before Postfix sends the "220 * Remote SMTP clients experience a long delay before Postfix sends the "220
hostname.example.com ESMTP Postfix" greeting. If this affects end-user mail hostname.example.com ESMTP Postfix" greeting.
clients, enable the "submission" service entry in master.cf (present since
Postfix 2.1), and tell users to connect to this instead of the public SMTP
service.
o NOTE: Broken DNS configurations also cause lengthy delays before o NOTE: Broken DNS configurations can also cause lengthy delays before
Postfix sends "220 hostname.example.com ...". In this case the delay Postfix sends "220 hostname.example.com ...". These delays also exist
happens even when Postfix is not busy. when Postfix is NOT overloaded.
o NOTE: To avoid "overload" delays for end-user mail clients, enable the
"submission" service entry in master.cf (present since Postfix 2.1),
and tell users to connect to this instead of the public SMTP service.
* The Postfix SMTP server logs an increased number of "lost connection after * The Postfix SMTP server logs an increased number of "lost connection after
CONNECT" events. This happens because remote SMTP clients disconnect before CONNECT" events. This happens because remote SMTP clients disconnect before
Postfix answers the connection. Postfix answers the connection.
o NOTE: A portscan for open SMTP ports also results in "lost connection o NOTE: A portscan for open SMTP ports can also result in "lost
..." logfile messages. connection ..." logfile messages.
* Postfix 2.3 and later logs a warning that all server ports are busy: * Postfix 2.3 and later logs a warning that all server ports are busy:
@ -63,15 +66,16 @@ activity). Symptoms of Postfix SMTP mail server overload are:
condition, increase the process count in master.cf or reduce the condition, increase the process count in master.cf or reduce the
service time per client service time per client
Legitimate mail that doesn't get through during an episode of overload is not Legitimate mail that doesn't get through during an episode of Postfix SMTP
necessarily lost. It should still arrive once the situation returns to normal, server overload is not necessarily lost. It should still arrive once the
as long as the overload condition is temporary. situation returns to normal, as long as the overload condition is temporary.
SSeerrvviiccee mmoorree SSMMTTPP cclliieennttss aatt tthhee ssaammee ttiimmee SSeerrvviiccee mmoorree SSMMTTPP cclliieennttss aatt tthhee ssaammee ttiimmee
To service more SMTP clients simultaneously, you need to increase the number of One measure to avoid the "all server processes busy" condition is to service
SMTP server processes. This will improve the responsiveness for remote SMTP more SMTP clients simultaneously. For this you need to increase the number of
clients, as long as the server machine has enough hardware and software Postfix SMTP server processes. This will improve the responsiveness for remote
SMTP clients, as long as the server machine has enough hardware and software
resources to run the additional processes, and as long as the file system can resources to run the additional processes, and as long as the file system can
keep up with the additional load. keep up with the additional load.
@ -84,8 +88,9 @@ keep up with the additional load.
operating system that supports kernel-based event filters (BSD kqueue(2), operating system that supports kernel-based event filters (BSD kqueue(2),
Linux epoll(4), or Solaris /dev/poll). Linux epoll(4), or Solaris /dev/poll).
* You can reduce the Postfix memory footprint by using cdb: lookup tables * More processes use more memory. You can reduce the Postfix memory footprint
instead of Berkeley DB's hash: or btree: tables. by using cdb: lookup tables instead of Berkeley DB's hash: or btree:
tables.
1 /etc/postfix/main.cf: 1 /etc/postfix/main.cf:
2 # Raise the global process limit, 100 since Postfix 2.0. 2 # Raise the global process limit, 100 since Postfix 2.0.
@ -120,9 +125,9 @@ keep up with the additional load.
SSppeenndd lleessss ttiimmee ppeerr SSMMTTPP cclliieenntt SSppeenndd lleessss ttiimmee ppeerr SSMMTTPP cclliieenntt
When increasing the number of SMTP server processes is not practical, you can When increasing the number of SMTP server processes is not practical, you can
improve Postfix server responsiveness by eliminating unnecessary work. When improve Postfix server responsiveness by eliminating delays. When Postfix
Postfix spends less time per SMTP session, the same number of SMTP server spends less time per SMTP session, the same number of SMTP server processes can
processes can service more clients in the same amount of time. service more clients in a given amount of time.
* Eliminate non-functional RBL lookups (blocklists that are no longer in * Eliminate non-functional RBL lookups (blocklists that are no longer in
operation). These lookups can degrade performance. Postfix logs a warning operation). These lookups can degrade performance. Postfix logs a warning
@ -137,18 +142,18 @@ processes can service more clients in the same amount of time.
BACKSCATTER_README for examples of the latter. BACKSCATTER_README for examples of the latter.
* Group your header_checks and body_checks patterns to avoid unnecessary * Group your header_checks and body_checks patterns to avoid unnecessary
pattern matching operations. pattern matching operations:
1 /etc/postfix/header_checks: 1 /etc/postfix/header_checks:
2 if /^Subject:/ 2 if /^Subject:/
3 /^Subject: virus found in mail from you/ reject 3 /^Subject: virus found in mail from you/ reject
4 /^Subject: ..../ .... 4 /^Subject: ..other../ reject
5 endif 5 endif
6 6
7 if /^Received:/ 7 if /^Received:/
8 /^Received: from (postfix\.org) / reject forged client name in 8 /^Received: from (postfix\.org) / reject forged client name in
received header: $1 received header: $1
9 /^Received: from .../ .... 9 /^Received: from ..other../ reject ....
10 endif 10 endif
DDiissccoonnnneecctt ssuussppiicciioouuss SSMMTTPP cclliieennttss DDiissccoonnnneecctt ssuussppiicciioouuss SSMMTTPP cclliieennttss
@ -157,14 +162,16 @@ Under conditions of overload you can improve Postfix SMTP server responsiveness
by hanging up on suspicious clients, so that other clients get a chance to talk by hanging up on suspicious clients, so that other clients get a chance to talk
to Postfix. to Postfix.
* Use "521" reply codes (Postfix 2.6 and later) for botnet-related RBLs or * Use "521" SMTP reply codes (Postfix 2.6 and later) or "421" (Postfix 2.3-
for selected non-RBL restrictions. With Postfix 2.3-2.5 use "421" for a 2.5) to hang up on clients that that match botnet-related RBLs (see next
similar result. The Postfix SMTP server will disconnect immediately without bullet) or that match selected non-RBL restrictions such as SMTP access
maps. The Postfix SMTP server will reject mail and disconnect without
waiting for the remote SMTP client to send a QUIT command. waiting for the remote SMTP client to send a QUIT command.
You can set individual reject codes for RBLs, and for individual responses * To hang up connections from blacklisted zombies, you can set specific
from a specific RBL. We'll use zen.spamhaus.org as an example; by the time Postfix SMTP server reject codes for specific RBLs, and for individual
you read this document, details may have changed. Right now, their responses from specific RBLs. We'll use zen.spamhaus.org as an example; by
the time you read this document, details may have changed. Right now, their
documents say that a response of 127.0.0.10 or 127.0.0.11 indicates a documents say that a response of 127.0.0.10 or 127.0.0.11 indicates a
dynamic client IP address, which means that the machine is probably running dynamic client IP address, which means that the machine is probably running
a bot of some kind. To give a 521 response instead of the default 554 a bot of some kind. To give a 521 response instead of the default 554
@ -180,37 +187,45 @@ to Postfix.
8 rbl_reply_maps = hash:/etc/postfix/rbl_reply_maps 8 rbl_reply_maps = hash:/etc/postfix/rbl_reply_maps
9 9
10 /etc/postfix/rbl_reply_maps: 10 /etc/postfix/rbl_reply_maps:
11 zen.spamhaus.org=127.0.0.10 521 4.7.1 Service unavailable; 11 # With Postfix 2.3-2.5 use "421" to hang up connections.
12 $rbl_class [$rbl_what] blocked using 12 zen.spamhaus.org=127.0.0.10 521 4.7.1 Service unavailable;
13 $rbl_domain${rbl_reason?; $rbl_reason} 13 $rbl_class [$rbl_what] blocked using
14 14 $rbl_domain${rbl_reason?; $rbl_reason}
15 zen.spamhaus.org=127.0.0.11 521 4.7.1 Service unavailable; 15
16 $rbl_class [$rbl_what] blocked using 16 zen.spamhaus.org=127.0.0.11 521 4.7.1 Service unavailable;
17 $rbl_domain${rbl_reason?; $rbl_reason} 17 $rbl_class [$rbl_what] blocked using
18 $rbl_domain${rbl_reason?; $rbl_reason}
Although the above shows three RBL lookups (lines 4-6), Postfix will still Although the above example shows three RBL lookups (lines 4-6), Postfix
only do a single DNS query, so the performance difference is negligible. will only do a single DNS query, so it does not affect the performance.
With Postfix 2.3-2.5, use 421 (reply code 521 will not cause Postfix to * With Postfix 2.3-2.5, use reply code 421 (521 will not cause Postfix to
disconnect). The down-side of sending 421 is that it works only for zombies disconnect). The down-side of replying with 421 is that it works only for
and other malware. If the client is running a real MTA, then it may connect zombies and other malware. If the client is running a real MTA, then it may
again several times until the mail expires in its queue. When this is a connect again several times until the mail expires in its queue. When this
problem, stick with the default 554 reply, and use "smtpd_hard_error_limit is a problem, stick with the default 554 reply, and use
= 1" as described below. "smtpd_hard_error_limit = 1" as described below.
With Postfix 2.5, or with earlier releases that contain the stress-adaptive * You can automatically turn on the above overload measure with Postfix 2.5
behavior patch, you can turn on the above under overload by replacing line and later, or with earlier releases that contain the stress-adaptive
8 with: behavior source code patch from the mirrors listed at http://
www.postfix.org/download.html. Simply replace line above 8 with:
8 rbl_reply_maps = ${stress?hash:/etc/postfix/rbl_reply_maps} 8 rbl_reply_maps = ${stress?hash:/etc/postfix/rbl_reply_maps}
More information about automatic stress-adaptive behavior is at the end of More information about automatic stress-adaptive behavior is in section
this document. "Automatic stress-adaptive behavior".
TTaakkee ddeessppeerraattee mmeeaassuurreess TTeemmppoorraarryy mmeeaassuurreess ffoorr oollddeerr PPoossttffiixx rreelleeaasseess
The following measures will still allow mmoosstt legitimate clients to connect and See the next section, "Automatic stress-adaptive behavior", if you are running
send mail, but may affect some legitimate clients. Postfix version 2.5 or later, or if you have applied the source code patch for
stress-adaptive behavior from the mirrors listed at http://www.postfix.org/
download.html.
The following measures can be applied temporarily during overload. They still
allow mmoosstt legitimate clients to connect and send mail, but may affect some
legitimate clients.
* Reduce smtpd_timeout (default: 300s). Experience on the postfix-users list * Reduce smtpd_timeout (default: 300s). Experience on the postfix-users list
from a variety of sysadmins shows that reducing the "normal" smtpd_timeout from a variety of sysadmins shows that reducing the "normal" smtpd_timeout
@ -228,55 +243,75 @@ send mail, but may affect some legitimate clients.
longer-active user names that didn't bother to unsubscribe. No mail should longer-active user names that didn't bother to unsubscribe. No mail should
be lost, as long as this measure is used only temporarily. be lost, as long as this measure is used only temporarily.
* Disable remote SMTP client hostname lookups, so that all SMTP client * Use an smtpd_junk_command_limit of 1 instead of the default 100. This
hostnames become "unknown" (line 5 below). This feature was introduced with prevents clients from keeping idle connections open by repeatedly sending
Postfix 2.3. Unfortunately, this measure is more problematic than the other NOOP or RSET commands.
ones proposed sofar. First, this will result in loss of mail when you use
hostname-based access rules that reject mail from "unknown" SMTP clients
(examples: reject_unknown_client_hostname,
reject_unknown_reverse_client_hostname). Second, this may result in loss of
mail when you subject "unknown" SMTP clients to additional restrictions
such as reject_unverified_sender.
1 /etc/postfix/main.cf: 1 /etc/postfix/main.cf:
2 smtpd_timeout = 10 2 smtpd_timeout = 10
3 smtpd_hard_error_limit = 1 3 smtpd_hard_error_limit = 1
4 # Caution: line 5 may trigger REJECTs by hostname-based access rules 4 smtpd_junk_command_limit = 1
5 smtpd_peername_lookup = no With these measures, no mail should be lost, as long as these measures are used
only temporarily. The next section of this document introduces a way to
automate this process.
Except with the last measure, no mail should be lost, as long as these measures AAuuttoommaattiicc ssttrreessss--aaddaappttiivvee bbeehhaavviioorr
are used only temporarily. The next section of this document introduces a way
to automate this process.
MMaakkee PPoossttffiixx bbeehhaavviioorr ssttrreessss--aaddaappttiivvee
Postfix version 2.5 introduces automatic stress-adaptive behavior. This is also Postfix version 2.5 introduces automatic stress-adaptive behavior. This is also
available as an add-on patch for Postfix versions 2.4 and 2.3 from the mirrors available as a source code patch for Postfix versions 2.4 and 2.3 from the
listed at http://www.postfix.org/download.html. mirrors listed at http://www.postfix.org/download.html.
It works as follows. When a "public" network service runs into an "all server It works as follows. When a "public" network service such as the SMTP server
ports are busy" condition, the master(8) daemon logs a warning, restarts the runs into an "all server ports are busy" condition, the Postfix master(8)
service (without interrupting existing network sessions), and runs the service daemon logs a warning, restarts the service (without interrupting existing
with "-o stress=yes" on the command line. Normally, it runs a stress-adaptive network sessions), and runs the service with "-o stress=yes" on the server
service with "-o stress=" on the command line (i.e. with an empty parameter process command line:
value). Other services never have "-o stress" parameters on the command line,
including services that listen on a loopback interface only.
The stress pseudo-parameter value is the key to making main.cf parameter 80821 ?? S 0:00.24 smtpd -n smtp -t inet -u -c -o stress=yes
settings stress adaptive:
1 /etc/postfix/main.cf: Normally, the Postfix master(8) daemon runs such a service with "-o stress=" on
2 smtpd_timeout = ${stress?10}${stress:300} the command line (i.e. with an empty parameter value):
3 smtpd_hard_error_limit = ${stress?1}${stress:20}
83326 ?? S 0:00.28 smtpd -n smtp -t inet -u -c -o stress=
Services that have local access only never have "-o stress" parameters on the
command line. This includes services internal to Postfix such as the queue
manager, and services that listen on a loopback interface only, such as after-
filter SMTP services.
The "stress" parameter value is the key to making main.cf parameter settings
stress adaptive. The following settings are the default with Postfix 2.6 and
later. With earlier Postfix versions that have stress-adaptive support, append
the lines below to the main.cf file and issue a "postfix reload" command:
1 smtpd_timeout = ${stress?10}${stress:300}s
2 smtpd_hard_error_limit = ${stress?1}${stress:20}
3 smtpd_junk_command_limit = ${stress?1}${stress:100}
Translation: Translation:
* Line 2: under conditions of stress, use an smtpd_timeout value of 10 * Line 1: under conditions of stress, use an smtpd_timeout value of 10
seconds instead of the default 300 seconds, seconds instead of the default 300 seconds. Experience on the postfix-users
list from a variety of sysadmins shows that reducing the "normal"
smtpd_timeout to 60s is unlikely to affect legitimate clients. However, it
is unlikely to become the Postfix default because it's not RFC compliant.
Setting smtpd_timeout to 10s (line 2 below) or even 5s under stress will
still allow most legitimate clients to connect and send mail, but may delay
mail from some clients. No mail should be lost, as long as this measure is
used only temporarily.
* Line 3: under conditions of stress, use an smtpd_hard_error_limit of 1 * Line 2: under conditions of stress, use an smtpd_hard_error_limit of 1
instead of the default 20. instead of the default 20. This helps by disconnecting clients after a
single error, giving other clients a chance to connect. However, this may
cause significant delays with legitimate mail, such as a mailing list that
contains a few no-longer-active user names that didn't bother to
unsubscribe. No mail should be lost, as long as this measure is used only
temporarily.
* Line 3: under conditions of stress, use an smtpd_junk_command_limit of 1
instead of the default 100. This prevents clients from keeping idle
connections open by repeatedly sending NOOP or RSET commands.
The syntax of ${name?value} and ${name:value} is explained at the beginning of The syntax of ${name?value} and ${name:value} is explained at the beginning of
the postconf(5) manual page. the postconf(5) manual page.
@ -346,6 +381,18 @@ accept remote connections.
7 -o stress= 7 -o stress=
8 -o . . . 8 -o . . .
OOtthheerr mmeeaassuurreess ttoo ooffff--llooaadd zzoommbbiieess
OpenBSD spamd implements a daemon that handles all connections from "new"
clients. Only well-behaved mail clients are allowed to talk to the mail server.
Other clients are tarpitted, and will never get a chance to affect mail server
performance.
At some point in the future, Postfix may come with a simple front-end daemon
that does basic greylisting and pipelining detection to keep zombies and other
ratware away from Postfix itself. This would use the "pass" service type which
has been available in stable Postfix releases since Postfix 2.5.
CCrreeddiittss CCrreeddiittss
* Thanks to the postfix-users mailing list members for sharing early * Thanks to the postfix-users mailing list members for sharing early

View File

@ -9,25 +9,18 @@ Wish list:
compatibility. The "first" setting is good for performance compatibility. The "first" setting is good for performance
(stress=yes) when all users are defined in local files. (stress=yes) when all users are defined in local files.
Make the double-bounce address time-dependent (with 24-hour
grace period). Spammers appear to use this address to avoid
DATA command rejects. Avoiding DATA rejects means they can
pipeline the entire SMTP session without triggering huge
numbers of protocol errors. They can still trigger "improper
command pipelining after DATA" alarms, but that requires
non-default main.cf settings.
Cleanup: make DNSBL query format configurable beyond the Cleanup: make DNSBL query format configurable beyond the
client's reversed IP address. client's reversed IP address.
With 'final delivery' in the LMTP client, need an option With 'final delivery' in the LMTP client, need an option
to also add delivered-to and other pipe(8) features. to also add delivered-to and other pipe(8) features. This
This requires making mail_copy() more generic. requires making mail_copy() functionality available in
non-mailbox context.
To work around historical AWK's limit of 10 open files, To work around historical AWK's limit of 10 open files,
pipe all output into a shell and have the shell open files. pipe all output into a shell and have the shell open files.
It's too much pain to find out whose AWK is old and where It's too much pain to find out what systems use ancient AWK
if any they keep the XPG4 compliant version. and where, if any, they keep the XPG4 compliant version.
Cleanup: modernize the "add missing From: header" code, to Cleanup: modernize the "add missing From: header" code, to
``phrase <addr>'' form. Most likely, quote the entire phrase ``phrase <addr>'' form. Most likely, quote the entire phrase

View File

@ -126,10 +126,10 @@ stress=
an empty value ("name="), or sends a zero value ("name=0") in an empty value ("name="), or sends a zero value ("name=0") in
the case of a numerical attribute. </p> the case of a numerical attribute. </p>
<li> <p> The "recipient" attribute is available only in the <li> <p> The "recipient" attribute is available in the "RCPT
"RCPT TO" stage, and in the "DATA" and "END-OF-MESSAGE" stages TO" stage. It is also available in the "DATA" and "END-OF-MESSAGE"
when Postfix accepted only one recipient for the current message. stages if Postfix accepted only one recipient for the current
</p> message. </p>
<li> <p> The "recipient_count" attribute (Postfix 2.3 and later) <li> <p> The "recipient_count" attribute (Postfix 2.3 and later)
is non-zero only in the "DATA" and "END-OF-MESSAGE" stages. It is non-zero only in the "DATA" and "END-OF-MESSAGE" stages. It

View File

@ -21,13 +21,11 @@ Stress-Dependent Configuration</h1>
<h2>Overview </h2> <h2>Overview </h2>
<p> This document describes the symptoms of Postfix SMTP server <p> This document describes the symptoms of Postfix SMTP server
overload, and how to avoid the condition under normal conditions. overload. It presents permanent <a href="postconf.5.html">main.cf</a> changes to avoid overload
When the condition is caused by botnets or other malware, the during normal operation, and temporary <a href="postconf.5.html">main.cf</a> changes to cope with
document suggests configuration settings that help to minimize the an unexpected burst of mail. This document makes specific suggestions
impact on legitimate mail. Finally, the document introduces for Postfix 2.5 and later which support stress-adaptive behavior,
stress-adaptive behavior, introduced with Postfix 2.5, and how it and for earlier Postfix versions that don't. </p>
can be used to automatically switch configuration settings under
overload. </p>
<p> Topics covered in this document: </p> <p> Topics covered in this document: </p>
@ -41,47 +39,52 @@ overload. </p>
<li><a href="#hangup"> Disconnect suspicious SMTP clients </a> <li><a href="#hangup"> Disconnect suspicious SMTP clients </a>
<li><a href="#desperate"> Take desperate measures </a> <li><a href="#legacy"> Temporary measures for older Postfix releases </a>
<li><a href="#adapt"> Make Postfix behavior stress-adaptive </a> <li><a href="#adapt"> Automatic stress-adaptive behavior </a>
<li><a href="#feature"> Detecting support for stress-adaptive behavior </a> <li><a href="#feature"> Detecting support for stress-adaptive behavior </a>
<li><a href="#forcing"> Forcing stress-adaptive behavior on or off </a> <li><a href="#forcing"> Forcing stress-adaptive behavior on or off </a>
<li><a href="#other"> Other measures to off-load zombies </a>
<li><a href="#credits"> Credits </a> <li><a href="#credits"> Credits </a>
</ul> </ul>
<h2><a name="overload"> Symptoms of Postfix SMTP server overload </a></h2> <h2><a name="overload"> Symptoms of Postfix SMTP server overload </a></h2>
<p> Under normal conditions, Postfix responds immediately when a <p> Under normal conditions, the Postfix SMTP server responds
remote SMTP client connects. The time needed to deliver mail should immediately when an SMTP client connects to it; the time to deliver
be noticeable only with very large messages. Performance degrades mail is noticeable only with large messages. Performance degrades
more dramatically when the number of remote SMTP clients exceeds dramatically when the number of SMTP clients exceeds the number of
the number of Postfix SMTP server processes. When a client connects Postfix SMTP server processes. When an SMTP client connects while
while all server processes are busy, the client must wait until a all Postfix SMTP server processes are busy, the client must wait
server process becomes available. </p> until a server process becomes available. </p>
<p> Overload may be caused by a legitimate mail (example: a DNS <p> SMTP server overload may be caused by a surge of legitimate
registrar opens a new zone for registrations), by mistake (mail mail (example: a DNS registrar opens a new zone for registrations),
explosion caused by a forwarding loop) or by illegitimate mail (worm by mistake (mail explosion caused by a forwarding loop) or by malice
outbreak, botnet, or other malware activity). Symptoms of Postfix (worm outbreak, botnet, or other illegitimate activity). </p>
SMTP mail server overload are: </p>
<p> Symptoms of Postfix SMTP server overload are: </p>
<ul> <ul>
<li> <p> Remote SMTP clients experience a long delay before Postfix <li> <p> Remote SMTP clients experience a long delay before Postfix
sends the "220 hostname.example.com ESMTP Postfix" greeting. If sends the "220 hostname.example.com ESMTP Postfix" greeting. </p>
this affects end-user mail clients, enable the "submission" service
entry in <a href="master.5.html">master.cf</a> (present since Postfix 2.1), and tell users to
connect to this instead of the public SMTP service. </p>
<ul> <ul>
<li> <p> NOTE: Broken DNS configurations also cause lengthy delays <li> <p> NOTE: Broken DNS configurations can also cause lengthy
before Postfix sends "220 hostname.example.com ...". In this case delays before Postfix sends "220 hostname.example.com ...". These
the delay happens even when Postfix is not busy. </p> delays also exist when Postfix is NOT overloaded. </p>
<li> <p> NOTE: To avoid "overload" delays for end-user mail
clients, enable the "submission" service entry in <a href="master.5.html">master.cf</a> (present
since Postfix 2.1), and tell users to connect to this instead of
the public SMTP service. </p>
</ul> </ul>
@ -91,8 +94,8 @@ clients disconnect before Postfix answers the connection. </p>
<ul> <ul>
<li> <p> NOTE: A portscan for open SMTP ports also results in "lost <li> <p> NOTE: A portscan for open SMTP ports can also result in
connection ..." logfile messages. </p> "lost connection ..." logfile messages. </p>
</ul> </ul>
@ -111,14 +114,16 @@ Oct 3 20:39:27 spike postfix/master[28905]: warning: to avoid this
</ul> </ul>
<p> Legitimate mail that doesn't get through during an episode of <p> Legitimate mail that doesn't get through during an episode of
overload is not necessarily lost. It should still arrive once the Postfix SMTP server overload is not necessarily lost. It should
situation returns to normal, as long as the overload condition is still arrive once the situation returns to normal, as long as the
temporary. </p> overload condition is temporary. </p>
<h2><a name="concurrency"> Service more SMTP clients at the same time </a> </h2> <h2><a name="concurrency"> Service more SMTP clients at the same time </a> </h2>
<p> To service more SMTP clients simultaneously, you need to increase <p> One measure to avoid the "all server processes busy" condition
the number of SMTP server processes. This will improve the is to service more SMTP clients simultaneously. For this you need
to increase the number of Postfix SMTP server processes. This will
improve the
responsiveness for remote SMTP clients, as long as the server machine responsiveness for remote SMTP clients, as long as the server machine
has enough hardware and software resources to run the additional has enough hardware and software resources to run the additional
processes, and as long as the file system can keep up with the processes, and as long as the file system can keep up with the
@ -137,7 +142,8 @@ later, and an operating system that supports kernel-based event
filters (BSD kqueue(2), Linux epoll(4), or Solaris /dev/poll). filters (BSD kqueue(2), Linux epoll(4), or Solaris /dev/poll).
</p> </p>
<li> <p> You can reduce the Postfix memory footprint by using <a href="CDB_README.html">cdb</a>: <li> <p> More processes use more memory. You can reduce the Postfix
memory footprint by using <a href="CDB_README.html">cdb</a>:
lookup tables instead of Berkeley DB's hash: or btree: tables. </p> lookup tables instead of Berkeley DB's hash: or btree: tables. </p>
<pre> <pre>
@ -181,9 +187,9 @@ Issue a "postfix reload" command to make the change effective. </p>
<p> When increasing the number of SMTP server processes is not <p> When increasing the number of SMTP server processes is not
practical, you can improve Postfix server responsiveness by eliminating practical, you can improve Postfix server responsiveness by eliminating
unnecessary work. When Postfix spends less time per SMTP session, the delays. When Postfix spends less time per SMTP session, the same
same number of SMTP server processes can service more clients in the number of SMTP server processes can service more clients in a given
same amount of time. </p> amount of time. </p>
<ul> <ul>
@ -201,18 +207,18 @@ emergency patterns to block the latest worm explosion or backscatter
mail. See <a href="BACKSCATTER_README.html">BACKSCATTER_README</a> for examples of the latter. mail. See <a href="BACKSCATTER_README.html">BACKSCATTER_README</a> for examples of the latter.
<li> <p> Group your <a href="postconf.5.html#header_checks">header_checks</a> and <a href="postconf.5.html#body_checks">body_checks</a> patterns to avoid <li> <p> Group your <a href="postconf.5.html#header_checks">header_checks</a> and <a href="postconf.5.html#body_checks">body_checks</a> patterns to avoid
unnecessary pattern matching operations. unnecessary pattern matching operations:
<pre> <pre>
1 /etc/postfix/header_checks: 1 /etc/postfix/header_checks:
2 if /^Subject:/ 2 if /^Subject:/
3 /^Subject: virus found in mail from you/ reject 3 /^Subject: virus found in mail from you/ reject
4 /^Subject: ..../ .... 4 /^Subject: ..other../ reject
5 endif 5 endif
6 6
7 if /^Received:/ 7 if /^Received:/
8 /^Received: from (postfix\.org) / reject forged client name in received header: $1 8 /^Received: from (postfix\.org) / reject forged client name in received header: $1
9 /^Received: from .../ .... 9 /^Received: from ..other../ reject ....
10 endif 10 endif
</pre> </pre>
@ -226,20 +232,22 @@ clients get a chance to talk to Postfix. </p>
<ul> <ul>
<li> <p> Use "521" reply codes (Postfix 2.6 and later) for <li> <p> Use "521" SMTP reply codes (Postfix 2.6 and later) or "421"
botnet-related RBLs or for selected non-RBL restrictions. With (Postfix 2.3-2.5) to hang up on clients that that match botnet-related
Postfix 2.3-2.5 use "421" for a similar result. The Postfix SMTP RBLs (see next bullet) or that match selected non-RBL restrictions
server will disconnect immediately without waiting for the remote such as SMTP access maps. The Postfix SMTP server will reject mail
SMTP client to send a QUIT command. </p> and disconnect without waiting for the remote SMTP client to send
a QUIT command. </p>
<p> You can set individual reject codes for RBLs, and for individual <li> <p> To hang up connections from blacklisted zombies, you can
responses from a specific RBL. We'll use zen.spamhaus.org as an set specific Postfix SMTP server reject codes for specific RBLs,
example; by the time you read this document, details may have and for individual responses from specific RBLs. We'll use
changed. Right now, their documents say that a response of 127.0.0.10 zen.spamhaus.org as an example; by the time you read this document,
or 127.0.0.11 indicates a dynamic client IP address, which means details may have changed. Right now, their documents say that a
that the machine is probably running a bot of some kind. To give response of 127.0.0.10 or 127.0.0.11 indicates a dynamic client IP
a 521 response instead of the default 554 response, use something address, which means that the machine is probably running a bot of
like: </p> some kind. To give a 521 response instead of the default 554
response, use something like: </p>
<pre> <pre>
1 /etc/postfix/<a href="postconf.5.html">main.cf</a>: 1 /etc/postfix/<a href="postconf.5.html">main.cf</a>:
@ -252,45 +260,55 @@ like: </p>
8 <a href="postconf.5.html#rbl_reply_maps">rbl_reply_maps</a> = hash:/etc/postfix/rbl_reply_maps 8 <a href="postconf.5.html#rbl_reply_maps">rbl_reply_maps</a> = hash:/etc/postfix/rbl_reply_maps
9 9
10 /etc/postfix/rbl_reply_maps: 10 /etc/postfix/rbl_reply_maps:
11 zen.spamhaus.org=127.0.0.10 521 4.7.1 Service unavailable; 11 # With Postfix 2.3-2.5 use "421" to hang up connections.
12 $rbl_class [$rbl_what] blocked using 12 zen.spamhaus.org=127.0.0.10 521 4.7.1 Service unavailable;
13 $rbl_domain${rbl_reason?; $rbl_reason} 13 $rbl_class [$rbl_what] blocked using
14 14 $rbl_domain${rbl_reason?; $rbl_reason}
15 zen.spamhaus.org=127.0.0.11 521 4.7.1 Service unavailable; 15
16 $rbl_class [$rbl_what] blocked using 16 zen.spamhaus.org=127.0.0.11 521 4.7.1 Service unavailable;
17 $rbl_domain${rbl_reason?; $rbl_reason} 17 $rbl_class [$rbl_what] blocked using
18 $rbl_domain${rbl_reason?; $rbl_reason}
</pre> </pre>
<p> Although the above shows three RBL lookups (lines 4-6), Postfix <p> Although the above example shows three RBL lookups (lines 4-6),
will still only do a single DNS query, so the performance difference Postfix will only do a single DNS query, so it does not affect the
is negligible. </p> performance. </p>
<p> With Postfix 2.3-2.5, use 421 (reply code 521 will not cause <li> <p> With Postfix 2.3-2.5, use reply code 421 (521 will not
Postfix to disconnect). The down-side of sending 421 is that cause Postfix to disconnect). The down-side of replying with 421
it works only for zombies and other malware. If the client is running is that it works only for zombies and other malware. If the client
a real MTA, then it may connect again several times until the mail is running a real MTA, then it may connect again several times until
expires in its queue. When this is a problem, stick with the default the mail expires in its queue. When this is a problem, stick with
554 reply, and use "<a href="postconf.5.html#smtpd_hard_error_limit">smtpd_hard_error_limit</a> = 1" as described below. the default 554 reply, and use "<a href="postconf.5.html#smtpd_hard_error_limit">smtpd_hard_error_limit</a> = 1" as
</p> described below. </p>
<p> With Postfix 2.5, or with earlier releases that contain the <li> <p> You can automatically turn on the above overload measure
stress-adaptive behavior patch, you can turn on the above under with Postfix 2.5 and later, or with earlier releases that contain
overload by replacing line 8 with: </p> the stress-adaptive behavior source code patch from the mirrors
listed at <a href="http://www.postfix.org/download.html">http://www.postfix.org/download.html</a>. Simply replace line
above 8 with: </p>
<pre> <pre>
8 <a href="postconf.5.html#rbl_reply_maps">rbl_reply_maps</a> = ${stress?hash:/etc/postfix/rbl_reply_maps} 8 <a href="postconf.5.html#rbl_reply_maps">rbl_reply_maps</a> = ${stress?hash:/etc/postfix/rbl_reply_maps}
</pre> </pre>
<p> More information about automatic stress-adaptive behavior is
at the end of this document. </p>
</ul> </ul>
<h2><a name="desperate"> Take desperate measures </a></h2> <p> More information about automatic stress-adaptive behavior is
in section "<a href="#adapt">Automatic stress-adaptive behavior</a>".
</p>
<p> The following measures will still allow <b>most</b> legitimate <h2><a name="legacy"> Temporary measures for older Postfix releases </a></h2>
clients to connect and send mail, but may affect some legitimate
clients. </p> <p> See the next section, "<a href="#adapt">Automatic stress-adaptive
behavior</a>", if you are running Postfix version 2.5 or later, or
if you have applied the source code patch for stress-adaptive
behavior from the mirrors listed at <a href="http://www.postfix.org/download.html">http://www.postfix.org/download.html</a>.
</p>
<p> The following measures can be applied temporarily during overload.
They still allow <b>most</b> legitimate clients to connect and send
mail, but may affect some legitimate clients. </p>
<ul> <ul>
@ -312,16 +330,9 @@ such as a mailing list that contains a few no-longer-active user
names that didn't bother to unsubscribe. No mail should be lost, names that didn't bother to unsubscribe. No mail should be lost,
as long as this measure is used only temporarily. </p> as long as this measure is used only temporarily. </p>
<li> <p> Disable remote SMTP client hostname lookups, so that all <li> <p> Use an <a href="postconf.5.html#smtpd_junk_command_limit">smtpd_junk_command_limit</a> of 1 instead of the default
SMTP client hostnames become "unknown" (line 5 below). This feature 100. This prevents clients from keeping idle connections open by
was introduced with Postfix 2.3. Unfortunately, this measure is repeatedly sending NOOP or RSET commands. </p>
more problematic than the other ones proposed sofar. First, this
will result in loss of mail when you use hostname-based access rules
that reject mail from "unknown" SMTP clients (examples:
<a href="postconf.5.html#reject_unknown_client_hostname">reject_unknown_client_hostname</a>, <a href="postconf.5.html#reject_unknown_reverse_client_hostname">reject_unknown_reverse_client_hostname</a>).
Second, this may result in loss of mail when you subject "unknown"
SMTP clients to additional restrictions such as <a href="postconf.5.html#reject_unverified_sender">reject_unverified_sender</a>.
</p>
</ul> </ul>
@ -330,40 +341,60 @@ SMTP clients to additional restrictions such as <a href="postconf.5.html#reject_
1 /etc/postfix/<a href="postconf.5.html">main.cf</a>: 1 /etc/postfix/<a href="postconf.5.html">main.cf</a>:
2 <a href="postconf.5.html#smtpd_timeout">smtpd_timeout</a> = 10 2 <a href="postconf.5.html#smtpd_timeout">smtpd_timeout</a> = 10
3 <a href="postconf.5.html#smtpd_hard_error_limit">smtpd_hard_error_limit</a> = 1 3 <a href="postconf.5.html#smtpd_hard_error_limit">smtpd_hard_error_limit</a> = 1
4 # Caution: line 5 may trigger REJECTs by hostname-based access rules 4 <a href="postconf.5.html#smtpd_junk_command_limit">smtpd_junk_command_limit</a> = 1
5 <a href="postconf.5.html#smtpd_peername_lookup">smtpd_peername_lookup</a> = no
</pre> </pre>
</blockquote> </blockquote>
<p> Except with the last measure, no mail should be lost, as long <p> With these measures, no mail should be lost, as long
as these measures are used only temporarily. The next section of as these measures are used only temporarily. The next section of
this document introduces a way to automate this process. </p> this document introduces a way to automate this process. </p>
<h2><a name="adapt"> Make Postfix behavior stress-adaptive </a></h2> <h2><a name="adapt"> Automatic stress-adaptive behavior </a></h2>
<p> Postfix version 2.5 introduces automatic stress-adaptive behavior. <p> Postfix version 2.5 introduces automatic stress-adaptive behavior.
This is also available as an add-on patch for Postfix versions 2.4 This is also available as a source code patch for Postfix versions
and 2.3 from the mirrors listed at <a href="http://www.postfix.org/download.html">http://www.postfix.org/download.html</a>. 2.4 and 2.3 from the mirrors listed at
</p> <a href="http://www.postfix.org/download.html">http://www.postfix.org/download.html</a>. </p>
<p> It works as follows. When a "public" network service runs into <p> It works as follows. When a "public" network service such as
an "all server ports are busy" condition, the <a href="master.8.html">master(8)</a> daemon logs the SMTP server runs into an "all server ports are busy" condition,
a warning, restarts the service (without interrupting existing the Postfix <a href="master.8.html">master(8)</a> daemon logs a warning, restarts the service
network sessions), and runs the service with "-o stress=yes" on the (without interrupting existing network sessions), and runs the
command line. Normally, it runs a stress-adaptive service with "-o service with "-o stress=yes" on the server process command line:
stress=" on the command line (i.e. with an empty parameter value).
Other services never have "-o stress" parameters on the command
line, including services that listen on a loopback interface only.
</p> </p>
<p> The stress pseudo-parameter value is the key to making <a href="postconf.5.html">main.cf</a>
parameter settings stress adaptive: </p>
<blockquote> <blockquote>
<pre> <pre>
1 /etc/postfix/<a href="postconf.5.html">main.cf</a>: 80821 ?? S 0:00.24 smtpd -n smtp -t inet -u -c -o stress=yes
2 <a href="postconf.5.html#smtpd_timeout">smtpd_timeout</a> = ${stress?10}${stress:300} </pre>
3 <a href="postconf.5.html#smtpd_hard_error_limit">smtpd_hard_error_limit</a> = ${stress?1}${stress:20} </blockquote>
<p> Normally, the Postfix <a href="master.8.html">master(8)</a> daemon runs such a service with
"-o stress=" on the command line (i.e. with an empty parameter
value): </p>
<blockquote>
<pre>
83326 ?? S 0:00.28 smtpd -n smtp -t inet -u -c -o stress=
</pre>
</blockquote>
<p> Services that have local access only never have "-o stress"
parameters on the command line. This includes services internal to
Postfix such as the queue manager, and services that listen on a
loopback interface only, such as after-filter SMTP services. </p>
<p> The "stress" parameter value is the key to making <a href="postconf.5.html">main.cf</a>
parameter settings stress adaptive. The following settings are the
default with Postfix 2.6 and later. With earlier Postfix versions
that have stress-adaptive support, append the lines below to the
<a href="postconf.5.html">main.cf</a> file and issue a "postfix reload" command: </p>
<blockquote>
<pre>
1 <a href="postconf.5.html#smtpd_timeout">smtpd_timeout</a> = ${stress?10}${stress:300}s
2 <a href="postconf.5.html#smtpd_hard_error_limit">smtpd_hard_error_limit</a> = ${stress?1}${stress:20}
3 <a href="postconf.5.html#smtpd_junk_command_limit">smtpd_junk_command_limit</a> = ${stress?1}${stress:100}
</pre> </pre>
</blockquote> </blockquote>
@ -371,11 +402,29 @@ parameter settings stress adaptive: </p>
<ul> <ul>
<li> <p> Line 2: under conditions of stress, use an <a href="postconf.5.html#smtpd_timeout">smtpd_timeout</a> <li> <p> Line 1: under conditions of stress, use an <a href="postconf.5.html#smtpd_timeout">smtpd_timeout</a>
value of 10 seconds instead of the default 300 seconds, value of 10 seconds instead of the default 300 seconds. Experience
on the postfix-users list from a variety of sysadmins shows that
reducing the "normal" <a href="postconf.5.html#smtpd_timeout">smtpd_timeout</a> to 60s is unlikely to affect
legitimate clients. However, it is unlikely to become the Postfix
default because it's not RFC compliant. Setting <a href="postconf.5.html#smtpd_timeout">smtpd_timeout</a> to
10s (line 2 below) or even 5s under stress will still allow most
legitimate clients to connect and send mail, but may delay mail
from some clients. No mail should be lost, as long as this measure
is used only temporarily. </p>
<li> <p> Line 3: under conditions of stress, use an <a href="postconf.5.html#smtpd_hard_error_limit">smtpd_hard_error_limit</a> <li> <p> Line 2: under conditions of stress, use an <a href="postconf.5.html#smtpd_hard_error_limit">smtpd_hard_error_limit</a>
of 1 instead of the default 20. </p> of 1 instead of the default 20. This helps by disconnecting clients
after a single error, giving other clients a chance to connect.
However, this may cause significant delays with legitimate mail,
such as a mailing list that contains a few no-longer-active user
names that didn't bother to unsubscribe. No mail should be lost,
as long as this measure is used only temporarily. </p>
<li> <p> Line 3: under conditions of stress, use an
<a href="postconf.5.html#smtpd_junk_command_limit">smtpd_junk_command_limit</a> of 1 instead of the default 100. This
prevents clients from keeping idle connections open by repeatedly
sending NOOP or RSET commands. </p>
</ul> </ul>
@ -463,6 +512,20 @@ services that accept remote connections. </p>
</pre> </pre>
</blockquote> </blockquote>
<h2><a name="other"> Other measures to off-load zombies </h2>
<p> OpenBSD <a href="http://www.openbsd.org/spamd/">spamd</a>
implements a daemon that handles all connections from "new" clients.
Only well-behaved mail clients are allowed to talk to the mail
server. Other clients are tarpitted, and will never get a chance
to affect mail server performance. </p>
<p> At some point in the future, Postfix may come with a simple
front-end daemon that does basic greylisting and pipelining detection
to keep zombies and other ratware away from Postfix itself. This
would use the "pass" service type which has been available in
stable Postfix releases since Postfix 2.5. </p>
<h2><a name="credits"> Credits </a></h2> <h2><a name="credits"> Credits </a></h2>
<ul> <ul>

View File

@ -46,6 +46,8 @@ configuration examples </a>
<li> <a href="IPV6_README.html"> IP Version 6 Support </a> <li> <a href="IPV6_README.html"> IP Version 6 Support </a>
<li> <a href="MULTI_INSTANCE_README.html"> Multiple-instance management </a>
<li> <a href="INSTALL.html"> Installation from source code </a> <li> <a href="INSTALL.html"> Installation from source code </a>
</ul> </ul>

View File

@ -179,7 +179,7 @@ POSTMULTI(1) POSTMULTI(1)
<b>New or existing instance name assignment</b> <b>New or existing instance name assignment</b>
<b>-I</b> <i>name</i> <b>-I</b> <i>name</i>
Assign the specified instance <i>name</i> to an existing Assign the specified instance <i>name</i> to an existing
instance or to a newly created or imported instance, newly-created instance, or imported
instance. Instance names other than "-" (which instance. Instance names other than "-" (which
makes the instance "nameless") must start with makes the instance "nameless") must start with
"postfix-". This restriction reduces the likeli- "postfix-". This restriction reduces the likeli-

View File

@ -599,7 +599,7 @@ ${WARN='-Wall -Wno-comment -Wformat -Wimplicit -Wmissing-prototypes \
export SYSTYPE AR ARFL RANLIB SYSLIBS CC OPT DEBUG AWK OPTS export SYSTYPE AR ARFL RANLIB SYSLIBS CC OPT DEBUG AWK OPTS
# Snapshot only. # Snapshot only.
CCARGS="$CCARGS -DSNAPSHOT" #CCARGS="$CCARGS -DSNAPSHOT"
# Non-production: needs thorough testing, or major changes are still # Non-production: needs thorough testing, or major changes are still
# needed before the code stabilizes. # needed before the code stabilizes.

View File

@ -176,7 +176,8 @@ primary Postfix instance.
.SH "New or existing instance name assignment" .SH "New or existing instance name assignment"
.IP "\fB-I \fIname\fR" .IP "\fB-I \fIname\fR"
Assign the specified instance \fIname\fR to an existing Assign the specified instance \fIname\fR to an existing
instance or to a newly created or imported instance. Instance instance, newly-created instance, or imported instance.
Instance
names other than "-" (which makes the instance "nameless") names other than "-" (which makes the instance "nameless")
must start with "postfix-". This restriction reduces the must start with "postfix-". This restriction reduces the
likelihood of name collisions with system files. likelihood of name collisions with system files.

View File

@ -126,10 +126,10 @@ stress=
an empty value ("name="), or sends a zero value ("name=0") in an empty value ("name="), or sends a zero value ("name=0") in
the case of a numerical attribute. </p> the case of a numerical attribute. </p>
<li> <p> The "recipient" attribute is available only in the <li> <p> The "recipient" attribute is available in the "RCPT
"RCPT TO" stage, and in the "DATA" and "END-OF-MESSAGE" stages TO" stage. It is also available in the "DATA" and "END-OF-MESSAGE"
when Postfix accepted only one recipient for the current message. stages if Postfix accepted only one recipient for the current
</p> message. </p>
<li> <p> The "recipient_count" attribute (Postfix 2.3 and later) <li> <p> The "recipient_count" attribute (Postfix 2.3 and later)
is non-zero only in the "DATA" and "END-OF-MESSAGE" stages. It is non-zero only in the "DATA" and "END-OF-MESSAGE" stages. It

View File

@ -21,13 +21,11 @@ Stress-Dependent Configuration</h1>
<h2>Overview </h2> <h2>Overview </h2>
<p> This document describes the symptoms of Postfix SMTP server <p> This document describes the symptoms of Postfix SMTP server
overload, and how to avoid the condition under normal conditions. overload. It presents permanent main.cf changes to avoid overload
When the condition is caused by botnets or other malware, the during normal operation, and temporary main.cf changes to cope with
document suggests configuration settings that help to minimize the an unexpected burst of mail. This document makes specific suggestions
impact on legitimate mail. Finally, the document introduces for Postfix 2.5 and later which support stress-adaptive behavior,
stress-adaptive behavior, introduced with Postfix 2.5, and how it and for earlier Postfix versions that don't. </p>
can be used to automatically switch configuration settings under
overload. </p>
<p> Topics covered in this document: </p> <p> Topics covered in this document: </p>
@ -41,47 +39,52 @@ overload. </p>
<li><a href="#hangup"> Disconnect suspicious SMTP clients </a> <li><a href="#hangup"> Disconnect suspicious SMTP clients </a>
<li><a href="#desperate"> Take desperate measures </a> <li><a href="#legacy"> Temporary measures for older Postfix releases </a>
<li><a href="#adapt"> Make Postfix behavior stress-adaptive </a> <li><a href="#adapt"> Automatic stress-adaptive behavior </a>
<li><a href="#feature"> Detecting support for stress-adaptive behavior </a> <li><a href="#feature"> Detecting support for stress-adaptive behavior </a>
<li><a href="#forcing"> Forcing stress-adaptive behavior on or off </a> <li><a href="#forcing"> Forcing stress-adaptive behavior on or off </a>
<li><a href="#other"> Other measures to off-load zombies </a>
<li><a href="#credits"> Credits </a> <li><a href="#credits"> Credits </a>
</ul> </ul>
<h2><a name="overload"> Symptoms of Postfix SMTP server overload </a></h2> <h2><a name="overload"> Symptoms of Postfix SMTP server overload </a></h2>
<p> Under normal conditions, Postfix responds immediately when a <p> Under normal conditions, the Postfix SMTP server responds
remote SMTP client connects. The time needed to deliver mail should immediately when an SMTP client connects to it; the time to deliver
be noticeable only with very large messages. Performance degrades mail is noticeable only with large messages. Performance degrades
more dramatically when the number of remote SMTP clients exceeds dramatically when the number of SMTP clients exceeds the number of
the number of Postfix SMTP server processes. When a client connects Postfix SMTP server processes. When an SMTP client connects while
while all server processes are busy, the client must wait until a all Postfix SMTP server processes are busy, the client must wait
server process becomes available. </p> until a server process becomes available. </p>
<p> Overload may be caused by a legitimate mail (example: a DNS <p> SMTP server overload may be caused by a surge of legitimate
registrar opens a new zone for registrations), by mistake (mail mail (example: a DNS registrar opens a new zone for registrations),
explosion caused by a forwarding loop) or by illegitimate mail (worm by mistake (mail explosion caused by a forwarding loop) or by malice
outbreak, botnet, or other malware activity). Symptoms of Postfix (worm outbreak, botnet, or other illegitimate activity). </p>
SMTP mail server overload are: </p>
<p> Symptoms of Postfix SMTP server overload are: </p>
<ul> <ul>
<li> <p> Remote SMTP clients experience a long delay before Postfix <li> <p> Remote SMTP clients experience a long delay before Postfix
sends the "220 hostname.example.com ESMTP Postfix" greeting. If sends the "220 hostname.example.com ESMTP Postfix" greeting. </p>
this affects end-user mail clients, enable the "submission" service
entry in master.cf (present since Postfix 2.1), and tell users to
connect to this instead of the public SMTP service. </p>
<ul> <ul>
<li> <p> NOTE: Broken DNS configurations also cause lengthy delays <li> <p> NOTE: Broken DNS configurations can also cause lengthy
before Postfix sends "220 hostname.example.com ...". In this case delays before Postfix sends "220 hostname.example.com ...". These
the delay happens even when Postfix is not busy. </p> delays also exist when Postfix is NOT overloaded. </p>
<li> <p> NOTE: To avoid "overload" delays for end-user mail
clients, enable the "submission" service entry in master.cf (present
since Postfix 2.1), and tell users to connect to this instead of
the public SMTP service. </p>
</ul> </ul>
@ -91,8 +94,8 @@ clients disconnect before Postfix answers the connection. </p>
<ul> <ul>
<li> <p> NOTE: A portscan for open SMTP ports also results in "lost <li> <p> NOTE: A portscan for open SMTP ports can also result in
connection ..." logfile messages. </p> "lost connection ..." logfile messages. </p>
</ul> </ul>
@ -111,14 +114,16 @@ Oct 3 20:39:27 spike postfix/master[28905]: warning: to avoid this
</ul> </ul>
<p> Legitimate mail that doesn't get through during an episode of <p> Legitimate mail that doesn't get through during an episode of
overload is not necessarily lost. It should still arrive once the Postfix SMTP server overload is not necessarily lost. It should
situation returns to normal, as long as the overload condition is still arrive once the situation returns to normal, as long as the
temporary. </p> overload condition is temporary. </p>
<h2><a name="concurrency"> Service more SMTP clients at the same time </a> </h2> <h2><a name="concurrency"> Service more SMTP clients at the same time </a> </h2>
<p> To service more SMTP clients simultaneously, you need to increase <p> One measure to avoid the "all server processes busy" condition
the number of SMTP server processes. This will improve the is to service more SMTP clients simultaneously. For this you need
to increase the number of Postfix SMTP server processes. This will
improve the
responsiveness for remote SMTP clients, as long as the server machine responsiveness for remote SMTP clients, as long as the server machine
has enough hardware and software resources to run the additional has enough hardware and software resources to run the additional
processes, and as long as the file system can keep up with the processes, and as long as the file system can keep up with the
@ -137,7 +142,8 @@ later, and an operating system that supports kernel-based event
filters (BSD kqueue(2), Linux epoll(4), or Solaris /dev/poll). filters (BSD kqueue(2), Linux epoll(4), or Solaris /dev/poll).
</p> </p>
<li> <p> You can reduce the Postfix memory footprint by using cdb: <li> <p> More processes use more memory. You can reduce the Postfix
memory footprint by using cdb:
lookup tables instead of Berkeley DB's hash: or btree: tables. </p> lookup tables instead of Berkeley DB's hash: or btree: tables. </p>
<pre> <pre>
@ -181,9 +187,9 @@ Issue a "postfix reload" command to make the change effective. </p>
<p> When increasing the number of SMTP server processes is not <p> When increasing the number of SMTP server processes is not
practical, you can improve Postfix server responsiveness by eliminating practical, you can improve Postfix server responsiveness by eliminating
unnecessary work. When Postfix spends less time per SMTP session, the delays. When Postfix spends less time per SMTP session, the same
same number of SMTP server processes can service more clients in the number of SMTP server processes can service more clients in a given
same amount of time. </p> amount of time. </p>
<ul> <ul>
@ -201,18 +207,18 @@ emergency patterns to block the latest worm explosion or backscatter
mail. See BACKSCATTER_README for examples of the latter. mail. See BACKSCATTER_README for examples of the latter.
<li> <p> Group your header_checks and body_checks patterns to avoid <li> <p> Group your header_checks and body_checks patterns to avoid
unnecessary pattern matching operations. unnecessary pattern matching operations:
<pre> <pre>
1 /etc/postfix/header_checks: 1 /etc/postfix/header_checks:
2 if /^Subject:/ 2 if /^Subject:/
3 /^Subject: virus found in mail from you/ reject 3 /^Subject: virus found in mail from you/ reject
4 /^Subject: ..../ .... 4 /^Subject: ..other../ reject
5 endif 5 endif
6 6
7 if /^Received:/ 7 if /^Received:/
8 /^Received: from (postfix\.org) / reject forged client name in received header: $1 8 /^Received: from (postfix\.org) / reject forged client name in received header: $1
9 /^Received: from .../ .... 9 /^Received: from ..other../ reject ....
10 endif 10 endif
</pre> </pre>
@ -226,20 +232,22 @@ clients get a chance to talk to Postfix. </p>
<ul> <ul>
<li> <p> Use "521" reply codes (Postfix 2.6 and later) for <li> <p> Use "521" SMTP reply codes (Postfix 2.6 and later) or "421"
botnet-related RBLs or for selected non-RBL restrictions. With (Postfix 2.3-2.5) to hang up on clients that that match botnet-related
Postfix 2.3-2.5 use "421" for a similar result. The Postfix SMTP RBLs (see next bullet) or that match selected non-RBL restrictions
server will disconnect immediately without waiting for the remote such as SMTP access maps. The Postfix SMTP server will reject mail
SMTP client to send a QUIT command. </p> and disconnect without waiting for the remote SMTP client to send
a QUIT command. </p>
<p> You can set individual reject codes for RBLs, and for individual <li> <p> To hang up connections from blacklisted zombies, you can
responses from a specific RBL. We'll use zen.spamhaus.org as an set specific Postfix SMTP server reject codes for specific RBLs,
example; by the time you read this document, details may have and for individual responses from specific RBLs. We'll use
changed. Right now, their documents say that a response of 127.0.0.10 zen.spamhaus.org as an example; by the time you read this document,
or 127.0.0.11 indicates a dynamic client IP address, which means details may have changed. Right now, their documents say that a
that the machine is probably running a bot of some kind. To give response of 127.0.0.10 or 127.0.0.11 indicates a dynamic client IP
a 521 response instead of the default 554 response, use something address, which means that the machine is probably running a bot of
like: </p> some kind. To give a 521 response instead of the default 554
response, use something like: </p>
<pre> <pre>
1 /etc/postfix/main.cf: 1 /etc/postfix/main.cf:
@ -252,45 +260,55 @@ like: </p>
8 rbl_reply_maps = hash:/etc/postfix/rbl_reply_maps 8 rbl_reply_maps = hash:/etc/postfix/rbl_reply_maps
9 9
10 /etc/postfix/rbl_reply_maps: 10 /etc/postfix/rbl_reply_maps:
11 zen.spamhaus.org=127.0.0.10 521 4.7.1 Service unavailable; 11 # With Postfix 2.3-2.5 use "421" to hang up connections.
12 $rbl_class [$rbl_what] blocked using 12 zen.spamhaus.org=127.0.0.10 521 4.7.1 Service unavailable;
13 $rbl_domain${rbl_reason?; $rbl_reason} 13 $rbl_class [$rbl_what] blocked using
14 14 $rbl_domain${rbl_reason?; $rbl_reason}
15 zen.spamhaus.org=127.0.0.11 521 4.7.1 Service unavailable; 15
16 $rbl_class [$rbl_what] blocked using 16 zen.spamhaus.org=127.0.0.11 521 4.7.1 Service unavailable;
17 $rbl_domain${rbl_reason?; $rbl_reason} 17 $rbl_class [$rbl_what] blocked using
18 $rbl_domain${rbl_reason?; $rbl_reason}
</pre> </pre>
<p> Although the above shows three RBL lookups (lines 4-6), Postfix <p> Although the above example shows three RBL lookups (lines 4-6),
will still only do a single DNS query, so the performance difference Postfix will only do a single DNS query, so it does not affect the
is negligible. </p> performance. </p>
<p> With Postfix 2.3-2.5, use 421 (reply code 521 will not cause <li> <p> With Postfix 2.3-2.5, use reply code 421 (521 will not
Postfix to disconnect). The down-side of sending 421 is that cause Postfix to disconnect). The down-side of replying with 421
it works only for zombies and other malware. If the client is running is that it works only for zombies and other malware. If the client
a real MTA, then it may connect again several times until the mail is running a real MTA, then it may connect again several times until
expires in its queue. When this is a problem, stick with the default the mail expires in its queue. When this is a problem, stick with
554 reply, and use "smtpd_hard_error_limit = 1" as described below. the default 554 reply, and use "smtpd_hard_error_limit = 1" as
</p> described below. </p>
<p> With Postfix 2.5, or with earlier releases that contain the <li> <p> You can automatically turn on the above overload measure
stress-adaptive behavior patch, you can turn on the above under with Postfix 2.5 and later, or with earlier releases that contain
overload by replacing line 8 with: </p> the stress-adaptive behavior source code patch from the mirrors
listed at http://www.postfix.org/download.html. Simply replace line
above 8 with: </p>
<pre> <pre>
8 rbl_reply_maps = ${stress?hash:/etc/postfix/rbl_reply_maps} 8 rbl_reply_maps = ${stress?hash:/etc/postfix/rbl_reply_maps}
</pre> </pre>
<p> More information about automatic stress-adaptive behavior is
at the end of this document. </p>
</ul> </ul>
<h2><a name="desperate"> Take desperate measures </a></h2> <p> More information about automatic stress-adaptive behavior is
in section "<a href="#adapt">Automatic stress-adaptive behavior</a>".
</p>
<p> The following measures will still allow <b>most</b> legitimate <h2><a name="legacy"> Temporary measures for older Postfix releases </a></h2>
clients to connect and send mail, but may affect some legitimate
clients. </p> <p> See the next section, "<a href="#adapt">Automatic stress-adaptive
behavior</a>", if you are running Postfix version 2.5 or later, or
if you have applied the source code patch for stress-adaptive
behavior from the mirrors listed at http://www.postfix.org/download.html.
</p>
<p> The following measures can be applied temporarily during overload.
They still allow <b>most</b> legitimate clients to connect and send
mail, but may affect some legitimate clients. </p>
<ul> <ul>
@ -312,16 +330,9 @@ such as a mailing list that contains a few no-longer-active user
names that didn't bother to unsubscribe. No mail should be lost, names that didn't bother to unsubscribe. No mail should be lost,
as long as this measure is used only temporarily. </p> as long as this measure is used only temporarily. </p>
<li> <p> Disable remote SMTP client hostname lookups, so that all <li> <p> Use an smtpd_junk_command_limit of 1 instead of the default
SMTP client hostnames become "unknown" (line 5 below). This feature 100. This prevents clients from keeping idle connections open by
was introduced with Postfix 2.3. Unfortunately, this measure is repeatedly sending NOOP or RSET commands. </p>
more problematic than the other ones proposed sofar. First, this
will result in loss of mail when you use hostname-based access rules
that reject mail from "unknown" SMTP clients (examples:
reject_unknown_client_hostname, reject_unknown_reverse_client_hostname).
Second, this may result in loss of mail when you subject "unknown"
SMTP clients to additional restrictions such as reject_unverified_sender.
</p>
</ul> </ul>
@ -330,40 +341,60 @@ SMTP clients to additional restrictions such as reject_unverified_sender.
1 /etc/postfix/main.cf: 1 /etc/postfix/main.cf:
2 smtpd_timeout = 10 2 smtpd_timeout = 10
3 smtpd_hard_error_limit = 1 3 smtpd_hard_error_limit = 1
4 # Caution: line 5 may trigger REJECTs by hostname-based access rules 4 smtpd_junk_command_limit = 1
5 smtpd_peername_lookup = no
</pre> </pre>
</blockquote> </blockquote>
<p> Except with the last measure, no mail should be lost, as long <p> With these measures, no mail should be lost, as long
as these measures are used only temporarily. The next section of as these measures are used only temporarily. The next section of
this document introduces a way to automate this process. </p> this document introduces a way to automate this process. </p>
<h2><a name="adapt"> Make Postfix behavior stress-adaptive </a></h2> <h2><a name="adapt"> Automatic stress-adaptive behavior </a></h2>
<p> Postfix version 2.5 introduces automatic stress-adaptive behavior. <p> Postfix version 2.5 introduces automatic stress-adaptive behavior.
This is also available as an add-on patch for Postfix versions 2.4 This is also available as a source code patch for Postfix versions
and 2.3 from the mirrors listed at http://www.postfix.org/download.html. 2.4 and 2.3 from the mirrors listed at
</p> http://www.postfix.org/download.html. </p>
<p> It works as follows. When a "public" network service runs into <p> It works as follows. When a "public" network service such as
an "all server ports are busy" condition, the master(8) daemon logs the SMTP server runs into an "all server ports are busy" condition,
a warning, restarts the service (without interrupting existing the Postfix master(8) daemon logs a warning, restarts the service
network sessions), and runs the service with "-o stress=yes" on the (without interrupting existing network sessions), and runs the
command line. Normally, it runs a stress-adaptive service with "-o service with "-o stress=yes" on the server process command line:
stress=" on the command line (i.e. with an empty parameter value).
Other services never have "-o stress" parameters on the command
line, including services that listen on a loopback interface only.
</p> </p>
<p> The stress pseudo-parameter value is the key to making main.cf
parameter settings stress adaptive: </p>
<blockquote> <blockquote>
<pre> <pre>
1 /etc/postfix/main.cf: 80821 ?? S 0:00.24 smtpd -n smtp -t inet -u -c -o stress=yes
2 smtpd_timeout = ${stress?10}${stress:300} </pre>
3 smtpd_hard_error_limit = ${stress?1}${stress:20} </blockquote>
<p> Normally, the Postfix master(8) daemon runs such a service with
"-o stress=" on the command line (i.e. with an empty parameter
value): </p>
<blockquote>
<pre>
83326 ?? S 0:00.28 smtpd -n smtp -t inet -u -c -o stress=
</pre>
</blockquote>
<p> Services that have local access only never have "-o stress"
parameters on the command line. This includes services internal to
Postfix such as the queue manager, and services that listen on a
loopback interface only, such as after-filter SMTP services. </p>
<p> The "stress" parameter value is the key to making main.cf
parameter settings stress adaptive. The following settings are the
default with Postfix 2.6 and later. With earlier Postfix versions
that have stress-adaptive support, append the lines below to the
main.cf file and issue a "postfix reload" command: </p>
<blockquote>
<pre>
1 smtpd_timeout = ${stress?10}${stress:300}s
2 smtpd_hard_error_limit = ${stress?1}${stress:20}
3 smtpd_junk_command_limit = ${stress?1}${stress:100}
</pre> </pre>
</blockquote> </blockquote>
@ -371,11 +402,29 @@ parameter settings stress adaptive: </p>
<ul> <ul>
<li> <p> Line 2: under conditions of stress, use an smtpd_timeout <li> <p> Line 1: under conditions of stress, use an smtpd_timeout
value of 10 seconds instead of the default 300 seconds, value of 10 seconds instead of the default 300 seconds. Experience
on the postfix-users list from a variety of sysadmins shows that
reducing the "normal" smtpd_timeout to 60s is unlikely to affect
legitimate clients. However, it is unlikely to become the Postfix
default because it's not RFC compliant. Setting smtpd_timeout to
10s (line 2 below) or even 5s under stress will still allow most
legitimate clients to connect and send mail, but may delay mail
from some clients. No mail should be lost, as long as this measure
is used only temporarily. </p>
<li> <p> Line 3: under conditions of stress, use an smtpd_hard_error_limit <li> <p> Line 2: under conditions of stress, use an smtpd_hard_error_limit
of 1 instead of the default 20. </p> of 1 instead of the default 20. This helps by disconnecting clients
after a single error, giving other clients a chance to connect.
However, this may cause significant delays with legitimate mail,
such as a mailing list that contains a few no-longer-active user
names that didn't bother to unsubscribe. No mail should be lost,
as long as this measure is used only temporarily. </p>
<li> <p> Line 3: under conditions of stress, use an
smtpd_junk_command_limit of 1 instead of the default 100. This
prevents clients from keeping idle connections open by repeatedly
sending NOOP or RSET commands. </p>
</ul> </ul>
@ -463,6 +512,20 @@ services that accept remote connections. </p>
</pre> </pre>
</blockquote> </blockquote>
<h2><a name="other"> Other measures to off-load zombies </h2>
<p> OpenBSD <a href="http://www.openbsd.org/spamd/">spamd</a>
implements a daemon that handles all connections from "new" clients.
Only well-behaved mail clients are allowed to talk to the mail
server. Other clients are tarpitted, and will never get a chance
to affect mail server performance. </p>
<p> At some point in the future, Postfix may come with a simple
front-end daemon that does basic greylisting and pipelining detection
to keep zombies and other ratware away from Postfix itself. This
would use the "pass" service type which has been available in
stable Postfix releases since Postfix 2.5. </p>
<h2><a name="credits"> Credits </a></h2> <h2><a name="credits"> Credits </a></h2>
<ul> <ul>

View File

@ -624,6 +624,10 @@ static void cleanup_header_done_callback(void *context)
* ID uniqueness only within a second, we must ensure that the time in * ID uniqueness only within a second, we must ensure that the time in
* the message ID matches the queue ID creation time, as long as we use * the message ID matches the queue ID creation time, as long as we use
* the queue ID in the message ID. * the queue ID in the message ID.
*
* XXX We log a dummy name=value record so that we (hopefully) don't break
* compatibility with existing logfile analyzers, and so that we don't
* complicate future code that wants to log more name=value attributes.
*/ */
if ((state->hdr_rewrite_context || var_always_add_hdrs) if ((state->hdr_rewrite_context || var_always_add_hdrs)
&& (state->headers_seen & (1 << (state->resent[0] ? && (state->headers_seen & (1 << (state->resent[0] ?
@ -636,7 +640,11 @@ static void cleanup_header_done_callback(void *context)
msg_info("%s: %smessage-id=<%s.%s@%s>", msg_info("%s: %smessage-id=<%s.%s@%s>",
state->queue_id, *state->resent ? "resent-" : "", state->queue_id, *state->resent ? "resent-" : "",
time_stamp, state->queue_id, var_myhostname); time_stamp, state->queue_id, var_myhostname);
state->headers_seen |= (1 << (state->resent[0] ?
HDR_RESENT_MESSAGE_ID : HDR_MESSAGE_ID));
} }
if ((state->headers_seen & (1 << HDR_MESSAGE_ID)) == 0)
msg_info("%s: message-id=<>", state->queue_id);
/* /*
* Add a missing (Resent-)Date: header. The date is in local time units, * Add a missing (Resent-)Date: header. The date is in local time units,

View File

@ -207,6 +207,7 @@ static int deliver_request_get(VSTREAM *stream, DELIVER_REQUEST *request)
static RCPT_BUF *rcpt_buf; static RCPT_BUF *rcpt_buf;
int rcpt_count; int rcpt_count;
int dsn_ret; int dsn_ret;
int lock_tries;
/* /*
* Initialize. For some reason I wanted to allow for multiple instances * Initialize. For some reason I wanted to allow for multiple instances
@ -335,8 +336,21 @@ static int deliver_request_get(VSTREAM *stream, DELIVER_REQUEST *request)
} }
if (msg_verbose) if (msg_verbose)
msg_info("%s: file %s", myname, VSTREAM_PATH(request->fp)); msg_info("%s: file %s", myname, VSTREAM_PATH(request->fp));
if (myflock(vstream_fileno(request->fp), INTERNAL_LOCK, DELIVER_LOCK_MODE) < 0)
/*
* XXX Originally, the queue manager would read new recipients AFTER all
* the in-memory recipients were processed. either the queue manager held
* an exclusive lock or delivery agents held a shared lock. Now we try a
* few times.
*/
for (lock_tries = 0; /* see below */; lock_tries++) {
if (myflock(vstream_fileno(request->fp), INTERNAL_LOCK, DELIVER_LOCK_MODE) == 0)
break;
if (lock_tries < 5)
sleep(1);
else
msg_fatal("shared lock %s: %m", VSTREAM_PATH(request->fp)); msg_fatal("shared lock %s: %m", VSTREAM_PATH(request->fp));
}
close_on_exec(vstream_fileno(request->fp), CLOSE_ON_EXEC); close_on_exec(vstream_fileno(request->fp), CLOSE_ON_EXEC);
return (0); return (0);

View File

@ -20,8 +20,8 @@
* Patches change both the patchlevel and the release date. Snapshots have no * Patches change both the patchlevel and the release date. Snapshots have no
* patchlevel; they change the release date only. * patchlevel; they change the release date only.
*/ */
#define MAIL_RELEASE_DATE "20090404" #define MAIL_RELEASE_DATE "20090415"
#define MAIL_VERSION_NUMBER "2.6" #define MAIL_VERSION_NUMBER "2.6.0-RC1"
#ifdef SNAPSHOT #ifdef SNAPSHOT
# define MAIL_VERSION_DATE "-" MAIL_RELEASE_DATE # define MAIL_VERSION_DATE "-" MAIL_RELEASE_DATE

View File

@ -164,7 +164,8 @@
/* .SH "New or existing instance name assignment" /* .SH "New or existing instance name assignment"
/* .IP "\fB-I \fIname\fR" /* .IP "\fB-I \fIname\fR"
/* Assign the specified instance \fIname\fR to an existing /* Assign the specified instance \fIname\fR to an existing
/* instance or to a newly created or imported instance. Instance /* instance, newly-created instance, or imported instance.
/* Instance
/* names other than "-" (which makes the instance "nameless") /* names other than "-" (which makes the instance "nameless")
/* must start with "postfix-". This restriction reduces the /* must start with "postfix-". This restriction reduces the
/* likelihood of name collisions with system files. /* likelihood of name collisions with system files.

View File

@ -107,5 +107,6 @@
VAR_SMTP_SENDER_AUTH, DEF_SMTP_SENDER_AUTH, &var_smtp_sender_auth, VAR_SMTP_SENDER_AUTH, DEF_SMTP_SENDER_AUTH, &var_smtp_sender_auth,
VAR_SMTP_CNAME_OVERR, DEF_SMTP_CNAME_OVERR, &var_smtp_cname_overr, VAR_SMTP_CNAME_OVERR, DEF_SMTP_CNAME_OVERR, &var_smtp_cname_overr,
VAR_SMTP_SASL_AUTH_SOFT_BOUNCE, DEF_SMTP_SASL_AUTH_SOFT_BOUNCE, &var_smtp_sasl_auth_soft_bounce, VAR_SMTP_SASL_AUTH_SOFT_BOUNCE, DEF_SMTP_SASL_AUTH_SOFT_BOUNCE, &var_smtp_sasl_auth_soft_bounce,
VAR_LMTP_ASSUME_FINAL, DEF_LMTP_ASSUME_FINAL, &var_lmtp_assume_final,
0, 0,
}; };