Wietse Venema: > Stefan Foerster: > > I don't send any large volumes to Yahoo, but I had to use a dedicated > > transport which ignored much more errors for a popular German freemail > > provider. Since you are using rate delays, your concurrency limit will > > basically be one, and this might very well be related to what you see. > > This is a good point. > > To compensate for this unwanted side effect of reduced concurrency > INCREASE the fragile_destination_concurrency_failed_cohort_limit > to 10-20 or so (or REDUCE fragile_destination_concurrency_negative_feedback > to 1/10 or 1/20).
I just did a few experiments to confirm this. With the default fragile_destination_concurrency_failed_cohort_limit, the scheduler defers all mail after one connection/handshake failure. With fragile_destination_concurrency_failed_cohort_limit > 1 the scheduler defers all mail after multiple connection/handshake failures in a row, which may be more desirable in the Yahoo scenario. For now, I'll add a note to the documentation. A clever software solution is not obvious - when a home office user needs to limit their output rate, it may not be a good idea to keep sending mail after the ISP starts pushing back. > > I don't know if you need to reload postfix and/or requeue the messages > > with "postsuper -r" after changing > > transport_destination_concurrency_failed_cohort_limit. > > No. Use "postfix reload" to update the queue manager. > > Wietse > >
