[opendmarc-dev] OpenDMARC 1.3.0 Beta0 available

[bcx+spam at bcx.com]

Scott,

If you don't include those configuration items in the default file, then nobody will
know they are available. Adding a build option to prevent the inclusion of the code
is not trivial and will be included in the configuration option to use libspf2.

In the meanwhile, please see the tests in opendmarc-code/libopendmarc/tests/test_spf.c
and suggest tests that may be missing that could shed light on parsing failures. This would
help bullet proof the code to a degree you might find acceptable.

Best Regards,
--Bryan Costales

  >------------
  > Quoting Scott Kitterman <sklist at kitterman.com>
  > Subject: Re: [opendmarc-dev] OpenDMARC 1.3.0 Beta0 available
  >------------
  > On May 27, 2014 11:44:57 AM EDT, bcx+opendmarc at bcx.com wrote:
  > >Scott,
  > >
  > >The spf code is only used if configured by you to do so. It is off by
  > >default.
  > >Hooks to use libspf2 will be in the next release.
  > >
  > >Best Regards,
  > >--Bryan Costales
  > >
  > >  >------------
  > >  > Quoting Scott Kitterman <sklist at kitterman.com>
  > >  > Subject: Re: [opendmarc-dev] OpenDMARC 1.3.0 Beta0 available
  > >  >------------
  > >  > On Monday, April 28, 2014 09:50:55 Murray S. Kucherawy wrote:
  > >  > > On Sat, 26 Apr 2014, Andreas Schulze wrote:
  > >  > > > do you now re-implement SPF-checks from stretch in OpenDMARC?
  > >  > > 
  > >> > Bryan added the feature, so I'll Cc him here to explain it in
  > >detail.  The
  > >> > documentation is there though, and basically says you can have
  > >opendmarc
  > >> > do its own SPF checks either always, or when the SPF check results
  > >were
  > > > > not done upstream and recorded in the header in the expected ways.
  > >  > 
  > >> Sorry it's taken me so long to look at the code, but even though it's
  > >late, 
  > >> I'm going to jump in and recommend not including the SPF code in the
  > >final 
  > >> release.  In RFC 4408 and even more so in RFC 7208 we were really
  > >careful 
  > >> about processing limits to mitigate the possibility of denial of
  > >service 
  > >  > attacks.
  > >  > 
  > >> As nearly as I can determine, the SPF code you've included implements
  > >none of 
  > >> those checks.  It uses a recursion depth limit model that was common
  > >in very 
  > >> early SPF implementations such as Mail::SPF::Query and libspf0 (pyspf
  > >
  > >> originally did this, but later implemented the RFC 4408 and now RFC
  > >7208 
  > >  > checks), but not in modern open source implementations.
  > >  > 
  > >  > I don't think it's use is suitable for today's internet.
  > >  > 
  > >> If you decide not to remove it, at the very least, please provide a
  > >configure 
  > >  > option to disable it.
  > >  > 
  > >  > Scott K
  > >  > _______________________________________________
  > >  > opendmarc-dev mailing list
  > >  > opendmarc-dev at trusteddomain.org
  > >  > http://www.trusteddomain.org/mailman/listinfo/opendmarc-dev
  > 
  > That's a run time option (as far as I can tell).  I was asking for a build time configure option.   As it is, I'm likely to skip 1.3 for Debian and by extension Ubuntu and wait for the next version unless I can compile support for this out.
  > 
  > Scott K
  > _______________________________________________
  > opendmarc-dev mailing list
  > opendmarc-dev at trusteddomain.org
  > http://www.trusteddomain.org/mailman/listinfo/opendmarc-dev