290529Re: destination_rate_delay and connection_reuse_time_limit
- Jan 8, 2013Am 09.01.2013 03:17, schrieb Viktor Dukhovni:
>> the request was "after 20 temp fails to the same destinationand the request was if the behavior can be controlled in
>> 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).
the future and not was the behavior currently is
> Throttling the destination (which means moving all pending messagessorry, but you really NOT understand the usecase
> for the destinatin to deferred, where they age exponentially, while
> more mail builds up...) is not the answer to your problem.
"while more mail builds up"
NO there is NO MORE MAIL built up
* DEDICATED NEWSLETTER MACHINE
* means large amount of mails one or two times a week
> 1. Get whitelisted without limits, send at the arrival rateno option
> 2. Get whitelisted at above the arrival rate, set rate delay toyou missed
> avoid exceeding the rate
smtp_destination_recipient_limit = 15
smtp_initial_destination_concurrency = 2
smtp_destination_concurrency_limit = 2
smtp_destination_concurrency_failed_cohort_limit = 10
smtp_destination_rate_delay = 1
> 3. Don't waste time with unresponsive mailbox providers, tell theirreailty check: you propose to tell my customers that
> customers their mailbox provider is not supported.
they should tell their customers anything because the
mailadmin would like to get rid of the permamently
"try again later" messages in his maillog
this will not happen in the real world
- << Previous post in topic Next post in topic >>