On Sat, 2004-12-04 at 05:20, william(at)elan.net wrote:
On Sat, 4 Dec 2004, Mark Shewmaker wrote:
Scoping as handled by marid-protocol draft is not necessarily the best way
to handle scoping and was never really approved by SPF community.
True.
Fortunately the discussion of the format for publishing scopes is mostly
uncoupled with the discussion of how to best publish the result of
future scope tests. :-)
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.
Explain how you think this "change" to spec should look like and why is it
not better to just address scoping right now.
It would be editing the Received-SPF section of Wayne's spec. (I didn't
want to send diffs with a first-concept type email, which is a good
thing because you're making me rethink things in the next section.)
As far as why to not address scoping now--I think the consensus is to
get something out the door. Addressing the publishing of results in a
way that will not hinder, but help, future additions to client spf
requirements, won't represent the sort of slowdown that reworking the
entire spec to incorporate scoping tests would.
Perhaps you need to look again at draft-kucherawy-sender-auth-header-00.txt
and then look at draft-leibzon-responsible-submitter-00.txt, which had the
following in it in section 5.4:
Authentication-Results: test-system.example.com
from=user(_at_)example(_dot_)com
envelope-submitter=user(_at_)example(_dot_)com ;
SPF=pass (auth-ip=10.0.0.10
SPF/submit=pass (auth-name=user(_at_)example(_dot_)com))
Thank you! You are quite correct: I needed to look at that again.
I had *completely* misinterpreted things the first time around.
I'm against Received-SPF being used actually, it is too SPF specific and
we need something general
Good point.
It makes more sense for something other than the spf client (or any
individual scope test) to collate the result of the various scope tests,
and the results of things like virus-checker tests (for the few users
who would want that, say statistical-analyzing spamtrap addresses),
applying local policy, making reputation assessments, and publishing all
that data as well as warnings about questionable messages.
Having all that data in a header of its own also makes sense, especially
a header that's not tied down into any one particular test.
Technically that's not all "authentication", so the name of the header
doesn't quite fit, but..a standard way of publishing and parsing that
data, defined outside of the spf spec, is a pretty good way of doing
things, especially if it's not XML formatted. :-)
If Authentication-Results: can do all that, (and it looks like it can),
then maybe it does make sense to not worry about the Received-SPF:
header at all to begin with, keeping that publishing done in a way
uncoupled with the internals of SPF.
It would be pretty cool if there isn't something else that I'm not
thinking through clearly, and there's a general consensus that using
such an outside header would be better, because if there's one thing
that can speed the publishing of a spec, it's a sudden group consensus
of "delete this otherwise-contentious section". :-)
(Technically we could do both--have extra data in a newly-redefined and
newly-deprecated Received-SPF: header, and push this other header,
but..)
I'll check back in a few hours, in anticipation of an email that will
make me want to flip back to Received-SPF:. :-)
How would use of "v=spf1/helo" effect current SPF1 clients?
They'd ignore it, as "v=spf1/helo " doesn't begin with the string
"v=spf1 ".
it would be nice if MUAs written now could
parse scopes written two years from now.
I agree, I just don't think Received-SPF is the way to go.
You're quite convincing.
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com