-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Alex van den Bogaerdt wrote:
On Sat, Mar 11, 2006 at 03:07:23AM +0000, Julian Mehnle wrote:
* Support both SPF (TYPE99) and TXT formats
Is this wise? IMHO a new version of SPF should only use SPF records,
not TXT records. Why do the extra work?
For backwards compatibility "v=spf1" records can also be found in TXT
record but only if no SPF (type99) record exists (v=spf2.1 or v=spf1).
* Binary (compressed) RR format?
Now would be a good time to decide wether or not to accept both
text and binary (or even mixed? think include...).
I currently would opt for binary only but I may easely change my mind.
Both the SPF/TXT and binary/text decisions strongly depend on whether the
tools for SPF and/or binary are available. This isn't necessarily a show
stopper, but having to maintain "TYPE99 \# 15 0e763d73706631206d78202d..."
in one's zone files is a maintenance nightmare. AFAIK, BIND doesn't so
far support the SPF RR type. (Hopefully that will change as soon as the
RFC is out.)
* Make "include:" more tolerant:
* Treat "include:domain-without-spf-record" as no-match instead
of error?
Unintended results will happen either way:
a) the included domain normally does have an SPF(TXT) record but due to
a mistake it does no longer have one
b) the included domain does not have such a record
If treated as "no-match" then case [a] is undesirable; the user probably
wants to know there's a problem.
If treated as "error" then case [b] is undesirable; the user doesn't
care enough to understand or investigate.
I think most errors will be type [b] but should ignorance win?
I disagree. This is not generally a matter of ignorance, but of how we
perceive SPF. IMO an "include:foo" means "apply the policy of domain foo,
then continue". If you view a domain policy not just as a concrete DNS RR
but as an abstract policy, then a missing DNS RR would also be a valid
(though empty) policy.
Besides, I don't think we should harden the border between "has SPF RR" and
"has no SPF RR" domains -- IOW, why should a domain not be allowed to
include another domain's policy in the anticipation that the include
target will publish an explicit domain in the near or not so near future?
And: case [a] can always be detected immediately, because "511 PermError:
SPF-less domain included" and "511 Fail" are likely to be treated identi-
cally by receivers.
* Tolerate circular inclusions
(a.org: include:b.org, b.org: include:a.org)
ugh... can we say can of worms?
Detecting circles is trivial, so what would the harm be?
Tolerating circular inclusions would be important in order for the more
abstract concept of domain policies to work (domains should be able to
mutually "trust" each other).
* Replace "~" qualifier by "testing" flag (op=testing) (so people
don't leave their testing records in "~all" state forever)?
Instead they will leave "op=testing" forever. IOW: what's the benefit?
That they're _aware_ that they're still in testing mode. Many don't know
that "~" is specifically meant for testing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFEErtRwL7PKlBZWjsRAjIuAKCY+kHsotaJNERlSOadkKTAlujqyACgzD9u
mReSsNm9U3YHx5qOwibuy68=
=KisD
-----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