On Thu, 2004-09-30 at 17:12, Stephane Bortzmeyer wrote:
On Wed, Sep 29, 2004 at 01:18:49PM -0700,
william(at)elan.net <william(_at_)elan(_dot_)net> wrote
a message of 108 lines which said:
-----------------------------------------------------------------
Step | SPF Identity | Result of verification
-----+---------------+-------------------------------------------
1 | SPF2.0/HELO | If Fail -> reject, otherwise go to 2
2 | SPF2.0/SUBMIT | If Fail -> reject, otherwise go to 3
3 | SPF2.0/MFROM | if Pass -> accept email, otherwise go to 4
4 | SPF2.0/PTR | If Fail and #1 was not Pass -> reject
I would change #4's result to:
"If Fail and ( (#1 tested and no test for the scope of #1 passed) or
(#2 tested and no test for the scope of #2 passed) or
(#3 tested and no test for the scope of #3 passed) or
false
) -> reject"
(ie, mailfrom could be tested with SES as well as spf, as well as manual
whitelisting--it doesn't really matter which one passes.)
I may be thick but why is it necessary to specify the algorithm to use
and the results? Why not providing several SPF records for several
identities and let the user decide which to check and how to combine
them? (Specially since the user may be a scoring system like
SpamAssassin which does not yield binary Pass/Fail but scores.)
I want these tests done in my MTA, which is a place where I want hard
pass/fail answers. I don't want a morass of sort-of/maybe answers of
the sort that spamassassin excels at--it isn't useful at that level.
Perhaps it is useful for spamassassin users, but I'd hope that they
could simply have had all these authentication tests done before they
ever get the message in the first place.
As far as "which to check", the recipients can all decide to check
different things, sure. There are unfortunately lots of practical
reasons why all recipients won't be able to do all checks. That I can
understand.
However, I think it's important for everyone to be on the same page as
to what *effective* order the checks they do make should be done in.
That is:
o If we all did all checks, and
o we're wanting to end up with a single pass/fail answer, and
o we have the exact same whitelists,
we had better IMHO all get the exact same end result!
Saying that recipients can pick among the checks they want to do is one
thing.
Saying that the same combination of checks done by two different
recipients having the same whitelists results in these recipients
getting different end results is quite another thing--that's as bad as
two recipients evaluating the same incoming message using classic spf
rules and getting two different answers!
I'd like to think that we could come up with The One True Order of
checks to be made, (equivalent algorithms being acceptable), or some
similar meta-rules that will work with Domain Keys and such, finding out
exactly why this one set of rules gives the optimum solution in all
cases, etc., but perhaps that's just me being idealistic.
However, right now, even with scoping discussions, I think we don't have
quite as much consensus as to what the rules should be, and I'm
*guessing* it's because we've mostly just thought we had that consensus.
The idea with the different scopes is that you figure answers in the
different scopes and then combine them, but we've had some minor
disagreements on how to combine them. At the very least we should
figure out what different alternatives people might have had all this as
their individual conclusions, conclusion that might have seemed so
clearly obvious to them that there had been no point even bringing it
up.
I do not think it will be possible to get a consensus on such an
algorithm so why not concentrating on the syntax of the record and on
the definition of the identities and waiting more experience before
deciding how to combine the checks?
We might not get full consensus, but we've not actually asked pursued
this ordering/combining question directly yet, I don't think.
As an aside, we already have one algorithm for combining the answers
hardcoded into unified. It also happens to be an algorithm that I don't
personally agree with, so I'm keen to have this discussion. :-)
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com