Tomoyuki Murakami:
> > And how much time would that be? Keep in mind that postscreen
> > does not always wait for the 6-second pregreet delay. It only
> > waits when the PREGREET or DNSBL test is not whitelisted.
>
> >From my observation related to DNSBL query time,
> (https://sites.google.com/site/tomoyukipostfix/)
> almost all DNSBL queries completed within 350 ms. for
> zen.spamhaus, b.barracudacentral is more fast, less than 200 ms.
DNSBL lookup timings are not relevant for CLIENT HOSTNAME lookup.
The system adminstrator chooses the DNSBL domains. Perhaps surpsingly,
DNSBL servers are run in a highly-available configuration.
The SPAMMER chooses the client IP address (and hence the reverse
DNS server). Perhaps surpsingly, the typical reverse DNS server
is not operated in a highly-available configuration.
> If the dead-line are assumed to 350 ms, about 56% of
> reverse-resolve would be completed. rest of them would be forced
> UNKNOWN. former(56%) are consist of 47% named and 53% un-named
> clients.
> a limited time slot of ~350 ms. is too short for resolving
> reverse-names.
> Contrary, If there are time to wait for completion, 95% would
> gets results within 1.4 sec. from my observation.
So you want postscreen to wait 1.4 seconds before allowing
a whitelisted connection to proceed? That is completely
contrary to the design principle, which is to minimize
delays for legitimate email.
Or, you want postscreen to log UNKNOWN most of the time, and a
reverse client name only some of the time? In that case why bother
with a system that is so inconsistent that it will log the name of
a client only some of the time?
I think that you need to do more research on these issues before
I am going to spend more time arguing about this.
Wietse
