-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Scott Kitterman wrote:
First, why 2.1 and not 3? I think jumping entirely past version 2 makes
sense.
I'd like to avoid the impression of version number inflation. But I'm not
strongly opposed to v3. Depending on the final feature set, v2.1 may even
be inappropriate. But for now let's stick to v2.1 as a codename so we
don't have to go back from v3 to v2.1 when we discover that v2.1 isn't
very different from v2.0.
SPF needs to support those [other auth methods] or it will sooner or
later vanish into oblivion.
I'd say provide a linkage to those rather than support those (excepting
PRA - I think it's own limitations and DKIM doom it into oblivion). I
would also throw in SES and BATV and CSV for that matter.
As for PRA, I think we would have to support that in order to be able to
claim backwards compatibility to spf2.0. Besides, having PRA in the spec
(as a pointer to the PRA RFC) really doesn't do any harm. People who are
convinced of it will NOT stop using it just because SPFv2.1 no longer
supports it. And people who refuse to use PRA can just do whatever
SPFv2.1 will suggest for known-but-unsupported mechanisms when they
encounter "pra" (i.e. result in "Neutral", throw "PermError", skip it,
whatever).
As for SES and BATV, I don't think they can be considered to be sender auth
methods. They're really receiver-side-only local mechanisms. CSV however
is a candidate for support in SPFv2.1 IMO.
* "Unknown" vs. "unsupported" mechanisms, e.g. dkim might be de-
fined and known, but not locally supported (i.e. unevaluatable)
DNS-based registry of valid mechanisms/modifiers?
I think this will probably have to be an IANA kind of issue if we stay
within the IETF structure to manage this.
Probably true, but we (or some other stable entity) could always mirror the
state of an IANA registry in DNS.
* Make "include:" more tolerant:
* Treat "include:domain-without-spf-record" as no-match instead
of error?
This will negatively affect deliverability.
Will it? Sorry, I don't remember the old discussion on this issue, could
you please rehash the most important argument(s)?
I think a better question is to reopen the notion that a permerror should
be rejected.
Well, we're brain-storming anyway, so we're free to discuss even that.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFEEsG1wL7PKlBZWjsRApEJAJ9yVyVefQeN0Hs73o00dGh2/HGdhwCcC5TE
NiX4BE0eSXEzqNclGHPVDDI=
=ZrAA
-----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/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com