Delay threshold TCPIP-channel-specific options

From Messaging Server Technical Reference Wiki
Jump to: navigation, search


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 SIZE_DELAY_THRESHHOLDS are in bytes, not blocks. The *_DELAY_AMOUNTS values are interpreted as hundredths of seconds.

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


See also: