In <20050519024514(_dot_)7EC1F54FE8(_at_)apex(_dot_)listbox(_dot_)com> Scott
Kitterman <spf2(_at_)kitterman(_dot_)com> writes:
23:35 <grumpy> all previous SPF specs say that you don't reject on
PermError (aka unknown)
23:35 <grumpy> and Scott was very concerned about the new language
23:36 <MarkK> yes, ever since we switched from 'unknown' to PermError
23:36 <Julian> I agree that we shouldn't prescribe receiver policy, but I
think most receivers will reject on "PermError". I don't think that Scott's
opinion is very representative.
(No offense, Scott.)
None taken. Most people aren't responding to submissions to spf.pobox.com
and on spf-help from people complaining about how come I rejected their
e-mail. This change is going to make it worse.
BTW, I don't think anyone is rejecting on PermError now. I've yet to see a
reject because of this and I've seen lots and lots of messed up records.
Bottom line: I don't think making a mistake with an SPF record should make
mail less likely to be delivered than having no SPF record at all. It's
going to hurt adoption.
I would just like to say that I trust Scott's analysis that the current
deployment of SPF implementations do not, generally, reject on
PermError.
All previous specs, dating back to Nov 2003, say things along the
lines of:
Unknown: indicates incomplete processing: an MTA MUST proceed as
if a domain did not publish SPF data.
For me, this makes the issue clear. I think we *MUST* document what
SPF is, not what we think it should be.
The "SHOULD reject on PermError" is a creation from the MARID process.
While may are arguing that it is the right thing to do, I am more and
more convinced that it is a very wrong thing to do.
Given that all specs say PermError MUST be treated as None, the only
thing that would convince me to change this would be strong evidence
that existing implementations don't treat PermError as None.
-wayne