spf-discuss
[Top] [All Lists]

Performance issues

2004-02-16 09:17:17
One of the drawbacks with LMAP-based proposals such as DMP and SPF, its the
high overhead potential in DNS lookups.

LMAP proposals have a major initial benefit - validating your own local
domains.  This is no doubt, the top #1 benefit gained - protection local
domain spoofing.

However, with 60-80% of the spammers are "spoofers" including using invalid
domains, there is a considerable overhead in failed DNS lookups for external
domains.

This has been an empirical result of our implementation of LMAP based
solutions which include DMP and SPF for the past 3-4 months in production
operations.

This is why we were forced to provide SMTP system (sysops) the option that
offers "list of LMAP domains" to check.   Of course, how this list is
generated is not the point.

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.

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.

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).

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.

Thanks

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com






<Prev in Thread] Current Thread [Next in Thread>