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.