I would like to bring up two things:
1. The default overall result isn't defined for all cases
in which the mailfrom and helo results don't match.
I'm not quite sure what the right answer should be
here, but leaving it undefined just doesn't seem
right.
(I don't want to dredge up unified arguments here,
but would rather there be a simple, sensible,
standard, and documented default answer that's
just obviously right.)
This is my main worry.
2. It might be helpful to define a few more (optional)
received-spf key names. Since they're not defined
now, this wouldn't be a change that would break any
existing implementation.
Technically this needn't be added to the spec, since
extra key names can show up over time--and that may
be a better way to go even if we did have lots of time
to figure out great names. (And everyone agreed on
the need for the names.)
I'm wanting to mention them now anyway, because for
me they help remove some mental blinders in thinking
through (1).
(So I'm mentioning them more as a, err, cataylist for
thought.)
Ambiguous overall results:
--------------------------
From section 2.1 of
http://www.schlitt.net/spf/spf_classic/draft-schlitt-spf-classic-01pre5.html :
| It is RECOMMENDED that SPF clients check not only the "MAIL FROM"
| identity, but also the "HELO" identity
[...]
| If the HELO test is performed, and results in a "Fail",
| the overall result for the SMTP session is "Fail",
| and there is no need to test the "MAIL FROM" identity.
So in this case the overall result for the SMTP session is "Fail."
But what about the overall result in other cases? Is it
implementation-dependent?
Can one compliant spf library return one overall result, and another
compliant spf library return a completely different overall result?
At the very least we know the following truth table values are correct:
HELO result MAILFROM result Overall result
----------- --------------- --------------
FAIL (any) FAIL
And we can probably safely guess:
HELO result MAILFROM result Overall Final result
----------- --------------- --------------------
PASS PASS PASS
None None None
Neutral Neutral Neutral
Softfail Softfail Softfail
TempError TempError TempError
PermError PermError PermError
But that leaves 36 ambiguous situations, namely the remaining
combinations of (None, Neutral, Pass, Fail, SoftFail,
TempError, PermError) with themselves.
IMHO this is not a good situation.
My initial thoughts were that the standard should say to use the "worse"
of the two answers, with the worst-to-best list being (PermError,
TempError, SoftFail, None, Neutral, Fail, Pass).
(At least then all correct implementations that choose to check
HELO will have matching default answers, as would correct
implementations that chose not to check HELO.)
I'm wondering what thoughts folks might have for an obviously-right
answer that Wayne would find unquestionably necessary to put into the
spec and unquestionably correct.
Now, the rest of this is more..conjecture.
Stepping back for a second, it looks to me that there are really four
(types of) results:
1. The initial Mailfrom Result.
2. The initial HELO result.
3. The default overall result.
4. Policy-specific overall result(s).
Note that the last could be multiple results. A site might have a
default policy, a site might offer a dozen easy-to-pick-from policies
for recievers to choose from, and an individual receiver might have
their policy. (Yes, this seems out in left field, but bear with me for
a minute.)
The draft has an implication that there's only one result, but in
a way this is similar to going to a widget supplier, asking "can
I buy your widgets for a dollar each?", and expecting that to
be a yes or no question.
(The real answer might be "'No' if you're buying less than a thousand,
'maybe' if you're buying between one and ten thousand and can show us
you'll continue to buy at least that many twice a year, and 'yes' if you're
buying more than ten thousand."
If the would-be purchaser returned to his boss with only a straight
yes-or-no answer, that would not be very useful when trying to decide on
what "policies" to use in the future. (ie, "Looking at our past
results, I think we might do better if we commit to buying widgets from
this place at a regular schedule."))
This could translate for an SPF scenario into the question: "What
receved messages of mine would have been rejected had I dropped my
whitelisting. Let me ask my friendly MUA, who has been keeping
a note of these things."
More Received-spf variables:
----------------------------
However, the Received-SPF header doesn't have standard key names
for these other results.
So I'm suggesting that there be standard names for these results.
For instance, imagine if there were a way to say: (the top four
lines are from an existing example in the spec)
Received-SPF: Pass (mybox.example.org: domain of
myname(_at_)example(_dot_)com designates 192.0.2.1 as permitted sender)
receiver=mybox.example.org; client-ip=192.0.2.1;
envelope-from=<myname(_at_)example(_dot_)com>; helo=foo.example.com;
scope/mailfrom=PASS; scope/helo=none;
policy/default(_at_)example(_dot_)com/suggested_policy=PASS;
policy/default(_at_)example(_dot_)com/restrictive_policy=NEUTRAL;
policy_used=default(_at_)example(_dot_)com/suggested_policy;
So the mailfrom scope resulted in a PASS, the helo scope in NONE, if you
used default(_at_)example(_dot_)com's policy named "suggested_policy" you'd end
up
with a PASS as the overall answer, if you used default(_at_)example(_dot_)com's
policy named "restrictive_policy", you'd end up with "NEUTRAL" as an
answer, and the policy being used by the receiver at the time of mail
receipt was default(_at_)example(_dot_)com's "suggested_policy".
The reason I wanted to go through example extra key-names is not so much
to suggest that specific wording, but to bring out the point that having
a well-defined default to this mismatched helo&mailfrom doesn't prevent
local policies from being implemented in a non-confusing way to MUA's
that want to show what really went on.
(That helped me get my brain around things better. Others probably
don't share my exact mental hang-ups.)
Technically, standard key names can simply evolve after the spec is
published--they needn't be set in stone now. But their existence means
that MUA's could understand what went on, when policies changed, etc.
(Maybe the authentication-results: header can solve this issue.)
But...any ideas on the helo-differs-from-mailfrom thing?
I hate to bring this up now--hopefully I've missed something big!
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com