[opendmarc-dev] OpenDMARC 1.3.0 Beta0 available

[bcx+opendmarc at bcx.com]

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