Mailing List Archive

error/unknown/pass/fail
I'd like to summarise the discussion (at the point that I left) with
regard to pass/fail/error/unknown statuses.

Principles:

If the initial domain of the sender does not have an SPF record (and
there is no local policy override), then the result is "unknown".

Any syntax error, missing record, unrecognized mechanism etc, dns
failure, is "error"

Any mechanism or modifier that finds an error, returns "error".

Unrecognized modifiers are ignored

The pass/fail/unknown statuses are generated as the result of a
mechanism evaluation. If the mechanism matches, then the result is
determined by the prefix character.

The include mechanism matches only if the included record returns
"pass". [Note that the error rule still applies]

* Note that softfail (if brought back) can be merged in easily in this
scheme.
* There is no distinction between permanent errors and temporary DNS
errors. I don't think that this is a serious problem

Was this refined further last night?

The biggest change that I see right now from the way that things
currently work, is that unknown mechanisms would return error rather
than unknown. I prefer this as it makes all errors behave in the same way.

Philip

--
Philip Gladstone
* Check out the live pondcam at http://pond.gladstonefamily.net

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h
Re: error/unknown/pass/fail [ In reply to ]
On Tue, Jan 27, 2004 at 06:17:25PM -0500, philip-spf@gladstonefamily.net wrote:
| I'd like to summarise the discussion (at the point that I left) with
| regard to pass/fail/error/unknown statuses.
|
| Principles:
|
| If the initial domain of the sender does not have an SPF record (and
| there is no local policy override), then the result is "unknown".
|
| Any syntax error, missing record, unrecognized mechanism etc, dns
| failure, is "error"
|
| Any mechanism or modifier that finds an error, returns "error".
|
| * There is no distinction between permanent errors and temporary DNS
| errors. I don't think that this is a serious problem
|

I think there are two kinds of errors:

1) DNS temporary error (timeout, SERVFAIL)

2) SPF parse error (missing record, unrecognized mechanism)

And there's the explicit unknown:

3) mechanism matches, prefixed with "?", so returns "unknown"

Only (1) should cause a 4xx tempfail back to the SMTP client.

(2) and (3) should both have the same severity since we're talking about
"fail safe" or "fail open" considerations. But it might be useful to
distinguish the two states all the way through the code until we reach
the client, at which point we collapse (2) and (3) into a single
"unknown".

In the case of an unrecognized mechanism or mechanisms we should provide
those mechanisms as Received-SPF: unknown dk habeas (...)

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h
Re: error/unknown/pass/fail [ In reply to ]
On Tue, Jan 27, 2004 at 06:29:10PM -0500, Meng Weng Wong wrote:
|
| I think there are two kinds of errors:
|
| 1) DNS temporary error (timeout, SERVFAIL)
|
| 2) SPF parse error (missing record, unrecognized mechanism)
|
| And there's the explicit unknown:
|
| 3) mechanism matches, prefixed with "?", so returns "unknown"
|

Here's the crux of the problem:

v=spf1 include:isp.com -all

If isp.com has no SPF record, do we want to return "unknown" or "fail"?

If we want it to return fail, we say that if the result of an include is
either (2) or (3) the result gets turned into a NOMATCH. Processing
continues.

If we want it to return unknown, we say that if the result of an
include is (2) we abort processing and return IMPLICIT-UNKNOWN.

If the result is (3) we abort processing and return EXPLICIT-UNKNOWN.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@Ë`Ì{5¤¨wâÇSÓ°)h