In <B2AE0E26-20B4-11D9-A608-000393A56BB6(_at_)glyphic(_dot_)com> Mark Lentczner
<markl(_at_)glyphic(_dot_)com> writes:
I didn't even think the original posting of this thread deserved a
response. I think a lot of vitriol has been posted here as well. It
is getting way out of hand.
First, some short responses:
- The way I see it, the one who writes the spec, *is* the one who sets
the standard. But only if that spec is the one that is accepted.
Yep.
I accept spf-draft-200406 as an ok spec for SPF-classic. Even though
the wording and such is much better in draft-lentczner-spf-00, it has
way too many problems and incompatibilities with spf-draft-200406 to be
accepted.
- Where did I get the authority to write the spec? Because I've
worked my tail off on this project.
You and *a lot* of other people.
Because I've done more than just
quibble and add my two cents to every thread on this list. Because I
did a helluva lot for SPF.
Ok, I understand. It isn't important to post to every thread....
- Everything I've done leading up to draft-lentczner-spf-00 was done
completely in the open on this list. Everything. Every question,
every decision.
I'm not sure if many (any) people have said this is a problem...
- Sorry, Wayne, you are way out of line: Not only were you not the
only voice I heard from, you were hardly a voice I heard from. You
didn't "gnash your teeth" until the absolute last minute possible.
And in any event, many people offered other opinions than the ones you
have.
Oh, wait, because I didn't post to every thread, my voice was barely
heard. Wha'?
Are you going to claim you didn't understand my concerns before I
posted the list? Are you saying that I should have known that you
wouldn't make draft-lentczner-spf-00 compatible with spf-draft-200406?
We have talked about these issues *a lot*.
- Sorry all: Sometimes a spec writer has to make a judgment call and
the answer may not be popular. I said this would happen up front, so
no one should be surprised. I believe that the standard itself has to
hang together and sometimes that requires overriding one thing over
another.
Again, I'm not sure if many (any?) people have ever said that
compromises aren't needed. spf-draft-200406 is full of compromises
and things I really don't like, but I can deal with it.
- As to my supposed absence last Winter, it is grossly overrated. I
may not have been posting here much, or able to attend some of the
meetings. But, rest assured, I was pretty involved in what was
happening and reading all versions of the standard produced.
Uh huh... You weren't very involved when Meng and I were I-Ds
submitted right before IETF-59 or right before the MARID interim
meeting. On IRC a while back, you said that you didn't think you ever
saw a draft with the zone-cut stuff, but now you claim you were pretty
involved and read everything.
Ok.
Now, some big issues:
SPF is at a crisis. This group is out of control, and not because I
wrote a draft. This group has no leadership, no direction, and almost
no practical output. This group is rapidly making itself useless.
Dude. SPF-classic hasn't changed for months. What are you expecting?
The first major mistake is that we have no practical product. SPF as
a spec is still full of problems: It hasn't answered the issue of
forwarders, needing SRS, or a practical way for receivers to
whitelist, or some other solution. (Don't reply with your favorite
solution -- the fact that we are still discussing solutions shows we
haven't solved it.)
You are right, there is still a problem with forwarders and roaming
users. This has been thought about a lot by many people. There *are*
still somewhat new ideas being brought up, such as the SES exists:
check. However, I think the problems with forwarders and roaming
users is highly over rated. The amount of email that is being checked
against the trusted-forwarder.org DNSWL is almost scary.
In general, SPF works. I believe in SPF because I've seen data.
Don't be so negative.
The SPF spec is complex due to speculation about
need, not actual need.
This is bunk.
There are *very* few features of SPF that aren't being used. Unknown
mechanisms is about the only one that isn't being used at all. The
split characters in macro variable expansion is lightly used, but it
enables pobox.com to do what users want.
We have talked about the things you would like to see removed from
SPF. Frankly, I think it just shows your lack of practical knowledge
of how SPF is being used.
While there are some implementations, there is
really nothing we can tell someone "drop this into your MTA, set it
and forget it". There are too many caveats, and any user is going to
have keep vigilant.
Uh, that's true for most things involving email, spam, and phishing.
The second major mistake is that we have been far too quick to abandon
our leadership.
I don't think it is quick at all. People have been warning about the
dangers of dealing with MS for a long time. It has only been recently
that Meng's support of the PRA with its bad license has caused a lot
of grumbling.
Ok, there was also Meng's support of XML in DNS that almost caused a
fork in SPF, but that was solved by the IETF telling MS that XML was
out. Meng didn't help much to keep that problem from spinning out of
control.
Unfortunately, we don't have the IETF to tell Meng that the PRA
license is bad this time. Meng is again letting things spin out of
control. Oh well.
Meng is only continuing to pursue the dual-identity
Sender-ID that as recently as September was still in favor.
It was in favor by some, but I've never seen the support for
Unified-SPF that I've seen for SPF-classic. The support for
Unified-SPF is stronger than the support for just the mailfrom and PRA
scopes (dual-identity).
Basically, I think you (and Meng) overestimate the support. It isn't
outright hostile, but it isn't generally "in favor" either.
Don't you all see? We won the
battle: MS didn't steam-roller Caller-ID over the industry and it is
because of our efforts. Now we can implement SPF on a level playing
field with MS's PRA.
No, I don't see that we won a clear victory, let alone won the war.
But, by rejecting Meng as leader, we have
jeopardized the whole project.
Are we rejecting Meng, or is Meng rejecting us?
It is time to stop adding features. It is time to
stop re-hashing features. Basta!
Well, I completely agree with you here Mark. That is why I can see
absolutely no reason for all the "features" you added to
draft-lentczner-spf-00 that weren't in spf-draft-200406. I see
absolutely no reason why you would create an "SPF-classic" spec that
is so incompatible with classic SPF.
SPF needs implementations, web pages, test suites, F.A.Q.s, on-line
checkers, record wizards, documentation, press releases, seminars,
cool graphics, and a spec writer. It is time for many people to step
up to the plate and start doing all this work that is needed, even if
SPF isn't perfect in their view. It is time for a few people to step
up and lead those efforts. It is time for us to rally behind one
person with a vision that can keep this project moving forward.
There are lots of SPF implementations. Granted, they implement
classic SPF, not your SPF-classic. Wouldn't it be easier to create a
compatible spec than to make everyone rewrite their implementations?
There are web pages.
There is a test suite, but despite my best efforts, Meng doesn't use
it and James abandoned it a while back. Others have used it, but it
is kind of depressing when Meng's "reference implementation" doesn't
use the test suite and doesn't even pass a lot of the tests.
There are FAQs.
There are online checkers.
There are record wizards. Fortunately, most of them work, unlike MS's
wizard.
Documentation isn't that bad.
Press releases and seminars are things that F/OSS projects are never
very good with.
I don't see where "cool graphics" comes in.
And, you have claimed the mantel of being the "spec writer".
Basically Mark: Quit your whining and stop being so defeatist.
-wayne