spf1 parsers should ignore spf2 records and still work with a legal spf1 record if it is present. I don't know how the various implementations deal with possibility of receiving an spf2 record ahead of an spf1 record. If well written, they should still work. A few sites have published both and I haven't heard anybody complain that it makes spf1 screw up.
If I read the Microsoft stuff correctly, you may not need to publish both if they are identical in content (aside from the version and scope). It appears that MS is going to read spf1 records as if they were spf2.
Some people believe this may cause trouble. If your spf1 and spf2 records work out to the same thing, the risk of trouble appears to be minimized. In that case, you may be fine with just spf1.
Trouble would arise if none of the inside headers that the pra algorithm checks has a domain that resolves (through the spf1 record) to the sending IP address. In slightly less picky terms, this means that if at least one of the inside headers pra checks has the same domain part as you set up your spf record for (the domain part of the envelope mailfrom header), you should be ok. For an awful lot of mail, this will be true. The problem is the exceptions. People have identified real world exceptions. For those cases, the spf1 and spf2 records will be different.
One of the little problems with the pra algorithm is that there are many more possibilites with it. With spf1, you are only checking one item, mailfrom (if present, helo/ehlo if not.) With pra, the algorithm goes through 6 (I think, but at least 4) headers to find a match. If you are trying to avoid false failures, you need to make sure that at least one of these is a match. Six times as many moles to whack.
Another little problem with pra is that only one of those headers has to match.
Example:
Sending ip is 123.123.123.123
Envelope
Mail From: ***@devilsRus.com
Body
From: ***@blessedbygod.com
Sender: ***@blessedbygod.com
Resent by: ***@blessedbygod.com
Resent sender: ***@devilsRus.com
devilsRus.com publishes an spfrecord v=spf2/pra ip4:123.123.123.123 -all
pra results in a pass for this scenario. (as does spf1)
Is this functionally any better than checking the envelope sender? Lots of people think not. Substitute
***@welldisguised.com for ***@devilsRus.com and the problem is even more apparent.
The awkward thing will be when somebody publishes an spf1 record, and then claims spf1 is broken because it doesn't work with Microsoft's algorithm. Or, they publish a record tuned for Microsoft's algorith, then expect it to work with spf1. That is where it gets messy. One worry is that MS's PR department may not take responsibility when their algorithm and their documentation lead people into doing things that are incompatible with spf1. It would be awfully easy and tempting for them to push any problems off on spf1.
As of the last time I checked, the Microsoft Sender ID record wizard appeared to lead one to a record that is identical to an spf1 record except for the version and scope. There is some ambiguous language, and an incomplete syntax checker that has lead people to create very poor records. (for example a:123.123.123.123 and mx:123.123.123.123. a and mx are supposed to take domain name arguements, not ip addresses.) I have not yet seen any language in the Microsoft wizard that takes the inside header vs. envelope header difference into account. (Last I checked was a couple of days ago.)
Mark Holm