On Wed, Jan 09, 2013 at 10:02:02AM -0200, Rafael Azevedo - IAGENTE wrote:
> > 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, ?
>
> I totally disagree with you. It would have more I/O having postfix
> trying to deliver when there's an active block. Messages are kept
> in disk/memory for much longer time, and Postfix keeps putting it
> from deferred to active and then back to deferred again. Plus, you
> can't forget that there are more messages coming in the mean time
> while the block is still active, leading postfix to a **infinite**
> loop (until it reaches maximal_queue_lifetime)
The part you're missing is that when Postfix "stops sending" the
only mechanism in place other than a rate delay is "throttling"
the destination queue, which moves every message (even those that
have not been tried yet), from "active" to "deferred", and the
same happens to any message that happens to arrive while the
queue is throttled.
The delivery rate to the destination will be a small number of
messages per $maximal_backoff_time, this is not terribly useful,
with the entire backlog shuffling between the active and deferred
queues, without any useful work being done.
> > To understand what one is asking for, one needs to understand the
> > scheduler (qmgr) architecture. Otherwise, one is just babbling
> > nonsense (no offense intended).
>
> Where can I read more about this?
SCHEDULE_README, the queue manager man page and source code.
> >> 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.
>
> Sorry Viktor, but I'm not sure about that. You keep saying to
> get whitelist like if it would be very easy. Believe me, there are
> a lot of companies that don't have any support for that.
I listed all the options available to you, one which "whitelisting"
is always the best when possible. When not possible you try one
of the others.
> > 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.
>
> But why move all the "active" queue to deferred? Wouldn't it be
> better to just move it to hold queue?
This suspends delivery of a (multi-recipient) message for all
deferred destinations, not just the ones you want treated specially.
Messages on hold don't get retried without manual intervention, that
makes your delivery rate to the destination zero, not a good way
to get the mail out.
> > 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.
>
> What's the meaning of "Snowshoe"?
Spread the load over sufficiently many outbound systems that the
rate limits are not exceeded by any of them. A fifth option is
to outsource to others who've already done that.
--
Viktor.
