There are two difficulties with this approach. First there
is barely a
process for developing SPF. Who gets to decide what goes
into SPF 1.1?
Who gets to decide what goes into SPF 1.1? The answer is going to be
very similar to questions like "Who gets to decide what goes into
Linux 2.7?" or "Apache 2.1?" or "Bind 9.3?".
Right now, Meng Weng Wong has shown very Linus-like traits of being a
good gatekeeper of ideas. If that trend continues, it will likely be
Meng for a long time to come. If that trend (or Meng) doesn't
continue, there may well be a fork in the standard. Such is life.
And if Meng had being showing other traits (anyone worked with RMS?) we
would not be where we are now.
The big deal with XML is that you can avoid the need to fork.
What
happens if someone makes a proposal for an extension and
the group does not
think it is a good idea? There is no way we can force them
to drop it, they
can go ahead and publish anyway.
Yep, and that is A Good Thing. If the proposal really is good, it
will be adopted even if the old-guard objects, and if it isn't a good
proposal it will be ignored.
The old guard have done a great job stopping people adding SPF semantics to
email for the past five years since Paul Vixie made the first proposal.
Too many good ideas have been dropped on the floor.
The second problem is that we have tried this mechanism for
extension in the
IETF in the past and it has never worked in practice.
Where is Jon Postel when you need him? *snif* :-<
That said, I can't see things changing much faster no matter what the
structure of creating standards is. There is too much legacy code out
there and too much cost of upgrading.
In the XML world we generally get standards turned round within 19 months
from start to finish with multi-vendor interop taking place about 12 months
in.
From my point of view, XML opens up a huge can of worms, for very
little benefit.
Yes, from your point of view.
There is another point of view and the company that holds it has a lot of
dollars to put behind pushing a solution.
What if we want to go beyond that capability? For example:
* MTA Mark like description of IP address use
* Accreditation schemes
* Domain key type authentication
I personally don't want to see *any* of those put into SPF.
Absolutely not.
But they should be in the complete solution package. If you don't want to
see them in SPF it is better to put them in a separate schema.
We can have 50% of email described by SPF
records in weeks.
BUNK!
50% of all email is spam.
OK 50% of the real email.
Take a look at senderbase.org. You will not get the top 10 senders of
email to add *restrictive* SPF records any time soon.
We will if we get this party on board.
If you think the state of SPF code to *check* SPF records is ready for
prime time in a matter of weeks, you are sadly mistaken.
Get the records published, all else will follow.
You are dangling a carrot out in front of people, hoping they will
follow a direction that they would not go on their own free will. I
hope people will see clearly enough to realize that nothing is going
to be so simple that we can get anything like SPF widely deployed
within months.
This would be so much easier if the people who want this issue could argue
the case themselves.
Phill
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡