On Sat, May 21, 2005 at 09:21:57PM -0500, wayne wrote:
I am getting really nervous about some of the stuff with NXDOMAIN and
PermError.
I can completely understand a Receiver Policy that rejects email when
the MAIL FROM is NXDOMAIN. Rejecting email on the HELO domain being
invalid doesn't seem as wise to me.
Both are outside the SPF scope.
However, it looks like what people are trying to do is have NXDOMAIN
be a PermError and PermError causing the rejection. This is really
bad since it makes a Receiver Policy into a claimed Sender Policy.
I didn't get that feeling; maybe I missed a post.
Unfortunately, PermError is caused by a lot of other things besides
just NXDOMAIN. You make one screwup on your SPF record, and *poof*,
you get lots of email rejected.
Yes. As does a typo in an ip4: mechanism. So?
We need to try to make SPF failsafe. If you screw up on your Sender
Policy, then you should end up like you don't have a Sender Policy.
Define screw up.
Having "v=spf1 ip4:aaa.bbb.ccc.22 -all" and someone, maybe you,
screws up and the MTA is suddenly on aaa.bbb.ccc.20
(I've seen this, close to me)
Having "v=spf1 a:aaa.bbb.ccc.22 -all", without a 22 TLD.
(I've seen this, IIRC on this list)
Having "\"v=spf1 ip4:aaa.bbb.ccc.22 -all\""
(this is a valid case of NONE)
More?
I think that treating NXDOMAIN as None is the most logical thing. If
i-hate-spf.com doesn't want anything to do with SPF, then an SPF check
against nxdomain.i-hate-spf.com should return None, not PermError.
True. Except when i-hate-spf.com does publish something like
"v=spf1 include nxdomain.i-hate-spf.com -all"
This is what the discussion, IMHO, is about.
There isn't a permanent error in their Sender Policy, they don't
*have* a Sender Policy.
That is currently under debate. FWIW, I think they _do_ have a sender
policy if they publish any text record starting with "v=spf1 ".
Even if you think that treating PermError as if it was None isn't the
right thing to do, I don't think we should make that change for
SPFv1. That is something we would need to change in SPFv2.
Can we vote on this?
In order to prevent people from trying to use SPF to implement their
Receiver Policy of rejecting on NXDOMAIN, I strongly believe that we
MUST have the result of NXDOMAIN be none.
True, except if it is part of an include or a redirect.
In order to maintain backwards compatibility, PermError MUST be treated
as None, or at very worst, some sort of feedback request like what is
in SoftFail.
Define backwards compatibility. http://spf.pobox.com/rfcs.html
specifies the CURRENT (emphasis mine) SPF Protocol Specification
to be draft-lentczner-spf-00.txt which defines PermError as:
" 2.4.7 PermError
A PermError result means that the domain's published records couldn't
be correctly interpreted for this "Mail From" identity. Checking
software SHOULD reject the message. If rejecting during SMTP
transaction time, a 550 reply MUST be used.
"
Alex