Throttle email

From MsgServerDocWiki

How can I throttle (rate-limit) email delivery?

Messaging server provides a number of mechanisms to throttle (rate-limit) email delivery. These mechanisms can help prevent Denial-of-Service attacks (whether intentional or by accident).

• The conn_throttle.so plug-in (5.2 -> 6.2 - for 6.3 use MeterMaid). This plugin allows you to reject connections based on IP address and the number of connections.
• MeterMaid (6.3 and above). This is a more advanced version of the conn_throttle.so library and allows you to reject connections across server processes. This article discusses the throttling of emails sent from UWC/Communication Express on a per-user basis by utilising Metermaid.
• RECIPIENT_DELAY_AMOUNTS, RECIPIENT_DELAY_THRESHHOLDS TCP/IP channel (SMTP server) options (5.2 and above). Further details on the options are below (they are currently not formally documented).

SIZE_DELAY_THRESHHOLDS
SIZE_DELAY_AMOUNTS
RECIPIENT_DELAY_THRESHHOLDS
RECIPIENT_DELAY_AMOUNTS
TRANSACTION_DELAY_THRESHHOLDS
TRANSACTION_DELAY_AMOUNTS 
(comma-separated list of integers)

These are SMTP server options; (they are also supported by the LMTP servers, though unlikely to be useful in an LMTP
context). The number of total message size, number of recipients, and number of transactions are tracked by the SMTP
server on a per-session basis. And via these options, the SMTP server can impose punitive delays in responding when
various threshhold levels are exceeded. That is, the SMTP server can in gradated fashion "slow down" its responses to
clients that are submitting "large" numbers of "large" messages to "large" numbers of recipients. These options come in
pairs, each containing a list of up to ten, comma-separated integers. (The default is all zeros.) One list is the  
threshhold list, which specifies the point past which the additional delay specified b the corresponding number in the
other list applies. The delay amounts are additive; that is, each delay value specifies an additional delay to impose,
rather than representing an absolute delay. The current delay in effect is maximized with the result of summing the 
three contributors:

D_c=max(D_c,D_t+D_r+D_s)

Here D_c is the current delay, D_t is the delay due to transactions being exceeded, D_r is the delay due to recipients
being exceeded, and D_s is the delay due to size being exceeded.

Note that the SIZE_DELAY_THRESHHOLDS are in bytes, not blocks. The *_DELAY_AMOUNTS values are interpreted as hundredths
of seconds.

Note that as always with such SMTP server options, they have to be set in the <channel-name>_option file corresponding to
the _default_ incoming channel for the relevant Dispatcher service. So typically tcp_local_option (_not_
tcp_intranet_option where they would have no effect).

Example configuration follows:

<msg_base>/config/tcp_local_option:
TRANSACTION_DELAY_THRESHHOLDS=5,10,50
TRANSACTION_DELAY_AMOUNTS=50,100,200
SIZE_DELAY_THRESHHOLDS=100000,250000,1000000
SIZE_DELAY_AMOUNTS=50,100,200
RECIPIENT_DELAY_THRESHHOLDS=50,100,1000
RECIPIENT_DELAY_AMOUNTS=25,50,75

Although only three pairs of values are specified for the above example, you can configure up to 10 pairs of values for  
increased graduation in throttling.

These restrictions are on a per-SMTP session basis, and the delay is calculated at the beginning of each subsequent
transaction. Therefore if an email client sent a 110KB file to 60 recipients in the first transaction, the second
transaction would get a 0.50+0.25 second delay applied to each "rcpt to:" and "data" command.