Meng Weng Wong [mengwong@dumbo.pobox.com] wrote:
> Hey guys, I cleared up some confusion in the return codes --- the old
> "unknown" conflated two concepts, an explicit "?" and an error state
> caused by parsing / interpretation problems. They have been
> disambiguated into "neutral" ("?") and "unknown".
>
> Functionally they are identical so this change is fully backward
> compatible with existing libraries.
>
> I also added two new return codes, "none" and "softfail" as per
> discussion earlier this week.
Do we really need so many result codes? I don't think so.
Now, we have "pass", "neutral", "softfail", "fail", "none", and "unknown".
Consider an SPF tester asking the envelope sender domain the question: "What shall I do with a message being sent from $IP_ADDRESS but stating as coming from $DOMAIN?"
The answer...
* "pass" means "pass",
* "neutral" means "I won't tell you what to do with it",
* "softfail" means "this message didn't originate from us, but please treat it mildly",
* "fail" means "fail",
* "none" means "no SPF record available",
* "unknown" means "zr54-$sd#fs" (i.e. an error occurred).
This is not only partly redundant and unnecessarily detailed, the result code names are also confusing and maybe even misleading.
"pass", "fail", and "softfail" do make perfect sense, I think.
What's the difference between "neutral" and "none"? They both mean "the result is unknown". I don't think "none" and "neutral" make much sense as answers to the question of an MTA doing an SPF test.
"unknown" really means "an error occurred".
Of course, as suggested, one can collapse this multitude of codes into a smaller set of return codes, but it isn't clearly specified *how* to do this. This is very bad!
To give some *constructive* criticism, I'll make an alternative proposal:
An SPF tester returns a result code, and an optional error code.
The result code...
* "pass" means "pass",
* "softfail" means "this message didn't originate from us, but please treat it mildly",
* "fail" means "fail",
* "unknown" means "I won't tell you what to do with it" or
"no SPF record available" or
"zr54-$sd#fs" (i.e. an error occurred).
The error code...
* "defined" means "the result code could be determined without problems from an existing SPF record",
* "undefined" means "no SPF record available",
* "temperror" means "a temporary error occurred, please retry again later if possible, otherwise reject",
* "error" means "a permanent error occurred, with little chance of not occurring again later".
That way, the answer, i.e. the supposed action of the MTA doing an SPF test with regard to the message being tested, is clearly separate from *why* that answer was given.
In almost all cases, SPF testers will (and should) not really be interested in *why* a specific answer was given, but only in *what* the answer is.
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ï#ÄÏÉæGã!'Rzš´ˆ»£‡Æ~3com
> Hey guys, I cleared up some confusion in the return codes --- the old
> "unknown" conflated two concepts, an explicit "?" and an error state
> caused by parsing / interpretation problems. They have been
> disambiguated into "neutral" ("?") and "unknown".
>
> Functionally they are identical so this change is fully backward
> compatible with existing libraries.
>
> I also added two new return codes, "none" and "softfail" as per
> discussion earlier this week.
Do we really need so many result codes? I don't think so.
Now, we have "pass", "neutral", "softfail", "fail", "none", and "unknown".
Consider an SPF tester asking the envelope sender domain the question: "What shall I do with a message being sent from $IP_ADDRESS but stating as coming from $DOMAIN?"
The answer...
* "pass" means "pass",
* "neutral" means "I won't tell you what to do with it",
* "softfail" means "this message didn't originate from us, but please treat it mildly",
* "fail" means "fail",
* "none" means "no SPF record available",
* "unknown" means "zr54-$sd#fs" (i.e. an error occurred).
This is not only partly redundant and unnecessarily detailed, the result code names are also confusing and maybe even misleading.
"pass", "fail", and "softfail" do make perfect sense, I think.
What's the difference between "neutral" and "none"? They both mean "the result is unknown". I don't think "none" and "neutral" make much sense as answers to the question of an MTA doing an SPF test.
"unknown" really means "an error occurred".
Of course, as suggested, one can collapse this multitude of codes into a smaller set of return codes, but it isn't clearly specified *how* to do this. This is very bad!
To give some *constructive* criticism, I'll make an alternative proposal:
An SPF tester returns a result code, and an optional error code.
The result code...
* "pass" means "pass",
* "softfail" means "this message didn't originate from us, but please treat it mildly",
* "fail" means "fail",
* "unknown" means "I won't tell you what to do with it" or
"no SPF record available" or
"zr54-$sd#fs" (i.e. an error occurred).
The error code...
* "defined" means "the result code could be determined without problems from an existing SPF record",
* "undefined" means "no SPF record available",
* "temperror" means "a temporary error occurred, please retry again later if possible, otherwise reject",
* "error" means "a permanent error occurred, with little chance of not occurring again later".
That way, the answer, i.e. the supposed action of the MTA doing an SPF test with regard to the message being tested, is clearly separate from *why* that answer was given.
In almost all cases, SPF testers will (and should) not really be interested in *why* a specific answer was given, but only in *what* the answer is.
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ï#ÄÏÉæGã!'Rzš´ˆ»£‡Æ~3com