Delay threshold TCPIP-channel-specific options

== TCP/IP-channel-specific options: 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 by 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  are in bytes, not blocks. The  values are interpreted as hundredths of seconds.

See also MeterMaid for an alternate way of implementing such intentional response delays.

See also:
 * TCPIP-channel-specific options
 * MeterMaid