-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hector Santos wrote:
IMO, an implementation can choose to do things differently as long if
the end result is not different.
But that's exactly the point. By ignoring the safety limit and NOT
throwing PermError, the results ARE different.
The problem here is an artificial limit of 10. Why 10?
What specific value would you have preferred?
Was there a DNS scientific study done that shows 10 is where critical
bandwidth issues begin?
I'm interested in your thoughts about a possibly methodology for that. It
might be useful for another version of SPF.
All this does is provide bashing feed to nay-sayers and the IETF people.
The processing limit was introduced, among other reasons, to appease the
IETF critics who said that SPF was open to DoS attacks. I agree that the
value of 10 is arbitrary, but honestly I don't see any empirical
methodology to determine a "good" value.
[...] make [the limit] more based on redundancy and cache tracking. Not
Lookup Mechanisms.
I still don't understand what you mean by "based on redundancy and cache
tracking".
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQFEXcNYwL7PKlBZWjsRAmyQAJ9AsfC80VyFiRP8KhgjiCe7pK7cwQCggmWT
zgyj4GsenqEe9QmeGGi6M9s=
=qDJ5
-----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