Site Configuration Keyword Reference for LISTSERV 17.5

Platforms

All non-z/VM Classic HPO.

Abstract

Defines bandwidth limits for the server.  Typically used with delivery pools, but can be used to set a server-wide bandwidth limit.

Example

See Details.

Details

Requires LISTSERV Classic HPO running on a non-z/VM platform.

It is possible to "rate-limit" LISTSERV's output to its SMTP_FORWARD host(s) by defining limits for individual delivery pools (or server-wide if you do not choose to implement separate delivery pools).  This is done by setting the site configuration variable SMTP_RATE_LIMIT appropriately.  For example, the following setting rate-limits the entire server to 12Mbps of throughput to the outbound forwarding host.

Using the feature with delivery pools allows the server administrator to limit the impact that large lists or large DISTRIBUTE jobs have on total throughput from LISTSERV to its outbound MTA(s), reserving sufficient bandwidth so that administrative mail and smaller lists can get through at the same time. Thus a more complicated rate-limiting scheme might be as follows:

In this case, the entire server (including existing delivery pools that have not been otherwise specified) is limited to 12Mbps outbound, while pools A and B are limited further to 1.5Mbps and pool C is limited to 150kbps.  Anything not mentioned is unlimited. In the above example, D is technically unlimited, other than for the overall 12Mbps limit for all traffic.

Each outbound message belongs to exactly one pool and is subjected to exactly two rate limits (either of which can be unlimited): the pool rate limit and the overall rate limit. Whichever is strictest at this particular moment sets the bar.

The formal syntax of SMTP_RATE_LIMIT is

Please note carefully the following:

• A LISTSERV HPO LAK is required.
• LISTSERV's rate-limiting imperatively requires that asynchronous SMTP "workers" (SMTP_FORWARD_n) be used. Results will be unpredictable if used with the deprecated ASYNCH_SMTP option. The fallback SMTP_FORWARD (synchronous) delivery mechanism ignores rate limits.
• The rate limit is specific to LISTSERV. It can be used to limit the rate at which LISTSERV feeds your outbound SMTP MTA, but it does NOT limit the rate at which your MTA feeds messages to the outside world. Rate-limiting your MTA on the outbound side is beyond the ability of LISTSERV to control.
• Rate limiting does not split messages. Any given message is either sent immediately as it is, or delayed. If you have large attachments with MAXBSMTP=10000, you will not get a smooth ride. If you want a smooth traffic graph on your network monitor, make sure that MAXBSMTP is low enough. This being said, it will work either way, correctly and accurately.
• The limit is applied to the size of the message body (including RFC822 headers and CRLF, but not including the RFC821 envelope). This may require that the rates be tweaked somewhat to get the actual desired performance.
• To keep synchronization overhead to a reasonable level, the rate limits are split among participating workers, which work independently as they always have. A little report is written at the beginning of the SMTP worker log. This means you will probably see somewhat less usage than you have requested, especially if you have workers servicing multiple pools. When worker #1 is servicing a large distribution for pool B, its rate quota for pool A is not being used. Worker #2 has no idea what worker #1 is doing and cannot "borrow" its pool A quota during this time. There is a simple solution to that problem: one worker, one rate-limited pool.
• For reference, kilo, mega and giga as used by SMTP_RATE_LIMIT are powers of 2, not 10. 

Default Value

0, that is, rate-limiting is disabled.