Re: SPFv3 proposal: rawfail result

On Fri, 4 Feb 2011, Alessandro Vesely wrote:
> To me, it seems nearly impossible to formally define that difference
> within the definition of the check_host function, in the face of
> forgeries.

Actually, "check_host" doesn't need to worry about it.  It would be
called upon only to *return* "fail" or "rawfail" according to the SPF
records, not to *interpret* them.

Still, I see what you're talking about, but would counter that it is even
harder to write a single reference behavior-set that makes use of the
distinction between "unknown" and "pass", let alone "softfail".

What I'd do is define a second function "is_internal_forward", that
returns a ternary result : True, False, or Unknown.  The definition would
have to be supplied by the local site, but it would have to satisfy the
following requirements.

 * MUST return True in all cases where a backup MX is handing off a
message towards the primary
 * MAY return Unknown in any other case
 * SHOULD NOT return True when the message is not a forward.
 * SHOULD NOT return False when the message is a forward.

(I use SHOULD because today forwarder whitelisting is done in an ad-hoc
way that could be utterly broken by a forwarder changing the IP or
hostname of its handoff mailserver without notice.

If we used MUSTs, then reject-on-ordinary-fail would not be available to
sites that have merely enumerated their incoming non-rewriting forwards,
but only to those confident that there are *none at all*)

Then the SPF reject vote is decided by the following matrix:

	rawfail  fail     softfail unknown  pass
True	Accept   Accept   Accept   Accept   Accept
Unknown Reject   Accept   Accept   Accept   Accept
False   Reject   Reject   Accept   Accept   Accept

---- Michael Deutschmann <[email protected]>