Thanks for your explanation Meng,
OK, I think now I understood your point of viewing. You want to make it
possible to use all the technics, but it is not nessesary to use them.
This seams to be bether then that what I understood in your first mail.
There is only one thing: If some people think the one technic is
nessecary and publish the records like that (in SPF style), some others
think another thing is important ant publish it like that (even in SPF
style) and do not care about the first. Then we have the same problem
like with the SPF/CallerID/DomainKey. On a technical level I mean, on a
political level it is bether because the people want to work together.
Finaly I can say only: lets wait and have a look what happens. Now I
think you are doing your job well Meng.
Thanks
Teddy
Meng Weng Wong wrote:
On Fri, Jun 18, 2004 at 05:43:31PM +0200, Teddy wrote:
|
| In your text here you have used many things that I've never seen and
| heard before (MTAMark/SS, DRIP and CSV). So I was not able to follow all
| your ideas.
These are proposals that have been presented to the IETF.
| already have deployed. You would call it "SPF Classic". Me in my
| position I do not have time, need, monay and nerves to program a more
| complex solution. Why should I? Because you would be happy if you can
| say my peoples have all implemented and it is running. No, for me this
| is no reason.
I should explain the motivation for presenting a "Unified
SPF".
I am not the one who wants the complexity. The people in
the IETF working group want it. There are people in the
IETF working group who think that PTR authentication is the
important thing. There are people who think that HELO
authentication is the important thing. Even though they are
in the minority right now, I am trying to reconcile all the
points of view and make them all possible. A lot of people
(in the SPF community) think that return-path authentication
is the most important thing. I agree with them. A lot of
people (at Microsoft, and elsewhere) also think that PRA
authentication is the most important thing, and that
explains the interest in SenderID. They may be right.
It is more likely that if different people see different
thing as important, then they are all right.
I want to extend SPF to make it possible for them to do what
they want, without requiring anything more from anyone else.
| Even if you continue your way to a super complex thing that noone can
| administrate (and perhaps noone can implement correctly), I wish you all
| the best on your way, but I won't come with you. I don't need it.
You are correct, but there is no need to see this change as
a negative.
In North America at the beginning of the 19th century,
railways were everywhere. But different railway companies
had different gauges: the space between the rails was
different. There were nine different regions and they all
had different widths, from three feet to six feet. This
made it impossible for railway cars to travel between
different networks. But within each region each railway
company said "what's the problem? We don't care about going
there."
But by the beginning of the 20th century gauge sizes had
been standardized to 4'8.5". This was a huge conversion
effort: all the incompatible track had to be converted, and
the trains had to be adapted. But they did it anyway. One
company even converted 300 miles of railway in a single
night.
From the point of view of just one rail company, after
standardization, the rail system became "a super complex
thing that noone can administrate" --- certainly not by a
single entity. And a railway company may have said "so it
may now be possible to run a car from Boston to San Diego,
but I won't do that. I don't need it." But that's not the
point: it is not mandatory; it is simply possible.
So right now there are many different "regions", or
identities, and each one uses a different gauge size. CSV,
DRIP, and DHVP are like railway companies that run in the
HELO region, and each of them uses a different gauge, or
record type. RMX and DMP run in the return-path; one uses
block queries and one uses factored queries. Caller-ID ran
in the PRA, and used XML. And so on.
What I am trying to do is make it possible for SPF to serve
as the standardized gauge size in all the different regions.
Just because you can go there doesn't mean you have to: if
you don't want to do CSV-style HELO checks, you don't have
to; if you don't want to do MTAMark-style PTR checks, you
don't have to. You can keep running Classic SPF without any
modification. I am just trying to build roads for people to
travel down. If you don't want to travel down a certain
road, all you need to do is not travel down it: you
shouldn't prevent other people from trying.
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Send us money! http://spf.pobox.com/donations.html
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
--
Teddy's Computerworld http://www.teddy.ch/
Himmelrainweg 2 mailto:teddy(_at_)teddy(_dot_)ch
4450 Sissach 076 383 80 60