Am 30.07.2016 um 23:10 schrieb Bill Cole:
On 30 Jul 2016, at 7:10, Kim Roar Foldøy Hauge wrote:I'm no expert here, but postgrey is usually a purely local test. It should terminate with a "currently busy, try again later" message very quickly.Unless your database is very large, yes.SPF checks and white listing require dns lookups that can potentially take much longer. Several orders of magnitude longer.Occasionally, yes, no matter how you do DNS. However, Postfix smtpd will do multiple DNS lookups that have a strong chance of being slow before getting to any policy daemon like Postgrey. Alternatively, postscreen is a much simpler process than smtpd and in its usual config does nearly no input processing while doing DNSBL lookups in parallel, time-limited to 10s. This is usually much more efficient for dealing with spambots than going through everything that smtpd does before calling any policy daemon. Most DNSBLs worth using have robust authoritative DNS, so (unlike SPF or IP->Hostname->IP checking, both of which can require many queries) it is rarely slow to get DNSBL results
and it don't eat any smtpd process, responses shoudl be cached by a local, rescursing resolver anyways and finally postfix-smtpd/postrey have only to deal with a very low volume and the very expensive content filter sees mostly ham
*if* a message makes it through postscreen and up to greylisting the DNSWL and SPF results are cached anyways and re-used by spamasssassin which can even re-use the spf header of the python policyd
our ould MX had peaks with 3000 MHz on the ESXi cluster, the current one after switch to postscreen and configure things proper including shortcircuit is running most of the time with 60-250 Mhz by a amount of 15000 destination addresses spammers try to deliver crap
signature.asc
Description: OpenPGP digital signature
