-----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).
With the exception of CSV, BATV, and SES, none of the other authentication
methods are working in the RFC 2821 envelope domain. I tend to think that
envelope authentication can proceed pretty much independently of RFC 2822
message authentication.
There are one or two internet drafts that deal with authentication headers
running around, but I don't know that a lot of progress is being made on
that front (sorry, the references escape me at the moment).
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.
Scott Kitterman