RE: SenderID and v=spf1 - Please say NO

I agree with the sentiment I think Phillip was trying to express.  I for 
one feel that if MS wants to use v=spf1 records for their own purposes 
(whether it be for SPF classic, SenderID, or getting rid of scuff marks on 
their floors) we can't really prevent them, and we shouldn't try.
For one thing, SPF is an open standard, and comes with no license, patent, 
or other restriction that would allow us to control how anyone uses it.  It 
has always been free and open and even though MS has played the patent game 
with their stuff, SPF's authors have not, and I don't believe they should 
start.  If they want to use published SPF records for something other than 
SPF Classic, how would we prevent them?  By going to the right meetings? 
By being really vocal here on our little list?  By trying to sue them?  The 
reality is that if anyone wants to use SPF for something other than 
checking return addresses, we can't really stop them.  If it doesn't work 
well, they are the ones that have to deal with it.  (If for some reason it 
*does* work well, that might be an extra added bonus).
For another thing, why would we want to discourage more uses of SPF, even 
ill-advised ones?  It sounds like the worst thing that could happen is that 
it works poorly and some people come away from it thinking that SPF is 
itself bad.  But, at the same time SPF will have received some attention.
So.  I really think that if people want to use v=spf1 records for other 
things, they should not be prevented.  This is the sort of thinking that 
led to Unified SPF and scope tagging which I still think are good ideas. 
For anyone who has looked at Unified and thinks it might be a good idea, 
this is really along the same lines... use the SPF toolset for other jobs.


Now.  That said, if MS proposes CHANGES to SPF to accomodate them, that is 
totally another matter.  I won't go into that here, because it is highly 
dependent on what the actual change is... but I think I can safely say that 
pretty much everyone that actively supports SPF would reject any changes 
that break anything, or fail to add substantial value to SPF itself.
As with anything MS does, if they decide they want to make use of all the 
published v=spf1 records for some other purpose not supported by SPF 
drafts, there is always the risk that they will "embrace and extend" by 
adding unofficial new options/keywords/mechanisms/whatever to their 
interpreter.  Given that we can't prevent them from using v=spf1 records 
for whatever purpose, this may still come to pass despite what Meng does, 
or what any of us do.

--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>