ietf-mxcomp
[Top] [All Lists]

Re: How fragile is SPF ?

2004-06-29 21:32:14

In <20040630023505(_dot_)28233(_dot_)qmail(_at_)xuxa(_dot_)iecc(_dot_)com> John 
Levine <johnl(_at_)iecc(_dot_)com> writes:

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

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.


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.

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.


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.

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



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