Meng Weng Wong [mengwong(_at_)dumbo(_dot_)pobox(_dot_)com] wrote:
But we [could] add a new mechanism that indicates where the full-fledged
XML policy document can be found. If that policy document is present,
it overrides the regular SPF declarations.
xml:_ep.%{d}
Think of it as an "include" with a twist in the language along the way.
If a domain wants to express accreditation attributes that are
inappropriate to SPF, it can do so in the XML space.
That allows all the "v=spf1 -all" domains to not get into XML at all.
I think you've got a misconception here. It's not the domains publishing SPF
records that are "getting into XML". It's the SPF tester libraries.
Thus, XML, its complexity, and its entity/reference/include features (which are
IMO all absolutely irrelevant to the problem that SPF tries to solve, which is
sender address domain forgery) are a wonderful waepon in the spammers' hands to
perform DOS attacks against early SPF adopters (or SPF users in general).
And please don't believe that XML-incapable SPF parsers will be acceptable in a
SPF+XML world. If SPF offers the possibility to domain owners of expressing
their SPF policy (in part or in whole) in XML, there *will* be some domain
owners who will do just that. Following from that, *every* SPF parser *will*
have to fully support SPF+XML, including XML, so to avoid false positives and
negatives (i.e. accidental rejecting or accepting of messages). There's no
such thing as "the best of both worlds" if that means "the simplicity of SPF"
and "the power of XML".
It also allows people to ramp up toward XML compliance while making full
use of the existing installed base.
No. The installed base would be immediately obsoleted if the SPF spec started
allowing an "xml:" mechanism for domain owners to use. See above.
On another note, it's easier to *write* a working SPF parser that it is to even
*learn* XML.
About "extensibility": what's the difference between
| v=spf1 mx -all
|
| becomes
|
| v=spf2 mx newfeature:foo -all
and
| <spf xmlns='http://spf.info/1'><mx/></spf>
|
| becomes
|
| <spf xmlns='http://spf.info/2'><mx/><newfeature>foo</newfeature></spf>
with regard to extensibility?
I just don't get it.
-------
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_)���v¼����ߴ� �1I�-�Fqx(_dot_)com