Loading ...
Sorry, an error occurred while loading the content.

266715Re: dealing with Yahoo slowness

Expand Messages
  • Wietse Venema
    Jun 19 6:20 AM
      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
    • Show all 26 messages in this topic