Subject: Re: [spfbis] #47: domain-spec

From: S Moonesamy <[email-masked]>
Date: Tue, 28 Aug 2012 22:47:01 -0700

At 18:27 26-08-2012, spfbis issue tracker wrote:
>#47: domain-spec
>
>  Message posted by Arthur Thisell on 26 Aug 2012:
>
>  Suggested text:
>
>  bis-06:
>     The domain-spec is expanded as per Section 8.  The resulting domain
>  name is used for a DNS A RR lookup.  If any A record is returned, this
>  mechanism matches.  The lookup type is A even when the connection type is
>  IPv6.
>
>  new:
>
>     The domain-spec is expanded as per Section 8.  The resulting domain
>  name is used for a DNS A RR lookup (even when the connection type is
>  IPv6). If any A record is returned, this mechanism matches, otherwise the
>  mechanism doesn't match.
>
>  or new:
>
>     The domain-spec is expanded as per Section 8.  The resulting domain
>  name is used for a DNS A RR lookup (even when the connection type is
>  IPv6). If any A record is returned, this mechanism matches.  In all other
>  cases (no A records, DNS error, etc.), the mechanism doesn't match.
>
>  http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html

Please review the above text.

Regards,
S. Moonesamy

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 29 Aug 2012 13:46:06 +0200

>>  IPv6). If any A record is returned, this mechanism matches,
>> otherwise the mechanism doesn't match.
>>
>>  or new:
>>
>> IPv6). If any A record is returned, this mechanism matches.  In all
>> other cases (no A records, DNS error, etc.), the mechanism doesn't match.
>>

my take:

  Note that the queried type MUST be A:  This mechanism doesn't work
  for sites returning TXT RRs, nor allows discrimination based on the
  returned value.  Only the returned RCODE is meaningful for the
  result, NOERROR yields a match and NXDOMAIN a non-match.  Other
  codes imply a DNS error and break the evaluation.

BTW, http://www.ietf.org/mail-archive/web/spfbis/current/msg01754.html
discusses SERVFAIL.  Is that the only DNS case, besides timeout, that
yields temperror?  Should Section 2.5.6 mention it?

The current I-D mentions SERVFAIL only in Appendix C, annotating the
option to turn repeated SERVFAIL into permerror.  Shouldn't such
criterion be applicable to "exists" mechanisms as well?

How about non-DNS errors, e.g. database unavailable and similar?

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 29 Aug 2012 23:38:20 -0400

> >  http://www.ietf.org/mail-archive/web/spfbis/current/msg02371.html

I think both these proposals change the meaning of the requirements in this 
paragraph.  Here's RFC 4408:

   The domain-spec is expanded as per Section 8.  The resulting domain
   name is used for a DNS A RR lookup.  If any A record is returned,
   this mechanism matches.  The lookup type is A even when the
   connection type is IPv6.

My understanding of the RFC 4408 design is that an error (temporary at the 
very least) could result from this lookup.  The propose text states that 
errors are ignored as no match.  I don't think there's been any foundational 
discussion for such a change in requirements and without a substantiating 
rationale we shouldn't change it.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 30 Aug 2012 00:04:16 -0400

On Wednesday, August 29, 2012 01:46:06 PM Alessandro Vesely wrote:
> >>  mechanism matches.  The lookup type is A even when the connection
> >> 
> >> type is
> >> 
> >>  IPv6.
> >>  
> >>  new:

This is addressed in the Record Lookup section.  I don't think we should 
repeat it.

> criterion be applicable to "exists" mechanisms as well?

Appendix C is not meant to be part of final 4408bis.  It's for our use to track 
what we've done.  I agree that exists should be subject to DNS errors causing 
a temperror.

> How about non-DNS errors, e.g. database unavailable and similar?

I don't think we've defined any non-DNS causes for temperrors.  If your system 
is unable to do SPF processing because it's broken in some manner, then it 
can't produce an SPF result.  It may choose to defer mail until it's fixed, but 
that's not part of the SPF protocol and I don't propose we add it now.

Scott K