On Thu, Jan 03, 2019 at 07:04:53PM -0500, Wietse Venema wrote:
> > If you're willing run your own franken-postfix, hard coded to run
> > one queue per transport whenever the recipient limit > 1, you could
> > test the below. I have no time to create a documented configurable
> > (mis)feature along these lines.
>
> He needs a SYN rate limiter.
I was under the impression that there's no code in the queue manager
that distinguishes between successful and failed delivery attempts
when it comes to rate delays. The feedback channel from the delivery
agent to the queue manager is intentionally minimal, all I see the
queue manager learning is:
* Destination ok, apply positive feedback, keep going after
any rate delay
* Destination down, apply negative feedback and
possibly throttle the queue. Otherwise, keep going (seemingly
also after any rate delay).
* Delivery agent broken, throttle the transport.
The only visible side effect of a completed delivery without a crash
is a change in the queue's busy count, and a change in the queue's
concurrency window. I don't see any way for the scheduler to
distinguish between completed deliveries and connection failure.
Likely I am missing some key insight, please pardon any confusion...
So, if destination down avoids rate delay, wouldn't that mean that
with the destination_concurrency_failed_cohort_limit > 1, throttling
may leave the transport ready for another delivery without incurring
a rate delay pause?
I don't think that'd be a feature, throttling may result from
connection failure, or a "[45]XX" code in the banner or EHLO reply,
or a lost connection, and I would expect that this a reason to skip
delaying the next delivery?
--
Viktor.
