At 12:12 PM 3/29/2005 -0500, Scott Kitterman wrote:
>-----Original Message-----
>From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
>[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of David
MacQuigg
>Sent: Tuesday, March 29, 2005 12:00 PM
>To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
>Subject: [spf-discuss] Standard Authentication Query
>
>My worry is that we might get agreement within the SPF community, barely
>squeeze it through IETF, then face adamant opposition from SenderID,
>DomainKeys, and any other group that doesn't like the letters SPF in an
>authentication header.
>
>My suggestion is that we take one little step backwards and try for a
>standard that everyone can agree on (or at least make clear that their
>objections are frivolous). With a few items standardized, SPF and any
>other method can do whatever they want within the standard, and the much
>bigger community that is not involved in the competition between
>authentication methods (spam filter companies, ISPs, spam blocking
>services, etc.) - that much larger community can move forward, knowing
>exactly what an authentication header will look like.
>
For those of us who've been around through the MARID working group, I would
expect that the rough consensus is that we've already tried that. WRT
Sender ID, I doubt that there will be significant support for working with
them until MS changes the license agreement to be compatible with the GPL
(this has been explored and is apparently not in the cards).
The IETF is probably not the place to deal with this kind of
controversy. I'm thinking the FTC might do better in dealing with hostile
competitors. ( Their main activity is anti-trust.) They have the mandate
from Congress. It is in their plan to provide a solution if the industry
doesn't provide one soon. More than any industry or standards group, the
FTC can require cooperation among hostile competitors.
I would like to see the FTC:
1) Call for a simple email authentication standard that all parties can
live with.
2) Use neutral experts to evaluate the objections to each proposal.
3) Chose the one proposal that provides the optimum tradeoff of
a) minimizing time to a workable shared standard
b) addressing all items that are nice but not essential in a shared standard
c) providing a fair basis for the different methods to compete
4) Modify the chosen proposal if necessary to achieve the optimum.
5) Promote the standard among ISPs and companies providing anti-spam
products to those ISPs.
6) Evaluate the results of competition between the various methods working
within the standard, and then decide if there is any need to mandate one or
another.
Item 3 will give some incentive to each of the competitors to give serious
thought to what the other guy needs. Some of the differences I'm seeing
between the current proposals are frivolous.
My expectation is that just starting this process will break the current
logjam. Hopefully, it will result in a voluntary standard good enough that
it is not necessary to write a detailed technical standard into law.
< snip discussion of authentication headers >
I'm, by and large, with Frank. We need to get the existing v=SPF1
documented in an experimental RFC and then move on to whatever comes next.
I do think that some added cautions wrt DNS loading and security risks may
be in order. I'm thinking that one over.
I wouldn't slow down the progress on the SPF standard, but be prepared to
make some changes to the parts relating to inter-operability.
-- Dave
************************************************************ *
* David MacQuigg, PhD email: dmquigg-spf at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *