Charles Gregory a écrit : > On Fri, 8 May 2009, Mark wrote: >> Okay, working from the idea that indeed the connecting client is >> timing out waiting for the "250 OK" after sending the message, I would >> think DNS lookups are the most costly, time-wise. So, I would examine >> the RBL lookups first: it only takes the presence of one or two >> defunct DNSBL lookups, or an unruly 'rbl_timeout' setting, to muck >> things up. > > I run the 'standard' set of RBL lookups for SA. Though it's worth > mentioning that my front end runs a half-dozen 'high trust' RBL's > while processing the envelope RCPT command. So by the time DATA is > accepted, those should be cached locally,
does your front end parse the received headers and check the IPs found there against DNSBLs? if not, then caching will only work for the IP that sent the message to your "front end". > and not add to the time > that SA is running. I think maybe I should look for a convenient way to > limit the RBL checks to the 'most popular' (most reliable, good hits) > RBL's.... you may want a two-step SA: - during smtp time, run a "lightweight" SA (minimize latency and minimize FPs, at the cost of increasing the ratio of FNs) - after mail has been accepted, pass it through a "normal" SA configuration
