On 09/05/2010 04:59 PM, Wietse Venema wrote:
Jeroen Geilman:
As for your original question, the combined processing time of all your
smtpd_* checks will still be reflected in the delay-"a" value (pre-queue).
Whatever time postfix itself adds for processing will be either static
or insignific
Jeroen Geilman:
> As for your original question, the combined processing time of all your
> smtpd_* checks will still be reflected in the delay-"a" value (pre-queue).
> Whatever time postfix itself adds for processing will be either static
> or insignificant (unless you have lots of expensive map
On 09/04/2010 10:42 PM, Stan Hoeppner wrote:
Victor Duchovni put forth on 9/4/2010 7:33 AM:
What do you mean by "filters"?
Spam filters in the form of table lookups and dnsbl queries. I'm
currently processing
12,581 CIDRs
1,568 regular expressions (PCRE)
5 dnsbl lookups
p
Victor Duchovni put forth on 9/4/2010 7:33 AM:
> What do you mean by "filters"?
Spam filters in the form of table lookups and dnsbl queries. I'm
currently processing
12,581 CIDRs
1,568 regular expressions (PCRE)
5 dnsbl lookups
per each inbound connection (assuming no hits). Obvious
On Sat, Sep 04, 2010 at 03:02:00AM -0500, Stan Hoeppner wrote:
> If we're using delays=a/b/c/d for troubleshooting that's fine. But if
> we're expecting to be tuning a server for performance based on log
> metric data we need time data for our rejected messages as well.
The purpose of the a/b/c/
Considering that spam accounts for the bulk of all client connections to
an MX these days, it might be beneficial if we had log data showing
total time per session, not just for queued mail, so an OP can see how
long it's taking to reject at the smtpd stage, as well as time elapsed
when rejecting m
