----- Original Message -----
From: "Theo Schlossnagle" <jesus(_at_)omniti(_dot_)com>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Cc: <jesus(_at_)omniti(_dot_)com>
Sent: Monday, February 16, 2004 11:38 AM
Subject: Re: [SPF-Discuss] Performance issues
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.
Right. So do we. A given, but not necessarily how it will be deployed if
you look at the "developer tools" being offered at the spf web site :-)
Also, please note initial premise of the original message. This concept
addresses spoofers. Until it is widely deployed, obviously the initial
majority of your queries will include failures for valid systems but it will
also include a high failure rate for invalid domain spoofers.
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.
Perhaps I should of been more specific. We have a suite of validations
techniques, not just SPF, so I wasn't attempting to compare the overhead of
SPF vs RCPT TO validation, but in general, all validation you might need to
do at the protocol level. If your total validation, which might now
include SPF, you might want to consider to the ultimate criteria most
systems use to whether an anonymous access transaction message is accepted
or not.
I don't understand your numbers. 68 seconds to do what?
Right, again, the comparison was part of a total suite of validations
methods, including a CBV (call back verifier).
If interesting take a look at our ANTI-SPAM SMTP statistics at
http://www.winserver.com/sslinfo. Specifically, on Dec 25/26 we switched to
the logic of only performing the validation after the RCPT was checked.
Before then, the total transation time that includes all the validation
methods, average ~68 seconds. Afterwards, it was drastically reduced to ~22
seconds.
Its not a matter of CPU cycles, but total transaction time that is important
in a high scale system. The fast perform the transaction, the better it is
for scalarability.
SPF will catch more fraudulent spam than those RBLs, so
many of those RBL requests will disappear -- as the SPF test will fail
first.
That would be nice to believe this, but I personally doubt it. This is
only my opinion of course, but SPF is not going to make other protocol
level methods obselete, and certainly SPF is not going to force the site
operators that they better get another line of (life) "work." In then, in
my view, SPF or LMAP based propoals is a short term kludge with a high
barrier of entry vs what it trying to accomplish/address - a problem with a
dismishing half life. If the ultimate result is not presumed, then we are
just beating a dead horse. :-)
Don't get me wrong, I'm not knocking SPF. In fact, I admire the author in
accomplishing something that not many have been able to do - promote change
and progress to solve real industry issues, a dearth in IETF for so many
years.
In anycase, I like it. SPF will do the job for now, especially at doing at
what it does best, trapping local domain spoofs, but I am still not
convinced it will be a long term solution. It still doesn't solve the
spoofing SPF system and I am totally convince this SRS is not the right
approach to closing the gaps.
Anyway thanks for your input. I was just providing my own insight in our
LMAP implementation - "Things to consider."
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com