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

290529Re: destination_rate_delay and connection_reuse_time_limit

Expand Messages
  • Reindl Harald
    Jan 8, 2013
    • 0 Attachment
      Am 09.01.2013 03:17, schrieb Viktor Dukhovni:
      >> the request was "after 20 temp fails to the same destination
      >> 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).

      and the request was if the behavior can be controlled in
      the future and not was the behavior currently is

      > 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.

      sorry, but you really NOT understand the usecase

      "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 rate

      no option

      > 2. Get whitelisted at above the arrival rate, set rate delay to
      > avoid exceeding the rate

      you missed

      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 their
      > customers their mailbox provider is not supported.

      reailty check: you propose to tell my customers that
      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
    • Show all 74 messages in this topic