Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE

[Hector Santos <[e-mail]>]

On 4/26/2013 9:02 AM, Scott Kitterman wrote:
>
> Since there wasn't the same screaming about DKIM, I wonder if this issue is
> really about the RR type at all or if it's really about the design decision on
> where to place the record?  It seems that SPF is not being penalized in some
> form for having gone to the trouble of getting the type assignment and giving
> it a go.
>

In my view, the DKIM decision was entirely based on the fact SPF was 
getting a huge traction and adoption as a TXT solution.  So why not for 
DKIM? It worked for SPF!

We should also note the mindset were among the same authors for 
protocols that are now entirely TXT:

    SPF    - 99/TXT, Levine against SPF, Murray wasn't around MARID
    DKIM   - TXT only, Murray authored
    VBR    - TXT only, Levine authored
    DMARK  - TXT only, and now a new I-D by Murray
    SPFBIS - TXT only, Murray started SPFBIS.

So we don't have too much "diversity" on the design.

SPF goal is still the same design goal for SPF type. The problem are the 
DNS servers. Getting Microsoft DNS servers to support unnamed RRTYPE 
processing at the very least will immediately change the course of the 
RRTYPE needs in the right direction.

Its a different problem in the same way AUTH-RES isn't ready for prime 
time with SPF - an errata is needed and people need to change their 
Received-SPF reporting.  In the mean time, in the name of across the 
board coding and single-sourcing, you support both even if the AUTH-RES 
support needs to be done with a kludge comment field.   Its the same 
with DMARC design pressures, it "works" better when MTA does the SPF 
processing at the 5322 Payload level (DATA state) or you accept the 
message then do the above tests and it may bounce or perhaps, hopefully 
not, discard:

             SPF FAIL POLICY === DKIM/ADSP DISCARD POLICY

Ideally, if we are going to stick with TXT based solutions and to better 
support integrated systems (ones that may support all of the above, it 
will be at least 4 DNS TXT queries), then we explore a direct solution 
of a single call to return all the sender information one may need 
about, including the message owner and copyright holder domain.

--
HLS