-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Wayne Schlitt 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.
Now I'm getting really nervous, too. Who the heck proposed anything like
that?
However, it looks like what people are trying to do is have NXDOMAIN
be a PermError and PermError causing the rejection.
Yes and no, no, no. First, you yourself said that most people probably
aren't going to reject on PermError. Second, receivers are supposed to
check the validity and existence of the identity themselves before calling
SPF (or not).
This is really bad since it makes a Receiver Policy into a claimed Sender
Policy.
Does it?
Unfortunately, PermError is caused by a lot of other things besides just
NXDOMAIN.
"None", too, is caused by a lot of other things besides just NXDOMAIN.
This also dilutes the meaning of "None". "None" can not only mean "the
domain does not have a sender policy", but also "you gave me an invalid
identity, so you could have known yourself that there cannot possibly be a
sender policy".
If the granularity, and thus the expressiveness, of the result codes is too
low, we should not have named PermError "PermError" but should have added
another error code with that name. The name "PermError" implies an error
that is not going to resolve itself under unchanged circumstances. If
that's what it is, then not only record syntax errors but also identity
syntax errors fall in the "PermError" category.
However, I agree that we probably cannot introduce a new result code now.
(On the other hand, can we really not?)
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.
I don't see the point of your argument. Receivers aren't supposed to
subject obviously invalid identities to SPF checks. If they want, they
can very well accept mail from nxdomain.i-hate-spf.com, but they should
not subject it to SPF.
There isn't a permanent error in their Sender Policy, they don't
*have* a Sender Policy.
Although I don't agree with it, I think this (sort of philosophical)
argument is the best one against my position that I have read so far. IMO
most of the following other arguments don't really hold.
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.
Please explain why it would be an incompatible change. I once tried to
analyze the situation[1], but no one really responded to my analysis.
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.
You said most receivers would not reject on PermError anyway.
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.
spf-draft-200406[2], for instance, says:
| 2.2.2 Lookup
| [...]
| If the domain does not exist (NXDOMAIN), SPF clients MUST return
| "unknown".
| 3. SPF Record Evaluation
| [...]
| There are two error conditions, one temporary and one permanent.
|
| Error: indicates an error during lookup; an MTA SHOULD reject the
| message using a transient failure code, such as 450.
|
| Unknown: indicates incomplete processing: an MTA MUST proceed as
| if a domain did not publish SPF data.
| 3.2 SPF Directive Evaluation
| [...]
| If it throws an exception, mechanism processing ends and
| the exception value is returned (either "error"
| indicating a temporary failure, usually DNS-related, or
| "unknown" indicating a syntax error or other permanent
| failure resulting in incomplete processing.)
Note "or other permanent failure" in the last paragraph.
Yes, the overall picture of spf-draf-200406 suggests that NXDOMAIN should
be handled sort of "gracefully", but it also tries to prescribe receiver
policy.
But, trying to get a constructive discussion going, where's the actual
incompatibility of returning "PermError" (formerly known as "unknown") in
the NXDOMAIN case?
References:
1.
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200505/0117.html
2. http://spf.pobox.com/spf-draft-200406.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFCkFaRwL7PKlBZWjsRAuNrAKDp8KmZvwC9Z1wGz93Uk+ZEdBQmPgCgiS5o
uQCqGkH9Aux7d0e9J6MKYFM=
=60Hk
-----END PGP SIGNATURE-----