On May 3, 2013, at 1:00 PM, Scott Kitterman <sc...@kitterman.com> wrote:
> On Friday, May 03, 2013 12:46:52 PM Douglas Otis wrote: >> On May 3, 2013, at 12:21 PM, Scott Kitterman <sc...@kitterman.com> wrote: >>> On Friday, May 03, 2013 12:04:53 PM Douglas Otis wrote: >>> ... >>> >>>> Over many years at attempting to change the course of the SPF process, >>>> this >>>> effort appears to have been futile. >>> >>> ... >>> >>> It does seem a bit odd for you to claim you're being ignored when the >>> largest change in SPF processing limits contained in 4408bis was your >>> suggestion. An alternate interpretation to consider is that the working >>> group fully considered your inputs and incorporated those that were >>> appropriate technically and in scope for the charter. >> >> Dear Scott, >> >> >> This was not directly part of the IETF process, as my input there was >> ignored. >> >> As I recall, removal of unlimited recursion occurred after a presentation >> made in Boston to the Open Group. > > I assume you are referring to some of the pre-IETF activities for SPF. > Recursion based processing limits don't appear in RFC 4408 (and also not in > 4408bis). > >> As with unlimited recursion, the need for the macro functions are also >> negligible while posing real risks. This is a serious security concern >> still needing to be addressed. > > This was discussed in the working group and tracked in the WG issue tracker: > > http://trac.tools.ietf.org/wg/spfbis/trac/ticket/24 > > The change mentioned in the ticket is a direct result of your input to spfbis > (referenced in the ticket). > > As far as I can tell, this is just a case of "the working group came to a > different conclusion, so I'll whine about it on the main list". Dear Scott, While the recommendation may have helped, there is a trend of large websites publishing synthetic domains as an alternative to web cookies. This overcomes the suggested fix. A similar issue applies to SPF reverse namespace macro expansion consuming connection resources, especially in regard to IPv6. In the end, the domain is still not authenticated, the number of transactions remain excessive and inhibit meaningful mitigation. Nothing justifies active content in DNS resource records distributed with email. Macros are not needed and seldom if ever are used in this regard. Simply put, SPF macros are not safe. DKIM as specified is not safe. Open IPv6 email can not be defended. The IETF needs to seek better and fairer remedies. Regards, Douglas Otis
