----- Original Message -----
From: "wayne" <wayne(_at_)midwestcs(_dot_)com>
To: "IETF MXCOMP" <ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Tuesday, March 30, 2004 7:32 PM
Subject: Re: Limited scope of work
Actually, that is EXACTLY the mindset that should be adopted. If we
don't
adopt this mindset we might as well trust everything by default like we
have
for the past fifteen+ years. Or is it twenty+ years?
The issue of whether there should be just a pass/fail, or if there
should be some levels of gray in the LMAP proposals seems to be one
that many reasonable people disagree on. I think most people agree
that the desired result is widespread adoption with generally only
pass/fail results, but there is disagreement about how to reach this
goal.
You make some very excellent valid points.
I have a few points:
1) I think it ok to have this relaxed result as long as it is coupled with
a "time limit."
The SPF docs eludes to the idea it is in placed for migration, which is
fine, but a statement should be stated that it must be time limited. It can
not be permanent policy.
I already have a "wish list" logic to be added that will record the "start"
date for the first softfail/neutral result returned by a SPF compliant
domain, something like:
Reject-SPF-SoftFail X months|msgs
X months , means reject this result after X months of usage
X msgs, means reject this result after X messages were submitted
etc.
In other words, this is the kind of "kludging" I wish to avoid in "new
technology" that hasn't even become a standard yet!
So lets remove all umbitities now before it is too late. Who wants to
already start creating variant-SPF? I want to help make SPF work great! I
don't want to reinvent the wheel here..
Meng should atleast provision that makes this results time limited and add a
provision that allows implementators to perform "SPF compliant" logic like
above.
2) I don't think the relaxed results apply to HELO SPF lookups. I don't
think it is logical.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com