-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Frank Ellermann wrote:
Stuart D. Gathman wrote:
I am now even more commited to the interpretation that museum needs
a trailing dot to be a FQDN.
Won't fly, we get into the same trouble with a:%{l} for a local part
"museum" (without dot, but actually it doesn't matter). There are
also SPF constructs to select a single label out of several labels,
and eventually you've to check if it (whatever it is) has an address.
- From a theoretical PoV, in a context that doesn't allow local name inter-
pretations (e.g. SPF records), "museum" -- with or without a trailing dot
- -- is an FQDN. No questions about it.
- From a practical PoV, SPFv1 doesn't support it, and this isn't something we
can fix with minor tweaks to the v=spf1 grammar.
There's also the issue of erroneous DNS queries to the root servers. We
don't want "OEMCOMPUTER" or the value of %{l} to be verified as a TLD,
effectively spamming the root servers. However, there's no conceptually
consistent way to distinguish "OEMCOMPUTER" from "museum" (without a
trailing dot).
Ergo, for SPFv3 a more sophisticated approach is needed:
* A literal "a:museum" mechanism (with or without a trailing dot) should
be allowed, as should "a:%{h}" with <helo> = "museum." (with a trailing
dot).
* On the other hand, <helo> = "museum" (without a trailing dot) should be
an input validation error, as should <sender-domain> = "museum"
(without a trailing dot), or, for that matter, <helo> = "1.2.3.4",
<helo> = "[1.2.3.4]", and <sender-domain> = "42".
* Input identity domains (<helo>, <sender-domain>) should get normalized
in a consistent way before policy processing (but after TLD valida-
tion), probably by stripping trailing dots and lower-casing them (so
expansion of "%{h}.%{h}" or "%{h}%{h}" is predictable).
The only place to fix this would be the definition of <target-name>,
we could demand that it must have a trailing dot if it has only one
label, independent of the used macro(s), %{h}, %{l}, or what else.
<target-name> isn't an element of the v=spf1 grammar. It's a semantic
variable.
It seems obvious to me (now) that in RFC 4408 we should have differentiated
between syntactic validation (which is omnipresent in RFC 4408) and
semantic validation (which is almost completely absent). However, again,
this isn't something we can fix in v=spf1.
SPFv3 should do both syntactic and semantic validation, the latter
specifically including input value validation (see above) as well as the
validation of macro string expansion results (against the context in which
the macro string was used, i.e. requiring FQDN characteristics, etc.).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGBb/qwL7PKlBZWjsRAqE7AKD/K5TOYwz/L4Au8uE6Dv4w5d14eACfYM2T
P0ten3DUZJHc5JkMJdOz30Y=
=tWMa
-----END PGP SIGNATURE-----
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735