On Sat, 4 Dec 2004, Mark Shewmaker wrote:
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.
I agree this is bad.
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.)
I do not think it is ok with publishers - they were never really asked
about it anyway and many do not understand that publishing spf record
may end up being used for more then just evelope from (which is what many
understand spf record are for)
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.
And for other scopes. I would even say it should be requirement that
you have to explicitely specify that its ok for SPF record to be used
for HELO as well as MAIL-FROM. etc. Same BTW, for PRA.
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.
Scoping as handled by marid-protocol draft is not necessarily the best way
to handle scoping and was never really approved by SPF community.
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.
That is my preference. I do not think delay will mean that we dont have
working SPF protocol or that people can't use it now, its just the matter
of creating a good technical document for standard process.
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.
Explain how you think this "change" to spec should look like and why is it
not better to just address scoping right now.
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
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))
I'm against Received-SPF being used actually, it is too SPF specific and
we need something general and I think what would be good is to have a
special document that explains for implementors how to convert their
code that adds Received-SPF to do equivalent Authenticateion-Results header.
That is not to say that we should not document Received-SPF (for those
who see it in email, they need to know what it is about), but we should
not promote it for future. So what I would prefer is that Received-SPF
not be included in spf protocol document but be document in separate
draft i.e. remove it from draft-schlitt-spf-x.txt and move to separate
draft document and in draft-schlitt-spf make reference to that draft
and to different draft describing use of Authentication-Results and
say that either one MAY be used for reporting SPF authentication
results but that Authentication-Results SHOULD be used.
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.
I completely agree. That is what UnifiedSPF is all about but we're had
bump on the road and now Meng is not even going that direction. After
MARID closure we've had good discussions on scoping, on Unified SPF
algorithm, etc and we need to start workin on it again as soon as we're
dne with current political organizing.
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)
DomainKeys SHOULD NOT BE part of SPF. The checking for mail signatures
should be done by completely different process and I would rather it
actually add separate Authentication-Results header.
, 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. :-)
I don't thin just change of Received-SPF header will do it what we need.
Changes required:
A. Allow for the "scope/scopename/version=Result" syntax in
Received-SPF:
That is fine, but I'd rather we depreciate Received-SPF for the future.
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.
Also fine, but it would be better if we just handle scoping.
[snip some text that is largely already mentioned before]
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.
How would use of "v=spf1/helo" effect current SPF1 clients?
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.
I agree, I just don't think Received-SPF is the way to go.
---
William Leibzon, Elan Networks:
mailto: william(_at_)elan(_dot_)net
Anti-Spam and Email Security Research Worksite:
http://www.elan.net/~william/emailsecurity/