Re: Last pending wannabe erratum: Invalid <target-name>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Frank Ellermann wrote:
> with 2821bis in Last Call I removed "<target-name> is a valid TLD"
> as potential erratum, if 2821bis permits it we'll follow suite.
>
> Syntactically SPF policies can't talk directly about this case,
> a <domain-spec> ends with a dot-separated <toplabel>, plus the
> optional trailing dot (that's certainly no 2821bis construct ;-)
>
> IOW we can't have "v=spf1 a:museum" or similar, this won't kill
> e-mail.  I think that deserves two test cases in the test suite:
>
> 1 - "v=spf1 a:museum" is a PERMERROR (missing dot)

Not sure whether this is already being implicitly tested by some other
test in the test suite.  If not, this would do it:

  tests:
    a-only-top-label:
      description: >-
        Domain-spec may not consist of only a top-label without a leading dot.
      spec: 8.1/2
      helo: mail.example.com
      host: 1.2.3.4
      mailfrom: [email protected]
      result: permerror
  zonedata:
    e5a.example.com:
      - SPF: v=spf1 a:museum

... probably to be inserted in the "A mechanism syntax" scenario.

> 2 - "v=spf1 -a:%{h} all" for h=museum or similar should be PASS,
>     if the address doesn't exist or at least doesn't match.  I
>     forgot how the test suite arranges this.  Maybe these tests
>     already exist.

This one is already covered by the "require-valid-helo" test.

> We could note that future SPF versions (4408bis or otherwise)
> need a syntax where "v=spf1 a:museum" is no syntax error, but
> IMO that's no 4408 erratum, it wasn't predictable that 2821bis
> changes the rules.

Pardon my ignorance, but how does 2821bis change the rules with regard to
this?

> -----------------------------------------------------------------
> The last pending erratum:  What do real implementations if the
> <target-name> has a form unsuited for DNS queries, e.g. adjacent
> dots ?  Just ignore the <target-name> as "no match" ?

- From a design theoretical PoV, that should be a PermError because it won't
go away on retrying.  However, since RFC 4408 does not specify behavior in
this case, there's little point in retroactively codifying observed
behavior in the spec or in an erratum.

As for real implementation behavior, Mail::SPF currently treats
"a:foo..bar" as a simple mismatch.

> For the test suite:  With "v=spf1 exists:%{l}.%{d}" and mail from
> "ugly..dots"@valid.domain.test what are implementations supposed
> to do ?  A dot (like any other octet) is permitted in a label, of
> course that's no host name, and it might be tricky to construct
> a DNS query, but maybe "ugly\.\.dots.valid.domain.test" works.

Following RFC 4408, behavior would have to be the same as for a literal
"exists:ugly..dots.valid.domain.test".

I have thought about defining (in a new specification -- SPFv3, 4408bis,
whatever) macro expansion to treat any expanded macro as an atomic and
opaque value when constructing a <target-name>, which would enable
"ugly..dots" to be considered as a domain label of its own in "%{l}.%{d}".
That, however, would break "%{ir}._spf.%{d}" and similar cases.

> It's not as esoteric as you might think, for UTF8SMTP local parts
> can contain "raw" UTF-8 octets.

We can support that in our next spec easily simply by allowing 8-bit bytes
in SPF records and defining that localparts have to be encoded as UTF-8
before %{l} expansion (handling of other non-ASCII input data can be
defined analogously).

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHVCXdwL7PKlBZWjsRAvsCAJsEVsFmaNCOgtCeaL0HRecf88OLTACfa1qO
7IJfuKGvLiSsEnmyXdXvr4c=
=XQgx
-----END PGP SIGNATURE-----

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/1007/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/1007/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=6959932&id_secret=71464379-325788
Powered by Listbox: http://www.listbox.com