On Tue, Jan 08, 2013 at 01:08:21PM -0500, Wietse Venema wrote:
> I could add an option to treat this in the same manner as "failure
> to connect" errors (i.e. temporarily skip all further delivery to
> this site). However, this must not be the default strategy, because
> this would hurt the far majority of Postfix sites which is not a
> bulk email sender.
Such a feedback mechanism is a sure-fire recipe for congestive
collapse:
- A brief spike in traffic above the steady input rate cases the
message-rate to trigger rate limits at the remote destination.
- Postfix throttles to the destination for many minutes.
- A lot of additional mail arrives while the destination is throttled.
- When the queue is unthrottled, the message rate will immediately
spike above the remote limit. And the queue is throttled.
- Lather, rinse, repeat
The *only* way to deal with rate limits, is to avoid traffic spikes,
which is only possible if you also avoid traffic troughs, and send
at a *steady* rate that is *below* the remote limit, but above the
input rate.
When the steady-state input rate is above the remote limit, no
scheduler strategy can avoid congestive collapse.
For remote sites that enforce indiscriminate rate limits (for all
senders, not just those who have a history of reported spam), the
only strategy is to:
- Send below the rate that triggers the rate-limit
- Buy more machines, and hope that rate limits are per
sending IP, not per sending domain. (showshoe).
- In some cases, the rate limits are reputation dependent,
and it takes time to "build" a good reputation. In that case
one needs to ramp traffic to the domain over time, by generating
less mail intially, and building volume over time. This is done
outside of the MTA, in the mail generating engine.
Thinking that delaying sending is a good idea is dead wrong. The
optimal strategy is to always send as fast as possible and no
faster!
--
Viktor.
