Subject: How fragile is SPF ?

From: John Levine <[email-masked]>
Date: 30 Jun 2004 02:35:05 -0000

I set up SPF for one of my subdomains to stress test systems that
check SPF on incoming mail.  (You know, running code to go with the
rough consensus.)  You can try them yourself on any subdomain of
slow.sp.am, e.g. yourname.slow.sp.am.  The extra level of name makes
it easier for me to tell from the DNS server logs what the sequence of
requests for each message is, of someone's wondering what his system
asked as it did the checks.

I believe all of the SPF records are syntactically and semantically
valid, and they're all well within both the limits of the SPF spec and
the implementation limits in the perl reference code.  They do nested
includes 10 deep and do a few MX lookups, and correctly list the hosts
from which <whatever>.slow,sp.am mail might be sent.  Responses fit in
512 byte UDP DNS packets unless you use a really long subdomain name.

If you'd be willing to see how your SPF implementation does, either
tell it to check any subdomain of slow.sp.am, or I can send you mail
and see how your MTA deals with it and you can write back, since the
addresses are real.  The SPF checks are likely to take an hour or more
per message, even though everything is well within the 15 second
timeout that the reference SPF code enforces.

The point of this is that we all expect bad guys to publish hostile
MARID records, so we might as well find out now how much trouble
that's going to cause.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
http://www.taugh.com

---

From: wayne <[email-masked]>
Date: Tue, 29 Jun 2004 23:32:10 -0500

In <[email-masked]> John Levine <[email-masked]> writes:

> rough consensus.)  [...]

It comes as little surprise to me that the Chair of the IETF Anti-Spam
*RESEARCH* Group has actually done research.  Thank you!  It has been
kind of lonely being one of the few to dig up stats.

> addresses are real.

As I mentioned in an earlier (private) email to you, my development
version of my SPF implementation has a overall timelimit on an SPF
execution.  While your very slow NS is by design, in practice, I think
we will run into equally slow NS by neglect.

The Caller-ID spec has a codified time limit.  My suggestion to Meng
to add one to the SPF spec got dropped.  I think it needs one really
needs to be added.

> timeout that the reference SPF code enforces.

My libspf2 (aka libspf-alt) implmentation runs into other processing
restrictions after a couple of minutes.  This is still too long.

---

From: Meng Weng Wong <[email-masked]>
Date: Wed, 30 Jun 2004 02:43:33 -0400

On Tue, Jun 29, 2004 at 11:32:10PM -0500, wayne wrote:
| 
| The Caller-ID spec has a codified time limit.  My suggestion to Meng
| to add one to the SPF spec got dropped.  I think it needs one really
| needs to be added.
| 

OK, how about:

  If an SPF evaluation fails to resolve an answer within 20
  seconds, processing SHOULD abort and return the "error"
  result.