On Wed, Feb 23, 2011 at 02:19:28PM -0800, Robert Goodyear wrote:
> I'm sorry... I was speaking lazily there. I meant a 4.X.X response
> that would cause the message to requeue and follow a retry/backoff
> rate algorithm.
Mere 4XX responses to "MAIL FROM:", "RCPT TO:", "DATA" or "." don't impact
active queue scheduling. Only responses that prematurely termination the
connection, or a 4XX banner or HELO response trigger backoff (concurrency
reduction and possible throttling of the destination after sufficiently
many consecutive failures).
> > What negotiation? What problem are you trying to solve?
>
>
> Trying to load-share my edge MTAs that are relayhosts from my origin
> Postfix in a more scientific way than just hitting them at random,
> because when one becomes saturated, its weight in the probability of
> receiving another request is not reduced programmatically.
This is not necessary. The random loading is fine at low loads, under
high loads Postfix connection caching is time-based rather than message
count based, which means that faster servers get a bigger share of the
load. Some sites foolishly set limits on the number of deliveries per
connection not just for suspect clients, but for all SMTP clients. They
are doing themselves and everyone else a disservice.
> By negotiation, I mean the SMTP session from my origin to the relay
> wherein it might get a 4.X.X
Not all 4XX responses are alike, tempfailing a message is normal,
rejecting SMTP service is another matter. You still have not explained
what real problem you're solving. Is this just premature optimization?
> -- if I can apply some logic that takes that
> one relay out of rotation for N minutes, that would be nice, because it
> would reduce chatter from subsequent retries and focus traffic on the
> other relays for a while.
Have you seen problem relays in your upstream relay mix? What real
symptoms do they exhibit and what is the observed impact on the upstream
Postfix SMTP client?
--
Viktor.
