Julian Mehnle wrote:
This might also be a useful feature for SPFv3.
Sure, anything with a new tag can specify whatever it likes.
Otherwise, recommending that receivers throw a PermError when hitting
limits that are lower than what RFC 4408 explicitly specifies is highly
problematic.
Indeed, it is. But if we can determine new limits not used in the wild
(outside of attack scenarios) we're free to add them below the already
existing SHOULD in a 4408bis (or maybe in the 4408 errata).
Maybe as TempError, Wayne's idea was NONE for this SHOULD, your and my
idea was TempError, but ideally it's of course a PermError. If it does
not break "too many" published policies. Where something below 10ppm
might be acceptable if it's really important against attacks.
After all the status is "experimental", it won't be upgraded to "PS"
with precisely the same text as is, e.g. we'll fix the errata, maybe
we publish some interop reports based on the test suite in a separate
document, maybe some "lessons learned" in a third document, the works.
And we can propose a 4408bis whenever we feel like it (e.g. after some
months without changes in the errata), we're not forced to wait until
2008 - that's not our timer, it's a timer of a former IESG.
BTW, there are even folks who are not shy to add dubious dots to a spec.
for in essence aesthetical reasons, while the author of RFC 2821 and
the author of RFC 2045 agree to remove that dot from an 2821bis draft,
because it's not backwards compatible wrt SMTP. In presence of an SPF
Council member (hi William) on the SMTP list.
The processing limits aren't "nice to have", they're really important.
I don't propose to break numerous published policies, that's why I was
against the SenderID "compatibility" clause, or the hopefully harmless
trailing dot (as long as nobody uses it it's definitely harmless, and
those who try it are free to change their mind if they get PermErrors).
But fixing bugs and security considerations if necessary is on another
level, IMO that's why they (IETF) have this "standards process" with
several steps.
Frank
-------
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