-----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 Meng
Weng Wong
Sent: Friday, June 18, 2004 11:07 AM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] a grand unified theory of MARID
On Fri, Jun 18, 2004 at 10:09:46AM -0400, spf(_at_)kitterman(_dot_)com wrote:
|
| I can do SPF. All this other stuff is going to take more time
than I have.
|
| Please, please, please, do not lead us towards a solution that is over
| complex.
|
Oops; I may have given the wrong impression.
The point of the message was that people can have an easy
choice of what they want to use.
Different sets of people tend to be interested in different
sets of semantics. Using SPF as the common syntax and
protocol for all the different semantics lets all those
people interoperate without unnecessary overhead.
So, the solution is not over complex. People can continue
to implement SPF Classic or SPF-for-HELO (as Hector Santos
will attest) without the need to do anything about PTR or
SenderID or crypto.
I just wanted to take a step back and show what the bigger
picture looked like. When you're exploring an unknown land,
sometimes it helps to climb a tall tree and see where you've
been; that helps you see where you're going.
| Even if it works, it probably won't work for me. If it's to
complex, it's
| unlikely to be reliable enough for people to depend on it.
|
| I fear in trying for everything, you will end up with nothing.
An oven can be used to cook a beef roast, a cake, and
lasagna. I've never made a cake, but if I wanted to, I know
my oven could handle it.
In the same way, the core SPF function can be used to
evaluate the PTR, the HELO, the return-path, the PRA; which
one you actually want to use is up to you.
Of course, under each choice of identity, it's important
that people agree on just what a lookup result means.
Without this agreement, you have chaos. So I will try to
define the semantics in a bit more detail soon.
Fortunately, those semantics will be backward-compatible
with what people are already familiar with.
If what people are talking about is different ways to use the data I provide
in an SPF record to gain more or less confidence that I'm a permitted
sender, that's fine.
I think what concerns me is what is being debated on the MARID list about
extensibility.
1. As soon as the checks are extensible, the result is no longer
deterministic. One thing about SPF Classic that's really smart is to return
error if an unknown mechanism is found. After all, if the reading program
doesn't understand part of the definition of what a permitted sender is,
then there's no way the program can really know if the sender is permitted
or not. It appears that MARID is on the opposite track. I don't see how
that could work. The SPF idea of versioning seems to me to make more sense.
To start from (sort of) the example of a dk mechanism in your original post:
example.com TXT "v=spf1 mx a:relay.example ~all"
example.com TXT "v=spf2 dk -all"
We all know how to parse V=spf1. I, as a small domain owner, can do spf1.
In this case example.com is saying, if it came from my mx or
relay.example.com it's mine. There are a few other cases that aren't
covered by this, so anything else has some chance of being mine. With spf1,
that's the best I can describe it.
Once spf2 is defined, people can start to do that, if they need something
that's in spf2.
This idea from the current spf classic spec is a really good one. It also
accomplished the goal (I think) that John Glube suggested of saying one must
check x, y, and z and one may also use a, b, and c.
We appear to me to share the fear that once the basic syntax has been
extended, use of it's full breadth will become mandatory as a practical
matter of self defense, even if the spec says otherwise. The versioning
approach lets the sender tell the receiver what set of semantics the sender
views as within the scope of their permitted sender definition.
Reading the message you sent while I was typing this, that sounds good and
should be consistent with what I'm saying here. One set of semantics that
the receiver can apply against the data that the receiver has available. My
really comes down to two things:
1. Are solutions that require more effort than I can reasonably put into it
going to be required as a practical matter.
2. Is the syntax stable enough that I know the receivers will have a
consistend understanding of what I'm saying.
Thanks,
Scott Kitterman