-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Frank Ellermann wrote:
Julian Mehnle wrote:
Why do you want to test _that_ case for crashes and not a million
other weird cases?
I don't know a million other weird cases, I know that one: At the
moment "oemcomputer" is no TLD under ICANN's root, unlike "museum",
"aero", "arpa", "travel", "asia", "mobi", "coop", etc. For a less
volatile test I'd replace "oemcomputer" by "invalid".
Now what does _that_ have to do with testing for crashes?
v=spf1 cannot be changed retroactively like this.
Implementations have to do something with an invalid <target-name>,
"ignore, no match, move on" is another possibility.
In RFC 4408, there is no such thing as an "invalid <target-name>". It says
that <t-n> "is an FQDN", but it doesn't say anything else, in particular
it doesn't say what should happen if <t-n> isn't an FQDN.
Sure "implementations have to do something". But that doesn't mean that it
_has_ to be specified at all costs. And the cost of rendering certain
implementations incompliant because they chose to do something other than
what _you_ want to specify retroactively, is simply too high.
There's yet no problem statement for your case,
It's not _my_ case. Whose is it really?
It's a Wiki, it has an edit history, and whoever added it likely
tried to track one of those convoluted test suite threads. If it's
bogus we can throw it out.
I suggest that whoever added it either explain whose idea it was, adopt the
idea as their own, or remove it from the proposed errata list.
confused developers aren't a good enough justification for
specifying _new_ behavior in v=spf1. Unspecifiedness is a bug
only when it harms interoperability. Is this the case here?
If some implementations can handle a:%{h} for an existing A record
for say "museum", others treat it as "ignore, no match, move on",
and some throw PermError, then it obviously harms interoperability.
Note that this is a very cornery corner case. It happens only if <helo> is
in some way "not an FQDN" (as the spec says), and then what's the problem
with some implementations making a (potentially bogus) TLD query (which is
likely to fail), some mismatching the mechanism, and some throwing
PermError? The only real type of case I can see is the "legit TLD used as
host or MX domain name" one, and as far as I can see, no TLD actually does
it.
Besides, throwing PermError in this case is hardly justifiable from what
the spec says.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGBu14wL7PKlBZWjsRAt+aAKCNnKKGiXdIlSIv03jEv97V2rtL3wCgjZAd
ubZo9GVcmaO+sCAHcuR8l4U=
=sIsE
-----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