In <000901c3f875$224a69b0$6401a8c0(_at_)FAMILY> "Hector Santos"
<winserver(_dot_)support(_at_)winserver(_dot_)com> writes:
Meng,
I'm not Meng, but I'll poke my nose in anyway.
SPF itself has added atleast 1 to 3 seconds to the session time.
Does SPF add a constant 1-3 seconds, or does it vary widely with a 1-3
second average?
I am not an expert with DNS technology, but I would like know why this
would be the case. DMP does have the dual lookup for the return path
domain and machine domain. Is there a difference in that with SPF you are
searching a domain vs. DMP where you have an "in-addr" sub domain lookup?
The in-addr subdomains are notorious for being poorly run. There
tends to be lots of addresses that timeout causing a >5 second delay.
(IIRC, there are RFCs that say that all IP addresses that are used
must have a valid in-addr pointer, but RFCs are often ignored.)
Worse, these name server failures are not cached like NXDOMAIN
failures are. So, on my system, every time I run "host 192.0.2.200",
it takes 25 seconds. The "host -t ptr 200.2.0.192.in-addr.arpa"
command is somewhat quicker, taking only 15 seconds to error out.
SPF doesn't, in theory, require in-addr lookups in most cases. SPF
does in-addr lookups only when the ptr: mechanism is used, or the %{p}
macro variable is used.
In practice, SPF requires in-addr lookups quite often. the best_guest
check includes the ptr: mechanism. The trusted-forwarder lookup
currently uses the %{p} macro variable. Originally,
trusted-forwarder.org didn't use the %{p}, but there are quite a few
forwarders that are hard to find IP addresses of their outgoing mail
servers, so it is much easier to add their names.
I'm not sure what to do about this situation.
*sigh*.
-wayne