spf-discuss
[Top] [All Lists]

Standard Authentication Query

2005-03-29 10:00:12
At 05:31 PM 3/29/2005 +0200, Frank wrote:

I want an RfC for
v=spf1 a.s.a.p.  All these permanent modifications like adding
zone-cut, removing zone-cut, use PRA instead of MAIL FROM,
don't use PRA, MAYbe test HELO, ignore HELO, SHOULD test HELO,
limit the processing time to at least 20 seconds, at most 20
seconds, at least 10 indirections, at most 10 indirectionss,
exactly 10 mechanisms, 10 queries, etc.

...all this infuriates me.  V=spf1 is supposed to be stable for
more than a year now.  I'm not interested in "new features", as
long as we don't have this one "really stable" RfC.  Even if it
is only "experimental".

In your case I felt that you insisted on going through a wall
(anything with DNS is a "wall" from my POV), where I could see
the SIQ-door, but couldn't explain the "wall"-part.

Chris Haynes has now done it:  It's not a theoretical problem
with DNS, but "only" a practical problem with the deployment of
new uses of DNS queries for new RRs like the future SPF RR.

Back to square one:  Adding new features to DNS is no option
but a bad case of FUSSP - "when all DNS libraries, servers,
firewalls, and what else are updated".  Yes, then we could do
wonderful things.  We could even forget SPF and implement CSV.

But in practice that's not possible.  SPF has reasons to abuse
TXT "at the moment", and this moment will last for decades plus
the time wasted to get a RfC with the new SPF RR (without your
modified query),

It was a design decision to have a 1:1 correspondence between
the "old" TXT RR solution and the "new" SPF RR.  Maybe add an
optional "additional info section" with the IP to these queries
for v=spf6 or spf/6.0 later.

But please stay away from v=spf1 "as is" before we have some
kind of "official" RfC for v=spf1.  It's already hell to get
at least so far.  The very last v=spf1 needs now are some "new
features".  Let alone new features in its DNS layer.

I appreciate your frustration. It sure seems like the entire technical community is floundering over what should be a simple standard. I don't mean the SPF standard, but a standard that all methods can live within. This would not include any controversial items like redirected queries, but just those few items needed for inter-operability of all methods.

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.

As for the opposition from the DNS community, I may be wrong because I haven't reviewed the earlier controversies, but I'll bet we can get them to help if we address their fundamental concerns, and enlist their help in coming up with a solution. We need them to think as proud fathers, not jealous guardians. Surely they would like to have their invention be a key player in the solution to a serious international problem. If not, there are alternatives.

Here is what I see as the fundamental requirements for a standard authentication query: 1) The authentication query must be quick and independent of any particular method. The alternative is to have the sender declare the authentication method in the envelope, but let's put that option aside for the moment. 2) The response must be quick and allow rejection of most forgeries with no additional queries.

I'm tempted to suggest how this might be done, but first let's see if anyone has objections to these requirements, or anything else we should add at this level.

-- 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        *
************************************************************ *


<Prev in Thread] Current Thread [Next in Thread>