On Feb 23, 2011, at 8:25 PM, Victor Duchovni wrote: > 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?
I'm going to run some analytics on my last 12 months' worth of outbound messages to get more scientific with my gut instincts here. It's about 270 million messages, and my observation is that when we have a spike of 4 or 5 million that need to deliver at a certain point in time (surrounding a critical/time-sensitive product launch) that my deferred queues saturate too quickly. Again, rather than just brute-force it with more edge MTAs, I was hoping to devise a more deterministic way to control the internal relaying to my geographically-separated points of presence and shave off the few ms of conversation that are consumed in finding out if relay X will accept more messages yet.
