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

Re: Dead Destination configuration

Expand Messages
  • DN Singh
    Thanks for the suggestion Robert, but how do I find the time for which Postfix will not attempt a delivery after reaching the fail limit? Instead of
    Message 1 of 41 , Dec 1, 2011
    • 0 Attachment
      Thanks for the suggestion Robert, but how do I find the time for which Postfix will not attempt a delivery after reaching the fail limit? Instead of outsourcing the task to script, and increasing a dependency, it would be better to keep it with Postfix itself, if possible.

      If there aren't any options, I may have to go with the script. Then, I may need some more help...

      Thanks,
      DN Singh

      On Thu, Dec 1, 2011 at 1:29 PM, Robert Schetterer <robert@...> wrote:
      Am 01.12.2011 08:35, schrieb DN Singh:
      > Hello Group,
      >
      > I am trying some extra configuration for postfix where it would mark
      > some destinations as undeliverable. I have found that there are some
      > destinations, start deferring the mails (may be greylisting) for a
      > particular period of time (times ranging from 1min to 4hrs), and after
      > the time window is over, they accept mails properly. So, I would like to
      > configure per-destination dead time limit, where Postfix would not
      > attempt any delivery at all to a destination for the mentioned time.
      >
      > I tried configuring backoff-time, but it only comes into picture after
      > first attempt, which will get deferred, during time the destination is
      > differing. Next, I found
      > "default_destination_concurrency_failed_cohort_limit", but I was unable
      > to find to time for which it will remain dead. I know this is transport
      > configurable, so I can configure different time limits for different
      > destinations. This is because, I do not want any delivery attempts
      > during the time when a destination is marked dead.
      >
      > Is this possible? If yes, then how?
      >
      > Thanks.
      > DN Singh

      perhaps put some kind of scripted hold on them
      if they are always the same

      or use ideas from

      http://www.postfix.org/QSHAPE_README.html#backlog

      Postfix version 2.5 and later:

         In master.cf set up a dedicated clone of the "smtp" transport for
      the problem destination. In the example below we call it "slow".

         In main.cf configure a short delay between deliveries to the same
      destination.

         /etc/postfix/main.cf:
             transport_maps = hash:/etc/postfix/transport
             slow_destination_rate_delay = 1
             slow_destination_concurrency_failed_cohort_limit = 100

         /etc/postfix/transport:
             example.com  slow:

         /etc/postfix/master.cf:
             # service type  private unpriv  chroot  wakeup  maxproc command
             slow      unix     -       -       n       -       -    smtp

      See also the documentation for default_destination_rate_delay.

      This solution forces the Postfix smtp(8) client to wait for
      $slow_destination_rate_delay seconds between deliveries to the same
      destination.

      IMPORTANT!! The large slow_destination_concurrency_failed_cohort_limit
      value is needed. This prevents Postfix from deferring all mail for the
      same destination after only one connection or handshake error (the
      reason for this is that non-zero slow_destination_rate_delay forces a
      per-destination concurrency of 1).


      --
      Best Regards

      MfG Robert Schetterer

      Germany/Munich/Bavaria

    • Jeroen Geilman
      ... There are two solutions you can try: within one instance, or using a separate instance, which will have its own queue. Within one instance, you can use a
      Message 41 of 41 , Dec 7, 2011
      • 0 Attachment
        On 2011-12-06 10:02, DN Singh wrote: Can you please name the topic, so I can search about it? It would be of great help.

        On Mon, Dec 5, 2011 at 10:41 PM, Jeroen Geilman <jeroen@...> wrote:
        On 2011-12-05 15:36, DN Singh wrote:
        Yes, I tried to figure it out that way, but the numbers aren't constant.

        Have you considered that this is because your submission is not 100% flat ?
        If you submit or retry in bursts (and when they block you for a fixed period of time after denying access, you WILL see clumping) then why expect their rejections to follow a different pattern ?

        As the people with much experience and experimentation on this list suggest, run separate delivery routes - with separate queues - for these slow destinations.
        All this is very well documented in the list archives.

        --
        J.



        There are two solutions you can try: within one instance, or using a separate instance, which will have its own queue.

        Within one instance, you can use a so-called *slow transport* to deliver mail to problematic domains at greatly reduced speeds.

        The basic theory behind this is described in: http://www.postfix.org/TUNING_README.html#rope

        To push mail for example.com to such a slow transport, use a transport_maps entry:

            example.com    smtp:myslowtransport

        Where myslowtransport is a service defined in master.cf.

        The more flexible solution is to set up a second instance of postfix (on an arbitrary internal port, say 127.0.0.1:2525) and push all slow mail to that instance.

        You then have complete control over queue lifetimes, backoff schedules, retry mechanisms, custom errors or deferrals, etc etc etc.

        (Sorry, I couldn't find a mailing list example in the time it took me to write this :)


        -- 
        J.
      Your message has been successfully submitted and would be delivered to recipients shortly.