In
<2A1D4C86842EE14CA9BC80474919782E01113342(_at_)mou1wnexm02(_dot_)vcorp(_dot_)ad(_dot_)vrsn(_dot_)com>
"Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com> writes:
The pro's need a bit of explanation
Thanks for the detailed and well thought out explanation.
The Extensibility Issue
-----------------------
[...]
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.
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 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.
Basically the sales pitch that is being given here is for
The Readability & Size Issue
----------------------------
I disagree.
My concerns are about complexity, efficiency, and a reliable
understanding of what is going on. I *like* SPF because it has a very
good balance between flexibility and well defined behavior.
From my point of view, XML opens up a huge can of worms, for very
little benefit.
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.
SPF is a good tool that does one thing well: It validates the
envelope from.
If you want MTA Mark, then use MTA Mark. It complements SPF well,
although I personally think that port 25 filtering is a far better
approach to the problem than MTA Mark.
If you want accreditation schemes, or Domain Key type validations of
email, then use something else.
SPF is not the FUSSP.
We can have 50% of email described by SPF records in weeks.
BUNK!
50% of all email is spam.
Take a look at senderbase.org. You will not get the top 10 senders of
email to add *restrictive* SPF records any time soon.
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.
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.
-wayne
-------
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;±¤Ö¤Íµø?¡