spf-discuss
[Top] [All Lists]

Re: [spf-discuss] Re: Ideas for future "unified" auth schemes

2005-10-11 12:05:31
William, thanks for the reply.


On Mon, 10 Oct 2005, Greg Connor wrote:

This is a fairly important question, which I believe I answered in my
first post on this thread.  As the subject suggests, I am looking for
a future scheme that "unifies" SPF with other identities that might be
checked against IP.  That implies that I'm *not* looking for clever
ways to modify v=spf1.

On Mon, 10 Oct 2005, william(at)elan.net wrote:
Other identities checked against the ip is scoping with use of spf
syntax and is a sender policy. "Unified" checking of these identities
implies recommended policies for the receiver which is different topic.
Which of these are you trying to discuss?


The first, mostly.  I want to give the receiver the freedom to do whatever
checks for which the domain owner can state a policy.  I don't want to require
certain checks in a certain order.

Some of the checks may seem non-sensical, but there may end up being cases
where they make sense.  Like if a domain is completely defunct, they can state
a blanket "do not use" policy that should apply to From: as well, but for most
domains the From: policy may be softer.  Anyway, what tests the receiver
actually decides to do should be beyond the scope right now... I just want to
give them the tools to do whatever checks they want to try.


spf language is a good mechanism for it but spf1 record is not setup
for specifying multiple scopes (we discussed it multiple times and is
the reason why spf2 was done in the first place) and simple extension
mechnanism of "op" is not good enough in my view.


Agreed.


The only thing the language lacks is a method to say "what
identity does this apply to?" and I believe that can be addressed simply
and well, if taken with a certain amount of deliberation and care.

If we're misunderstanding each other (and it's safe to say I didn't
understand one or more things you wrote on this thread) it's probably
because I was assuming the above context.  Sorry if I was unclear.
This is not intended to be bolted on to v=spf1, it's intended to be a
brainstorming  session for a future superset/extended application of
SPF's ideas.

Unfortunetly so far you have not told us anything specific. I remind
you that unified spf proposal was quite specific as to what scopes,
(even if not full developed)


Right, I was purposely leaving that vague because I want people to think of
scopes I haven't thought of.  Right now I want the possible values for "Scope"
to be "Anything that can be used in a message or envelope/transaction, and
contains a domain name".  It's even possible that new headers will appear, or
even new extensions to ESMTP (remember FRED^W DAVE) -- I want to be compatible
with stuff people might invent in the future too.  As long as it contains a
domain name, and might resonably benefit from a sender policy.


Actually that is exactly where I was going with the topic.  Yes, I know
it won't happen any time soon, but I expect it will happen eventually.  I
predict v=spf1 will probably be replaced by something else (hopefully
something better) in the next 1-2 years.

First of all its possible to create such an scoping extension that
it is compatible with spf1 and does more then just yes/no of "op" and
that could possibly be introduced in 1-2 years. If completely new syntax
is introduced I would say that within "1-2" years is too optimistic:
2-5 is more like it.


Possibly so.  We could possibly shorten the time by being ready for it.  (It
could be exactly 2 and we'd both be right :)


I think SPF is equal to the task (just not v=spf1).

SPF is probably not equal to the task of very generic email policy record.
You probably would want easy to extend with generic names policy server
(with records that would be larger that what you can do with dns) -
most likely XML along what MS proposed, in fact I dsicussed that with Bob
Atkison (original CID designer) at ASRG back 2 years ago and he proposed
using soap server (obviously MS likes soap) where as I think more general
xml that is not bound to soap will do just fine. The question is if that
generic functionality is what we want or if multiple scoping for specifying
primarily domain->ip policy and some extensions with mechanism is ok.


I think I agree that we don't want to go *too* generic.  It should be
primarily focused on domain->ip.


Now everyone is so hopping mad at Microsoft, that they are
avoiding anything that smells like MARID out of sheer prejudice.

And we're better off unless they they reform and understood what they
did wrong. Its not everyone else that was a problem with MARID -
it was MS actions in regards to how it developes technologies and
presents these to the rest of the world.


Actually I blame Doug Otis as much as I blame MS.  We actually had some good
ideas, some good consensus in some areas, and probably could have worked
through them.  Patent issues, and incessant whining and regurgitating from the
CSV crowd, were kind of the one-two punch - either of those issues by itself
might not have been fatal.

But yeah, I know how you feel.  I don't like PRA really, but hopefully PRA
won't get in the way of SPF2.0 much.  If we give people permission to use PRA
if they opt in, and also give them a few other choices too, my bet is that PRA
will atrophy and die.


Yeah, here again I think you're reading a different context in here.
Apologies if I was unclear.  I am not looking to modify v=spf1.  I want
something that will replace both v=spf1 and Sender-ID, and be flexible
enough to apply to other headers too

Introduction of scoping will do it and its then left to those who propose
new scope to specify what record with that scope means and what header
field or other identity it applies to. But as I noted in the beginning you
need to be carefull when talking about unified as to if you want to
develop sender or receiver policy system.


Understood (and agreed :)


Talk to you later.
gregc

--
Greg Connor
gconnor(_at_)nekodojo(_dot_)org

Everyone says that having power is a great responsibility.  This is a lot
of bunk.  Responsibility is when someone can blame you if something goes
wrong.  When you have power you are surrounded by people whose job it is
to take the blame for your mistakes.  If they're smart, that is.
                -- Cerebus, "On Governing"

-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your 
subscription, 
please go to 
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com