On Feb 23, 2011, at 12:04 PM, Victor Duchovni wrote: > On Wed, Feb 23, 2011 at 11:49:34AM -0800, Robert Goodyear wrote: > >>> Postfix remembers dead destinations, not dead hosts. When a live >>> destination is served by hosts a subset of which are down, demand >>> connection caching kicks in under load and reduces the frequency >>> of (probabilistically slow) connection attempts. >> >> I guess I'm most interested in what happens when a backoff response is >> sent back from my edge (relayhost/smarthost) MTA to my origin MTA. > > I don't know what a "backoff response" means. There is no such term > defined in the SMTP RFC.
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. > >> Since this is not a dead MX we're talking about, I'm trying to understand >> the negotiation and see if rapidly-expiring internal DNS TTL would actually >> _do_ anything or just shake up the randomization, which is pointless. > > 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. By negotiation, I mean the SMTP session from my origin to the relay wherein it might get a 4.X.X -- 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. I realize that just adding relays to my topology in an equal-weighted priority gives a _similar_ result, but that's not deterministic.
