On Feb 23, 2011, at 4:27 AM, Noel Jones wrote: > On 2/22/2011 11:44 PM, Robert Goodyear wrote: >> >> On Feb 22, 2011, at 9:06 PM, Noel Jones wrote: >> >>> On 2/22/2011 9:29 PM, Robert Goodyear wrote: >> >>> The postfix connection caching algorithm will automatically limit the >>> damage caused by a subset of slow-responding relayhosts. >> >> I suppose there's a tipping point of how much it would queue in memory >> versus paging it off to disk, right? Or would, for example, our friends at >> (name your favorite ISP here) decide to greylist us and just saturate the >> deferred queue such that the subset becomes the majority? In other words, is >> Postfix's algorithm written to prevent exclusive saturation by reserving >> some percentage of its allocated limits for !=(grouchyISP) > > That was referring to mail for a single destination, such as a relayhost > farm. For general high-volume internet delivery, it's generally recommended > to have an internal fallback_relay or two that collects mail that can't be > delivered right away. This keeps the defer queue low and keeps slow/dead > destinations for hogging the active queue. This is covered in the docs > referenced earlier.
Ah right... I'll add a couple more fallbacks. I'm only running one behind six edge MTAs so I should increase the ratio as I add more edge MTAs. > >> I just had a thought, however... I wonder if I can mess with the backoff >> behavior of my edge MTAs to tell my origin server to cool it a bit in >> response to its (the edge's) workload? Will MX parity cause Postfix to hear >> the backoff request and move on to another equally-weighted server, or will >> it just defer the message and mark it as being destined for the exact same >> server that it handshook with and got the backoff request from? > > Postfix does not remember the last host tried for a destination, and looks up > the MX each time the message is scheduled for delivery. Most of the grouchy > ISPs have some sort of registration program for high-volume senders so you're > not throttled or blacklisted. Oh trust me, I have a one person on my team who spends most of his time maintaining unsubscribes, blacklists, feedback loops, whitelist requests, RBL pleadings (it's amazing how many RBLs spring up out there because someone thinks they've invented a better mousetrap. Unfortunately it only impacts legitimate senders and costs us time and money, whereas the spammers are unperturbed and just stay one step ahead) So: the message is ready to send. Postfix queries DNS for my smarthost entry and gets MTA1 = 10, MTA2 = 10. Postfix opens a connection to MTA1 which responds with a 'not now, too busy' response. Does Postfix hold the MX record in memory _for the duration of THIS message's delivery attempt_ knowing that MTA2 is next, or does Postfix re-query to look for another peer immediately? If it re-queries, and knowing that SMTP randomize should return a random result, and if MTA1 is _not_ known to have (soft) failed just a moment ago, then technically the next attempt has a 50% chance of hitting MTA1 for a retry, right? I guess what I'm getting at is that if there's no marking of the equal-weighted MX peers' responses within the context of _THIS_ message's attempts, I can't really load-distribute internally without the chance knocking on the same door twice. Which isn't a bad thing so much as me just wanting to really understand the line of execution.
