-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sorry for the late reply. This is my view on this issue:
The spec explicitly recommending receiver policy is a bug. Receiver policy
is just that: receiver policy. The spec should define the meanings of the
various result codes, and leave it to the receiver how to react to those.
So, yes, 2.5.7. should not make any recommendations on receiver policy.
Yes, syntax errors should become obvious ASAP. Thus syntactically invalid
SPF records should result in "PermError", certainly not in "None". _If_
we really want to suggest some behavior for PermError, we should suggest a
permanent (5xx) rejection.
Also, we should not make any more "ResultCodeX SHOULD/MUST be treated
exactly like ResultCodeY" statements than absolutely necessary. I have
never liked the idea of defining distinct result codes that are then
declared to be semantically equivalent. That way lies madness.
Summing it up: Of the 4 options offered by Wayne, 1, 2, and 4 are
unacceptable. 3 is marginally acceptable. But let's not mandate receiver
policy.
Re DSNs: One should not send DSNs to the envelope sender as a response to
broken SPF records. This opens up the possibility of joe-jobs, which is
exactly what SPF is trying to prevent. Besides, this is receiver policy
and should not be defined by the spec.
Re scaring off first-time deployers: I seriously doubt that any serious
admin is going to be scared off by e-mail not getting delivered and error
messages being generated due to him having configured a broken SPF record.
Admins will recognize that their problem is caused by their own fault, not
by a misdesigned SPF. Don't take people for more simple-minded than they
really are.
Wayne Schlitt wrote:
Should the language in the PermError section be toned down to match
the flexibility of the other SPF results?
Yes.
Does it really make sense to say that PermError SHOULD be rejected when
Fail doesn't?
No.
I couldn't have said it any nicer than Stuart:
Stuart D. Gathman wrote:
The RFC shouldn't "equate" PermError with anything. It is one of the
possible results of evaluating an SPF policy, just like PASS, FAIL, or
NEUTRAL. Ultimately, it is up to the receivers policy what to do with
*any* SPF result. The RFC should make clear the senders policy for a
given email.
PASS "sent via authorized means"
FAIL "not sent via any authorized means"
SOFTFAIL "not sent via any authorized means . . . we think"
NEUTRAL "we don't know"
NONE "What's SPF?"
PermError "Our policy is screwed up."
TempError "Ask us again in a few hours"
The RFC should outline general guidelines for receiver policy, but they
should all use words like MAY and SHOULD. No one should be forced to
accept or reject email.
In any case, there should be a clear distinction between an SPF *result*
(which had better be completely objective and deterministic) and the
receivers *response* to that result (which can vary with mood, political
persuation, random number generator, etc).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFCfqDAwL7PKlBZWjsRAlT5AJ9X09FMnvFwn2OGaZ21LOX8GjG0RwCeJjMu
P0qv6vPON7x8t3x/oTBgQZY=
=+tku
-----END PGP SIGNATURE-----