281782Re: Dead Destination configuration
- Nov 30, 2011Am 01.12.2011 08:35, schrieb DN Singh:
> Hello Group,perhaps put some kind of scripted hold on them
> 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?
> DN Singh
if they are always the same
or use ideas from
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
transport_maps = hash:/etc/postfix/transport
slow_destination_rate_delay = 1
slow_destination_concurrency_failed_cohort_limit = 100
# 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
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).
MfG Robert Schetterer
- << Previous post in topic Next post in topic >>