> 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) > > 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? > >>> 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. 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. > >> 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. But why move all the "active" queue to deferred? Wouldn't it be better to just move it to hold queue? > > 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"? - Rafael
