On Fri, 2004-12-03 at 20:32, Dave Crocker wrote:
In other words, it is not enough that one can fine some entry that matches
a name to an address. The semantics of the matching needs to.... match the
use.
I understand (and agree with) this one specific complaint that I think
you have:
Seemingly-unscoped spfv1 implicitly merges MAILFROM and HELO scopes.
The historical reason/excuse for the merged scopes is, (as I understand
it), that if your purpose is to test incoming mails' MAIL FROM values,
there's a bit of a hole in the process if you get a bounce with "MAIL
FROM:<>" and have nothing to test against, so we test against the HELO
argument instead, using the very same record.
Such a dual-use is presumably okay with spf record publishers, as they'd
otherwise not really be protecting themselves from bounce forgeries,
(And because, unlike the PRA, this dual-use existed all along--it wasn't
sprung on domain owners after the fact.)
But it is still very slightly annoying to have no way of publishing two
tests for the two scopes: It would *would* be nice if I could publish
different records to be used for MAIL FROM tests and HELO tests.
That leaves the question: What are the possible ways that spf folks can
address this situation, looking just at SPF, and what are their
cost/benefits?
I can think of a few possibilities:
1. Ignore the problem completely for now: (fastest option)
Publish spfv1 with the minor corrections and tweaks discussed
in other threads, but not addressing this merged-scope issue
at all.
Later develop a full unified spec, using, say,
"v=spf2/scope1,scope2 blah -all" syntax.
At that point people who publish v=spf2 records can do the
multiple scoping.
2. Completely handle the problem right now: (slowest option)
Make more major edits to the spf1 spec to incorporate scoping,
including a specific helo scope.
This will add yet another delay for the council to publish the
spec.
3. Loosen the spec *just* enough to better allow for future helo-scope
solutions.
For instance, if tests for helo-scope were allowed to merely
default to testing the spf way, but use another, more specific
method if one were available and in agreement with local policy,
we'd then mostly have the best of both worlds above.
I think (3) would be nice if possible.
That is, I'd like to see if it's at all possible to make very, very,
tiny changes to the spec to allow for future helo-only scoping to be
made, so as to address complaints such as yours.
But I don't want to delay the spec from being finalized--I'd like a way
to improve things without requiring changes. I'd like to change the
spec without actually changing anything to speak of--or only changing
the smallest amount possible.
So is that possible?
Well, I have just such a specific suggestion, making small changes so as
to make (3) above more workable in the future. (I think this has been
mentioned many times on the list, but I think it happened before
marid--not sure.)
So here's my unified-ish suggestion--backwards:
Imagine a Received-SPF: line with the following format, and where
everything just happened to Pass:
] 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/classic/v1=Pass;
] scope/mailfrom/v1=Pass;
] scope/helo/v1=Pass;
] scope/PRA/v1=Pass;
] scope/sender_agents/v1=Pass;
] scope/super-nifty/v1=Pass;
] scope/CSV/v1=Pass;
] scope/dk/v1=Pass;
] user_warning_level/reputation=0
] user_warning_level/forgery=0
] user_warning_level/composite=0
So this spf library presumably took multiple scope results, fed them into a
local
policy engine, popped out a composite answer, (the "Pass" on the first line),
and
even made some helpful suggestions to the MUA on what sort of default warnings
to give about the message.
Note that even if you had some fails for some scoped tests, (say a PRA check
failed),
that needn't cause a composite FAIL if you didn't want that as your local
policy.
Instead it would just cause a FAIL for that one scope, thus letting users' MUAs
alert
users to the problem.
All these scopes couldn't be tested and printed with a single check_host()
function--you'd either need a different check_host() for each scope,
(especially for
doing things such as domain keys tests), or a scoped_check_host() that has the
scope
as an argument. But that sort of detail is more of a unified-type thing,
closer to
option (2) above.
The goal in (3) is to be much more lazy, figuring out the bare minimum
required for both a smoother transition to unified, and for allowing an easy
option for fixing the mailfrom&helo merged scope among interested parties soon
after spfv1 goes through.
Fortunately, it looks to me like all we need are a few tweaks to the definition
of the Received-SPF: header, which was conveniently being considered changed
anyway. :-)
Changes required:
A. Allow for the "scope/scopename/version=Result" syntax in
Received-SPF:
Fortunately, there's nothing stopping that usage in the spec
now, but perhaps the scope/... keyword could be reserved, (for
everything but "scope/x-scopename" to allow for unofficial scopes).
This change does not affect backwards compatibility whatsoever.
B. Define the current merged mailfrom&helo usage as the scope name
"classic". (Or some spiffy name. Not mailfrom or helo.)
Again, no backward compatibility problems.
C. Redefine the meaning of "Received-SPF: Result".
Change it from meaning:
o The result of check_host(),
to meaning
o The result of the local policy engine.
Option 1: The above redefinition occurs iff there are any
quote-value pairs of the form "scope/scopename/version=".
The upshot of this is that an spf client that
wants to use this redefinition will append a
"scope/classic/v1=Result" tag.
Option 2: The above redefinition is global, and spf clients
are required to publish a "scope/classic/v1=Result" tag.
Between the two, I would go for Option 2 for simplicity. It says what
you must do, prepares the way for more scopes to be defined, and...in
effect it's actually the same as Option 1, since if your library
*doesn't* return a scoped response, you know the one-Result you get
is the result of the merged spf&mailfrom classic scope.
And again, no backward compatibility problems to speak of, or not
much of any at least, since you still have a good overall Result
in the same place, (even though it now means something slightly
different.)
If the meaning of Received-SPF were changed in these three ways, we'd still have
the nice property of a standard result of tests: All libraries that published
a scope tag with "classic" would have the same Result for that scope, and all
libraries that published no scope tags would have the same first-Result.
It makes convenient and inconvenient changes to the meaning of the header:
Instead of only listing the results of sender policies, which admittedly does
make sense for sender-policy-results header, it lists the results
of each sender policy test, *and* the conclusions the receiving machine
can immediately make from that data, in a form an MUA can use.
But more importantly, if this were changed, and spfv1 soon finalized and
published, another document could define "v=spf1/helo" scope, and what
clients that wanted to implement that test should do, and how they
should add to this same Received-SPF: line.
That sort of thing is something we'll need in unified. There's probably
a lot more than I realize in defining different scopes and operators and
how to deal with them, but it would be nice if MUAs written now could
parse scopes written two years from now.
We can't easily define all the scopes and operators and such now, but
can we have the spec allow for future results to be parsable by current
tools, and I think (hope) with very little work.
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com