Scott Kitterman wrote:
Somehow I started one subthread too many, sorry, I'm trying to
join that, Julian said:
>> A "processing limit exceeded" PermError isn't bogus, though.
We could have said so, we didn't. It's a similar case as say
"v=spf1 a a a a a a a a all". Really weird, but no PermError.
> The fundamental difference, IMO, is that all the explicit
> PermError cases are about errors/limits within the SPF
> record.
No, don't give us more credits than we deserve. An NXDOMAIN
for include or redirect= is also a PermError, a compromise
we arrived at after a couple of "for SPF Council review" in
the time when that convention for appeals worked.
> I suppose if we still called PermError Unknown, I might be
> more likely to agree with you, but I lost that point and
> have moved on.
Another compromise, I "won" a point about specifying the SMTP
error code (if rejected) as in spf-00, but the sneaky editor
interpreted that as "delete it anyway" ;-)
It deteriorated with the AUTH48 introduction of trailing dots.
Before we start 4408bis adventures we need a better appeal
procedure. Brian proposed something for the IETF, they're
also not really happy with their procedure as is.
> The more I think about this, the more I think the RFC is
> correct and silently not matching is the best out of a
> selection of poor choices.
IBTD, Julian's view makes more sense, but we can't simply
reintrepret the RFC. I hope that "more than 10 MX" is in
practice about as relevant as the "trailing dot".
Not that the test suite is mere theory, it's not, we need
the results for the "implementation and interoperability"
report, for my first (mainly for training) example compare
http://purl.net/xyzzy/home/test/cram.xml
http://www.ietf.org/IESG/Implementations/CRAM-MD5_implem.txt
Frank
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com
Somehow I started one subthread too many, sorry, I'm trying to
join that, Julian said:
>> A "processing limit exceeded" PermError isn't bogus, though.
We could have said so, we didn't. It's a similar case as say
"v=spf1 a a a a a a a a all". Really weird, but no PermError.
> The fundamental difference, IMO, is that all the explicit
> PermError cases are about errors/limits within the SPF
> record.
No, don't give us more credits than we deserve. An NXDOMAIN
for include or redirect= is also a PermError, a compromise
we arrived at after a couple of "for SPF Council review" in
the time when that convention for appeals worked.
> I suppose if we still called PermError Unknown, I might be
> more likely to agree with you, but I lost that point and
> have moved on.
Another compromise, I "won" a point about specifying the SMTP
error code (if rejected) as in spf-00, but the sneaky editor
interpreted that as "delete it anyway" ;-)
It deteriorated with the AUTH48 introduction of trailing dots.
Before we start 4408bis adventures we need a better appeal
procedure. Brian proposed something for the IETF, they're
also not really happy with their procedure as is.
> The more I think about this, the more I think the RFC is
> correct and silently not matching is the best out of a
> selection of poor choices.
IBTD, Julian's view makes more sense, but we can't simply
reintrepret the RFC. I hope that "more than 10 MX" is in
practice about as relevant as the "trailing dot".
Not that the test suite is mere theory, it's not, we need
the results for the "implementation and interoperability"
report, for my first (mainly for training) example compare
http://purl.net/xyzzy/home/test/cram.xml
http://www.ietf.org/IESG/Implementations/CRAM-MD5_implem.txt
Frank
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com