ietf-mxcomp
[Top] [All Lists]

Re: Comments on draft-ietf-marid-core-01 xml use

2004-06-04 13:41:53

In 
<81AC085044D04B429F5FB883D94FA1AF30CFC9(_at_)df-fido-msg(_dot_)exchange(_dot_)corp(_dot_)microsoft(_dot_)com>
 "Jim Lyon" <jimlyon(_at_)exchange(_dot_)microsoft(_dot_)com> writes:

 
Ryan Ordway asks how XML extensibility differs from a hypothetical
version of SPF that ignores both mechanisms and declarations that it
doesn't understand.

The major difference is that the XML (as specified) has more
extensibility points.  [...]

Now suppose that there is an extension that gives feedback to the
publisher when various mechanisms fire.

You mean like the "report=" modifier that been on the SPF website for
something like 9 months?  See http://spf.pobox.com/extensions.html

Note that this is an extension and not part of the SPF spec.  To the
best of my knowledge, no one has implemented it.  The demand for such
a feature has been largely theoretical.


We could invent new SPF syntax to accomplish this like:
   +mx  
-exists:%i.blacklist.example.com/feedback=forgeries(_at_)example(_dot_)com
?all/feedback=ToAnalyse(_at_)example(_dot_)com

First, it may come as a surprise to many people, but it is perfectly
valid to have a domain name that contains slashes, equal signs and at
signs.  They aren't valid *host* names, but they are valid domain
names.

Second, you are making things way too complicated and are over
designing things.  The data available via the report= extension to SPF
gives you everything you need to know, it doesn't require any changes
to the SPF syntax and it has better thought out semantics.

Third, I do not like the SPF report= extension because I *really* do
not think it is wise to send email off to random email addresses at
the request of a possibly hostile third party.


In summary, XML gives us more, and better-defined, extensibility points
than anything we're likely to dream up ourselves as extensions to SPF.

And I have yet to hear of a single example of XML extensibility that
I would consider useful.


In a closely related message, 
<7BD19F59D0DA4C448B0C4BBE78C35BE30A8A59(_at_)DF-SEADOG-MSG(_dot_)exchange(_dot_)corp(_dot_)microsoft(_dot_)com>
 "Bob Atkinson" <bobatk(_at_)exchange(_dot_)microsoft(_dot_)com> writes:

I can tell you that, having worked on Caller ID for more than a year and
a half, and having had it basically stable since a year ago, I
continually and routinely keep coming across valuable new things that
people will want to say about these sorts of policies. 

Weird.

I have actually come to the completely opposite conclusion having been
involved with the SPF project for a long time.  I've heard of lots of
ill-considered and harebrained ideas, but almost no extensions to the
SPF spec that is really useful since it was frozen late last year.



If you want examples, take a look at the attributes we have on the
Caller ID <m> element to today. Or think about what one might wish to
say about ones willingness or desire to participate in forensics
gathering to support prosecution of spammers. And so on.

Ok, I've thought about it.  I don't see anything that can't be handled
just fine with the SPF extension system.  Can you please give some
examples? 



Many people on this working group have complained about how big and
complicated SPF is.  SPF is actually *FAR* more complicated than I
would really like to see.  However, when SPF was being developed,
there was a constant pounding to try and keep it simple and keep it
well defined.  Most of the stuff that has survived into the SPF spec
has been stuff that is really needed to cover very important use
cases. 

I really think that SPF is very close to the smallest functional set
of features needed to do domain name usage validation.  Things should
be as simple as possible, but no simpler.


For people who initially looked at SPF as being bloated and having a
bad case of creeping featuritis, it might be surprising to learn that
the vast majority of people in the SPF community STRONGLY oppose any
inclusion of XML in a merged Caller-ID/SPF spec.  XML has been
considered by the SPF community in the past and didn't withstand the
pounding.  The inclusion of XML in any IETF RFC may very likely cause
a split in the SPF community or a complete abandonment of support by
the SPF community in such an RFC.


-wayne