On Mon, 2004-02-16 at 11:17, Hector Santos wrote:
One of the drawbacks with LMAP-based proposals such as DMP and SPF, its the
high overhead potential in DNS lookups.
It isn't a high overhead really. From a system performance standpoint
it is negligible. A DNS query requires UDP packet. DNS is one of the
cheapest directory protocols in existence -- which is why it is so
ubiquitous.
The point is simply relying on DNS caching is not sufficient. You may need
to also do your own "intelligent" caching and learning of results.
Of course. This is a given. We see relatively high hit-rates on our
application-internal cache.
In additional, I would like to suggest two SPF optimization considerations;
one for SPF implementators (sysops adding SPF records) that they try to do
so that help will minimized the required lookups by client, and one for SPF
client software implementators (SMTP developers).
1) Reduce lookups by using IP4/IP6 directives.
If possible use IP4/IP6 directives if possible. Adding references to
additional DNS lookups only contributes to overhead and redundancy.
2) Delay SPF validation until RCPT TO: validation, if any, is finalized.
That costs much much more. Validating a RCPT TO can include a long list
of things including checking existence, account status, quotas, etc.
Checking SPF records requires almost 0 CPU and our evidence shows that
the average check requires about 6 DNS requests... That is 6 UDP packets
our and 6 in.
Clients should avoid or delay lookup into your RCPT TO: validation is
performed. Of course, if RCPT TO validation is performed and
rejected/refused for some reason, then performing any other validation is
redundant and unnecessary. If you follow this tip, you will reduce your
total session time by nearly 300% (in our case from 68 seconds to 22
seconds).
I don't understand your numbers. 68 seconds to do what? Our typical
SPF validation is subsecond. But, the length of time it takes is pretty
much irrelevant as long as it is both bounded and reasonable. Simply
put, clients can wait -- a second or two... or event 10. Because
"clients" here are just other MTAs. The point is it that is takes
almost 0 system resources to do the checks.
The fact that you may have to wait 10 seconds to get your DNS response
back isn't a big issue. You wan't burning CPU, you aren't burning
network and you aren't burning Disks.... So, you can other things with
your resources while that session is "waiting".
Just consider that if SPF is going to be widely deployed, there is going to
be alot of network traffic. We need to do our best to minimize this at by
the sysop end and software end.
Minimizing network traffic is always a good goal. But many people use 3
or more DNS RBLs already -- and paranoid lookups (in-addr.arpa + A +
correlation). SPF will catch more fraudulent spam than those RBLs, so
many of those RBL requests will disappear -- as the SPF test will fail
first.
I haven't seen, nor foresee SPF incurring an unreasonable increase in
DNS traffic -- especially with application-internal caching.
--
// Theo Schlossnagle
// Principal Engineer -- http://www.omniti.com/~jesus/
// Postal Engine -- http://www.postalengine.com/
// Ecelerity: fastest MTA on earth