~ubuntu-branches/ubuntu/maverick/postfix/maverick-security

overload, and how to avoid the condition under normal conditions.

When the condition is caused by botnets or other malware, the

document suggests configuration settings that help to minimize the

impact on legitimate mail.  Finally, the document introduces

stress-adaptive behavior, introduced with Postfix 2.5, and how it

can be used to automatically switch configuration settings under

overload.  </p>

<li><a href="#desperate"> Take desperate measures </a>

<li><a href="#adapt"> Make Postfix behavior stress-adaptive </a>

<p> Under normal conditions, Postfix responds immediately when a

remote SMTP client connects. The time needed to deliver mail should

be noticeable only with very large messages.  Performance degrades

more dramatically when the number of remote SMTP clients exceeds

the number of Postfix SMTP server processes.  When a client connects

while all server processes are busy, the client must wait until a

server process becomes available. </p>

 

<p> Overload may be caused by a legitimate mail (example: a DNS

registrar opens a new zone for registrations), by mistake (mail

explosion caused by a forwarding loop) or by illegitimate mail (worm

outbreak, botnet, or other malware activity).  Symptoms of Postfix

SMTP mail server overload are: </p>

sends the "220 hostname.example.com ESMTP Postfix" greeting.  If

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>

<p> NOTE: The first two symptoms may also happen without overload,

for example: </p>

 

<ul>

 

<li> <p> Broken DNS also causes lengthy delays before "220

hostname.example.com

..." while the Postfix SMTP server tries to look up the client's

hostname.  </p>

 

<li> <p> A portscan for open SMTP ports also results in "lost

connection ..." logfile messages. </p>

 

</ul>

 

overload is not necessarily lost. It should still arrive once the

situation returns to normal, as long as the overload condition is

temporary.  </p>

<p> To service more SMTP clients simultaneously, you need to increase

the number of SMTP server processes. This will improve the

<li> <p> You can reduce the Postfix memory footprint by using <a href="CDB_README.html">cdb</a>:

lookup tables instead of Berkeley DB. </p>

out".  To fix, edit <a href="master.5.html">master.cf</a> and specify a zero "maxproc" field

unnecessary work. When Postfix spends less time per SMTP session, the

same number of SMTP server processes can service more clients in

the same amount of time. </p>

unnecessary pattern matching operations.

 4      /^Subject: ..../ ....

 9      /^Received: from .../ ....

<li> <p> Use "421" reply codes for botnet-related RBLs or for

selected non-RBL restrictions. This causes Postfix 2.3 and later

to disconnect immediately 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

responses from a specific RBL. 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 dynamic client IP address, which means

that the machine is probably running a bot of some kind.  To give

a 421 response instead of the default 554 response, use something

like: </p>

11      zen.spamhaus.org=127.0.0.10 421 4.7.1 Service unavailable;

12       $rbl_class [$rbl_what] blocked using

13       $rbl_domain${rbl_reason?; $rbl_reason}

14  

15      zen.spamhaus.org=127.0.0.11 421 4.7.1 Service unavailable;

16       $rbl_class [$rbl_what] blocked using

17       $rbl_domain${rbl_reason?; $rbl_reason}

<p> Although the above shows three RBL lookups (lines 4-6), Postfix

will still only do a single DNS query, so the performance difference

is negligible. </p>

 

<p> The down-side of sending 421 instead of the default 554 is that

it works only for zombies and other malware. If the client is running

a real MTA, then it may connect again several times until the mail

expires in its queue. When this is a problem, stick with the default

554 reply, and use "<a href="postconf.5.html#smtpd_hard_error_limit">smtpd_hard_error_limit</a> = 1" as described below.

</p>

 

<p> With Postfix 2.5, or with earlier releases that contain the

stress-adaptive behavior patch, you can turn on the above under

overload by replacing line 8 with: </p>

at the end of this document. </p>

 

</ul>

 

<h2><a name="desperate"> Take desperate measures </a></h2>

 

<p> The following measures will still allow <b>most</b> legitimate

clients to connect and send mail, but may affect some legitimate

clients. </p>

<li> <p> Disable remote SMTP client hostname lookups, so that all

SMTP client hostnames become "unknown" (line 5 below). This feature

was introduced with Postfix 2.3. Unfortunately, this measure is

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>

4      # Caution: line 5 may trigger REJECTs by hostname-based access rules 

5      <a href="postconf.5.html#smtpd_peername_lookup">smtpd_peername_lookup</a> = no

<p> Except with the last measure, no mail should be lost, as long

<h2><a name="adapt"> Make Postfix behavior stress-adaptive </a></h2>

This is also available as an add-on patch for Postfix versions 2.4

and 2.3 from the mirrors listed at <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

an "all server ports are busy" condition, the <a href="master.8.html">master(8)</a> daemon logs

a warning, restarts the service (without interrupting existing

network sessions), and runs the service with "-o stress=yes" on the

command line. Normally, it runs a stress-adaptive service with "-o

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> The stress pseudo-parameter value is the key to making <a href="postconf.5.html">main.cf</a>

parameter settings stress adaptive: </p>

 

<blockquote>

<pre>

1  /etc/postfix/<a href="postconf.5.html">main.cf</a>:

2      <a href="postconf.5.html#smtpd_timeout">smtpd_timeout</a> = ${stress?10}${stress:300}

3      <a href="postconf.5.html#smtpd_hard_error_limit">smtpd_hard_error_limit</a> = ${stress?1}${stress:20}

<li> <p> Line 2: 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,

 

<li> <p> Line 3: 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>