-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Frank Ellermann wrote:
Julian Mehnle wrote:
We could decree that it's invalid in chapter 4.8 for consistency with
the <domain-spec> construct always requiring more than one label (in
the absence of macros).
[...]
You didn't understand what I said. We cannot add this to v=spf1,
EVER.
Of course we can. In theory we can approve the damned erratum as is,
I think at the moment it reflects Stuart's appproach. On their way
from Proposed Standard to Full Standard specifications can do what you
see when comparing RFC 1738, 2396, and 3986 (a rather extreme case)
[...]
existing implementations would have to undergo significant changes
in order to remain compliant.
That's the purpose of a "proposed standard" (let alone "experiment"):
| Implementors should treat Proposed Standards as immature
| specifications. It is desirable to implement them in order to gain
| experience and to validate, test, and clarify the specification.
| However, since the content of Proposed Standards may be changed if
| problems are found or better solutions are identified, deploying
| implementations of such standards into a disruption-sensitive
| environment is not recommended.
Yes, there are differences between RFC 2026 theory (1996) and common
practice today, but they're nowhere near to your rigid assumptions.
And almost completely beside the point for an experimental RFC.
Yeah, and we could approve an erratum specifying that v=spf1 be applicable
for PRA checks.
Of course it would break most v=spf1 records. But maybe we suddenly
stopped caring about that? After all, RFC 4408 is just of "experimental"
status, right?
include_subdomains=yes
For the record: this concept is useless. In order to make this work, all
existing v=spf1 implementations would have to start doing the zone cut
search, and then 99.999% of all zone cut searches would turn out as
pointless (because practically no domain uses that proposed modifier).
I can see reconsidering the zone cut search for v=spf3, though.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGBvEHwL7PKlBZWjsRAtXnAKCiPhOievFedpkr8d80FsFhLxMrWQCdGHyL
PcAiWM7lzjAQ1nf2vNvx7pc=
=EaUY
-----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