On Wed, Jan 09, 2013 at 03:06:58AM +0100, Reindl Harald wrote:
> > Suspending delivery and punting all messages from the active queue
> > for the designated nexthop is not a winning strategy. In this state
> > mail delivery to the destination is in most cases unlikely to
> > recover without manual intervention.
>
> it is in the usecase of a DEDICATED newsletter relay
> why should it not recover?
>
> the request was "after 20 temp fails to the same destination
> retry the next delivers to THIS destination FIVE MINUTES later"
That's not what happens when a destination is throttled, all mail
there is deferred, and is retried some indefinite time later that
is at least 5 minutes but perhaps a lot longer, and at great I/O
cost, with expontial backoff for each message based on time in the
queue, ...
To understand what one is asking for, one needs to understand the
scheduler (qmgr) architecture. Otherwise, one is just babbling
nonsense (no offense intended).
> > I would posit that neither Reindl nor the OP, or that many others
> > really understand what they are asking for. If they understood,
> > they would stop asking for it.
>
> i would posit you do not understand the usecase
How likely do you think that is? Of course I understand the use
case, in fact better than the users who are asking for it.
> and yes we do not care if a newsletter has reached every RCPT
> two hours later but we do care for reputation and not exceed
> rate limits of large ISP's
Throttling the destination (which means moving all pending messages
for the destinatin to deferred, where they age exponentially, while
more mail builds up...) is not the answer to your problem.
1. Get whitelisted without limits, send at the arrival rate.
2. Get whitelisted at above the arrival rate, set rate delay to
avoid exceeding the rate.
3. Don't waste time with unresponsive mailbox providers, tell their
customers their mailbox provider is not supported.
4. Snowshoe.
Pick the first one that is viable for you.
--
Viktor.
