Sendmail can be configured to deliver messages to a file or program, as well as a mailbox.


To append messages to a file:


In the alias file or the user's ~/.forward file, add the username followed by a path to the name of the file that you want the message appended to:


user:        /path/to/file


To send the message to a program, in either the user's ~/.forward file or in the alias database, use:


user:        |/path/to/program


It helps to set the number of file descriptors to the maximum number allowed by the Operating System. The last thing you want to have happen is to have Sendmail run out of open file handles. Consult docs.sun.com for help on setting /etc/system for maximum file descriptors.


You may also want to tune your TCP/IP send and receive buffers. Adjusting these numbers may help with network latency issues. Consult Sun Blueprints for help on ndd settings.


Sendmail has several parameters to control resource usage. You can use the following:


conncontrol
ConnectionRateThrottle
greet_pause
MaxDaemonChildren
MaxQueueChildren
MaxRunnersPerQueue
ratecontrol


FEATURE(`conncontrol') - Enable a simple check of the number of incoming SMTP connections. This requires entries in access_db of the form:


ClientConn:IP.ADD.RE.SS        LIMIT


The RHS specifies the maximum number of open connections (an integer number).


Take the following example:


ClientConn:10.1.2.3           4
ClientConn:127.0.0.1          0
ClientConn:                  10


10.1.2.3 can only have up to 4 open connections, the general limit is 10, and 127.0.0.1 does not have any explicit limit.


The ConnectionRateThrottle and MaxDaemonChildren can be used to limit the number of incoming connections. Their appropriate values depend on the host operating system and the hardware, e.g., amount of memory. In many situations it might be useful to set limits to prevent having too many Sendmail processes, however, these limits can be abused to mount a denial of service attack. For example, if MaxDaemonChildren is set to 10, then an attacker needs to open only 10 SMTP sessions to the server, leave them idle for most of the time, and no more connections will be accepted.


greet_pause - Adds the greet_pause ruleset which enables open proxy and SMTP slamming protection. The feature can take an argument specifying the milliseconds to wait:


FEATURE(`greet_pause', `5000') dnl 5 seconds


If FEATURE(`access_db') is enabled, an access database lookup with the GreetPause tag is done using client hostname, domain, IP address, or subnet to determine the pause time:


GreetPause:my.domain                  0
GreetPause:example.com             5000
GreetPause:10.1.2                  2000
GreetPause:127.0.0.1                  0


When using FEATURE(`access_db'), the optional FEATURE(`greet_pause') argument becomes the default if nothing is found in the access database. A ruleset called Local_greet_pause can be used for local modifications, e.g.,


LOCAL_RULESETS
SLocal_greet_pause
R$*             $: $&{daemon_flags}
R$* a $*        $# 0


The MaxQueueChildren and MaxRunnersPerQueue limit the number of Sendmail processes that operate on the queue.


FEATURE(`ratecontrol') - Enable simple ruleset to do connection rate control checking. This requires entries in access_db of the form:


ClientRate:IP.ADD.RE.SS        LIMIT


The RHS specifies the maximum number of connections (an integer number) over the time interval defined by ConnectionRateWindowSize, where 0 means unlimited.


Take the following example:


ClientRate:10.1.2.3        4
ClientRate:127.0.0.1       0
ClientRate:               10


10.1.2.3 can only make up to 4 connections, the general limit is 10, and 127.0.0.1 can make an unlimited number of connections per ConnectionRateWindowSize.


Sendmail has some built-in measures against simple denial of service (DoS) attacks. The SMTP server by default slows down if too many bad commands are issued or if some commands are repeated too often within a session. Details can be found in the source file sendmail/srvrsmtp.c by looking for the macro definitions of MAXBADCOMMANDS, MAXNOOPCOMMANDS, MAXHELOCOMMANDS, MAXVRFYCOMMANDS, and MAXETRNCOMMANDS. If an SMTP command is issued more often than the corresponding MAXcmdCOMMANDS value, then the response is delayed exponentially, starting with a sleep time of one second, up to a maximum of four minutes (as defined by MAXTIMEOUT). If the option MaxDaemonChildren is set to a value greater than zero, then this could make a DoS attack even worse since it keeps a connection open longer than necessary. Therefore a connection is terminated with a 421 SMTP reply code if the number of commands exceeds the limit by a factor of two and MAXBADCOMMANDS is set to a value greater than zero (the default is 25).


Next Section: Queue Tips - 19 of 32



This Web Site Copyright © 1997 - 2008
by Alan Pae - All Rights Reserved