Why? The current SPF spec is up to the task it is designed
for, unless
problems arise there should be no need for a series of protocols with
ever-expanding scope beyond the original premise.
How many protocols have you designed. I have worked on HTTP,
XKMS, SAML, WS-Security, WS-SecureConversation, about 6 others.
I very much doubt that the SPF syntax will need a revision so
serious that the version number has to change. But the addition
of new features within the SPF framework is absolutely certain
if it is going to continue.
I am getting seriously worried about supporting SPF if it is
going to be a
'blank cheque' for an ongoing process which draws in all
kinds of 'features'
unrelated to the task of IP-based sender authentication.
With respect, Demon is not exactly the worlds largest ISP. The
proposals being considered by the largest ISPs require accreditation,
yahoo is very keen on cryptographic authentication.
The extensions to the specification are not large, the power
they provide is.
If somebody wishes to publish additional data points in their
DNS for any
other purpose (related or unrelated) they can do so with or
without SPF's
help.
You forget that SPF has claimed the TXT record as its own.
Please don't destroy SPF with feature creep and misplaced
'extensibility'.
Let's please freeze it and concentrate on evangelism and
adoption rather than
creating new opportinities for confusion and incompatibility.
It is not feature creep, the feature set has been discussed
for a very long time.
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
Wiki:
http://spfwiki.infinitepenguins.net/pmwiki.php/SenderPermittedFrom/HomePage
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡