Subject: [spfbis] RFC 4408 Test Ambiguities

From: Scott Kitterman <[email-masked]>
Date: Thu, 21 Jun 2012 18:12:18 -0400

As part of my preparations for uploading the initial WG draft of 4408bis, I'm 
reviewing the SPF test suite for documented ambiguities that need fixing (See 
http://tools.ietf.org/wg/spfbis/trac/ticket/5).  
Here's one I've come up with that I don't know the correct solution for that I 
think should be discussed:

invalid-domain-empty-label:
    description: >-
      target-name that is a valid domain-spec per RFC 4408 but an invalid
      domain name per RFC 1035 (empty label) must be treated as non-existent.
    comment: >-
      An empty domain label, i.e. two successive dots, in a mechanism
      target-name is valid domain-spec syntax, even though a DNS query cannot
      be composed from it.  The spec being unclear about it, this could either
      be considered a syntax error, or, by analogy to 4.3/1 and 5/10/3, the
      mechanism chould be treated as a no-match.
    spec: [4.3/1, 5/10/3]
    helo: mail.example.com
    host: 1.2.3.4
    mailfrom: [email-masked]
    result: [permerror, fail]

The question is, should ".." be an error or an oddity that will never match 
anything because you can't actually query for it.  I lean towards the former, 
but I think picking one matters more than which one we pick.

invalid-domain-long-via-macro:
    description: >-
      target-name that is a valid domain-spec per RFC 4408 but an invalid
      domain name per RFC 1035 (long label) must be treated as non-existent.
    comment: >-
      A domain label longer than 63 characters that results from macro
      expansion in a mechanism target-name is valid domain-spec syntax (and is
      not even subject to syntax checking after macro expansion), even though
      a DNS query cannot be composed from it.  The spec being unclear about
      it, this could either be considered a syntax error, or, by analogy to
      4.3/1 and 5/10/3, the mechanism chould be treated as a no-match.
    spec: [4.3/1, 5/10/3]
    helo: "%%%%%%%%%%%%%%%%%%%%%%"
    host: 1.2.3.4
    mailfrom: [email-masked]
    result: [permerror,fail]

This is very simlar (too long versus non-existant).  Once again, I think 
picking one is the most important thing.

Scott K

---

From: Commerco WebMaster <[email-masked]>
Date: Thu, 21 Jun 2012 19:36:48 -0600

Scott,

Does it make sense to perhaps simplify even further?  It might suffice 
to simply say that if a domain name cannot be resolved because it is 
invalid per RFC 1035, it MUST be considered an error by those who 
implement SPFBIS.

It kind of leaves little to the imagination, which in this case is 
probably a good thing.

Best,

Alan M

On 6/21/2012 4:12 PM, Scott Kitterman wrote:
>      description:>-
>      comment:>-
>      description:>-
>      comment:>-
> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis
>
>

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 22 Jun 2012 11:08:58 +0200

> It kind of leaves little to the imagination, which in this case is

That makes sense because --when adequate provisions will be in place--
it will be possible to report that as an error, which it is, to the
relevant admin.  Given the high number of permerrors, such kind of
action is desirable, IMHO.

Perhaps +all is also an error, in most of the few places where it
appears, e.g. bluecross.ca.  However, since it is exemplified in the
text, it cannot be an error.  Will we have warnings for such cases?

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 22 Jun 2012 10:39:15 -0400

> text, it cannot be an error.  Will we have warnings for such cases?

The protocol can't be a mind reader.  If a domain owner wants to authorize 
every MTA on the planet to sent mail from their domain, then there's not a lot 
we can do about it.  -1 on warnings being defined in the protocol.

There are ways to make a record that acts like +all, but doesn't appear so 
based on casual inspection, so identifying these cases in non-trivial.

It would be useful in testing tools perhaps to provide such warnings, but 
there's no scope for it in the protocol definition.

Scott K

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 22 Jun 2012 11:02:11 -0400

Hi,

No hat.

>       domain name per RFC 1035 (empty label) must be treated as non-existent.

The problem with this (and the other) case is, surely, that
"domain-spec" doesn't actually constrain things such that only valid
DNS names pass it, right?  (It doesn't permit all valid DNS names,
either, but I guess that's on purpose.)  Wouldn't it be better to fix
domainspec so that there would necessarily never be a name that met
the test, but that isn't actually a valid DNS name anyway?

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 24 Jun 2012 00:25:53 -0400

On Thursday, June 21, 2012 06:12:18 PM Scott Kitterman wrote:
> As part of my preparations for uploading the initial WG draft of 4408bis,
> I'm reviewing the SPF test suite for documented ambiguities that need
> fixing (See http://tools.ietf.org/wg/spfbis/trac/ticket/5).
> Here's one I've come up with that I don't know the correct solution for that
> I think should be discussed:
> 
>       domain name per RFC 1035 (empty label) must be treated as
> non-existent. comment: >-
>       target-name is valid domain-spec syntax, even though a DNS query
> cannot be composed from it.  The spec being unclear about it, this could
> either be considered a syntax error, or, by analogy to 4.3/1 and 5/10/3,
> the mechanism chould be treated as a no-match.
>     spec: [4.3/1, 5/10/3]
>     helo: mail.example.com
>     host: 1.2.3.4
> anything because you can't actually query for it.  I lean towards the
> former, but I think picking one matters more than which one we pick.
> 
>       expansion in a mechanism target-name is valid domain-spec syntax (and
> is not even subject to syntax checking after macro expansion), even though
> a DNS query cannot be composed from it.  The spec being unclear about it,
> this could either be considered a syntax error, or, by analogy to 4.3/1 and
> 5/10/3, the mechanism chould be treated as a no-match. spec: [4.3/1,
> 5/10/3]

I'm continuing my way through things towards posting a draft.  The above is 
tracked as http://trac.tools.ietf.org/wg/spfbis/trac/ticket/22 and it has some 
suggested language.

Scott K