Re: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14

[Douglas Otis <[e-mail]>]

On May 28, 2013, at 2:15 PM, Murray S. Kucherawy <[e-mail]> wrote:

> On Tue, May 28, 2013 at 1:16 PM, S Moonesamy <[e-mail]> wrote:
> Douglas Otis submitted draft-otis-spfbis-macros-nixed-00 [1] as WGLC comments about draft-ietf-spfbis-4408bis-14.  Could the SPFBIS WG please read the draft-otis-spfbis-macros-nixed-00 and comment about it?
> 
> 
> I have reviewed the draft, as requested.  My responses:
> 
> Nixing macros based on non-use has already been debated at length, to the point of a low-level appeal, and it's been decided that they're staying.  There's no action for the WG here based on that argument.

Dear Murray,

A pertinent point regarding the decision that receivers must process macros is whether it represents a reasonable demand.  SPF records containing macros can not cache results and will always necessitate reprocessing.  If macro processing is skipped, any expectation of preserving interchange is lost.  In other words, it is broken by design by asking too much from receivers.
   
> Beyond that, I disagree that macros "diminish" SPF's utility in any way; their mere presence in the protocol doesn't render it less useful, as one may simply not use them and still get useful results.

When the main purported use is to determine a domain's outbound IP addresses, macros preclude this prevalent use offering the greatest utility, bar none.

> I would argue that DMARC, which makes use of SPF in a specific way, should not influence SPF itself at this point as DMARC has no particular status with the IETF yet.

DMARC does not differ in how many hoped to make use of SPF.  Desired use is very much at odds with stated SPF processing which is likely to require subsequent reprocessing, with increased burdens and layer violations.   

> The dropping of type 99 RRTYPE support was made for more reasons than just "sparse use", so I don't find that part of Doug's arguments compelling.  I think we reached consensus on that debate long ago, and it's been beaten to death recently once again on the main IETF list.

Mark Andrews made good points about increasing use of SPF 99 not shown in your survey.  The general goal should be to ensure unknown RR types are accommodated.  Unfortunately, some vendors still don't.

> The local-part macro attack has been discussed to death.  There's no new information presented here that I can see.
> 
> Saying RFC6686 "failed to provide a breakdown on macro use" is to imply that it should have.  Analysis of macro use was not part of the goal set of that document, so it's strange to identify this as a failure.  However, I still have those data available should there be some demonstrated purpose for mining the data further.  Or, Doug can do his own survey and see what he finds.

IMHO, it was wrong (a failing) to limit a review of SPF to answer only whether the PRA mode was being used.  This review should have also focused on both macro publication and macro processing.  Whether it is local-part macro or any other macro, cached results are not useful and much of the SPF utility for defining a domain's outbound address space is lost.  Since there is only 0.053% of domains using macros, it becomes an easy trade-off some providers make.  They even have stated ignoring SPF records containing macros do not result in complaints.

> The document mentions use of macros given the advent of EAI, but I believe the current spfbis document already deals with this in the same way DKIM did.  Someone more expert in EAI than I am might want to confirm we've done our due diligence there.

It can no longer be assumed domains will be encoded as A-labels. In addition, it can not be assumed the local-part will be ASCII.  Such changes can place spf libraries at risk.  In a quick review, it seems some unused features in the libraries might permit induced buffer overruns.  Adding in additional conversion libraries introduces more risk which might compromise SMTP servers.  Nothing justifies these types of risks to support something that is practically unused.  

> Overall, I don't think this draft introduces any new material such that the WG needs to revisit anything since WGLC closed.

The macros nixed draft was just updated to better clarify these concerns.

http://tools.ietf.org/html/draft-otis-spfbis-macros-nixed-01

Regards,
Douglas Otis