-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of Marc
Chametzky
Sent: Tuesday, March 22, 2005 3:22 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] Re: DNS load research
Excuse me for jumping into the middle of this discussion...
Another thing that really bothers me is the potential for malicious
'punishment':
This is an area that causes me concern as a developer implementing SPF
into our product. We have a history of allowing our customers to use a
variety of on-the-fly lookup techniques (IDENT and, later, various DNS
blocking lists) and while they may serve the purposes, they also tend to
introduce possible support issues when their MTA stops accepting mail
reasonably because of a problem elsewhere on the network.
Our customers want SPF support. I think that there is a lot of potential
that makes it worth implementing, but I can't get over this nagging
feeling in the back of my head that it opens up a customer to a new
variety of DoS attacks (both the mail recipient's MTA and any DNS
servers possibly referenced in SPF records) that will be harder to limit.
--Marc
Receivers always have the ultimate option to not check SPF. When we discuss
SPF processing limits, we are discussing the maximum processing that can be
required to get a valid SPF result. Something one might want to design into
a receiving program would be load shedding SPF checks if DNS load got too
high. This could be at any point, the key from an SPF perspective is that
if the receiver bails out before processing all the way to the specified
processing limits, then the receving MTA can't call the result a valid SPF
result.
Also, where in the process the SPF checks are done can have a very large
impact on performance. I think it was Hector Santos who suggested that
deferring SPF checks until after RCPT TO: checks would make sense. From my
limited experience I expect that is correct. In my experience more than 90%
of messages are failing because of an invalid RCPT TO: (YMMV), so doing SPF
after RCPT TO, but before data would substantially reduce the potential for
DNS loading from SPF.
Scott Kitterman