Subject: [spfbis] Opinon on macros

From: Scott Kitterman <[email-masked]>
Date: Thu, 19 Jul 2012 15:38:12 -0400

I was asked offlist what my opinion on macros was and since I took the time to 
write, it, I thought it was better to be transparent and send it (this is 
actually very slightly changed, since I realized one thing I wrote before 
wasn't quite accurate) to the list too.  This is not meant to spark a lot of 
debate (I expect I'll be sadly disappointed about that, please surprise me).  
What's below is my opinion.  It may be wrong, but it is my opinion, so just 
telling me it's wrong isn't worth your time to write it or my time to read it.  
I'm certainly open to new facts or ones I've missed, but repetition won't help 
the ones already on the table.

Scott K

My understanding of the charter leads me to believe that it is a strong goal 
for the WG that organizations that have published SPF records or SPF checking 
software based on RFC 4408 will not HAVE to do anything to interoperate with 
records and checking software based on 4408bis.  I think it's not at all a 
problem if there are some things they SHOULD do eventually, as long as there 
are no MUST do's.  I think the design goal is 100%.

In order to override that goal, it has to be shown that the existing RFC 4408 
design is broken and that the only reasonable method of repair will require 
some change.  

So far (and I'm always open to new data) the only issue that, in my opinion, 
has risen to that level is the Type TXT versus Type SPF issue.  There isn't ay 
100% backward compatible way to solve that issue.  Since we established that 
the very few domains that published Type SPF only records were already 
experiencing a poor level of interoperation, I think it was quite reasonable 
for the WG to conclude as it did.

Macros are different.  There are some potential risks in the RFC 4408 design, 
but the design is not fundamentally defective (I admit to it being complex, 
but not more so than it needs to be if SPF is going to have macros).  They 
also support at least one very important use case (the DNS logging SPF record 
listed in section 9.1) that is does not yet have a well deployed alternative 
(RFC 6652 or DMARC could replace this in the future, but not today).  They can 
also be useful in exp= modifiers to help return a more specific result.  As a 
result of the lack of clear defects and the legitimate use cases that don't 
have good alternatives, I think removal is not appropriate.

I have no strong objection to deprecation (I don't agree it's necessary, but I 
don't think it's unreasonable).  If we can make a good push for deployment of 
6652 as a deployment validation mechanism and/or DMARC gets standardized as an 
appropriate solution for SPF feedback/validation (the currently published spec 
is not) and we give users time to migrate to different approaches, I think it 
will be appropriate to consider removal, particularly of local-part, in the 
future.