Sorry. That didn't come out formatted too well. Here is a second try.
Here are three lines of objection to Microsoft using or promoting the use of
spf1 records with SenderID algorithms:
1. Technical
Boils down to: It may work poorly. You already know the gory details.
2. Social/political
Organizations that publish spf1 records have done so in the understanding that
they were supplying information to be used by the spf1 protocol. There is no
legal prohibition on using that information in other ways, but there is a
social obligation to respect the actions and intentions of the publishers.
(stress the latter clause of that sentence, not the former.)
There may actually be legal liability attached to using spf1 records in a way
not intended by their publishers, if that use turns out to harm the publishers
in some legally tangible way. For example, shutting off email communications
between a supplier and customers because of faulty use of spf records might
result in an actionable situation. An email service provider who implements
the spf1 protocol for checking spf1 records would be in a more defensible
position than one who implemented another protocol for checking the same spf1
records. It would be easier to argue negligence against a company that used
spf1 records in a way not envisioned in the published spf protocols.
3. Also social/political
spf1 has been developed independantly of Microsoft It isn't very polite of
them to put their experimental protocol to work on spf1 records that were not
designed with their protocol in mind. This is especially true when spf is
still in a developmental phase. It is generally not polite to muck about with
someone else's experiment, even when that experiment is being conducted in
public. The approach you have all been working toward, of getting an
experimental RFC, has to add weight to this argument.
Probably the most correct statement that can be made is that spf1 records were
not designed or published with SenderID in mind. SenderID may produce
unintended results when used with records designed for spf1. If SenderID turns
out not to work well with spf1 records, it is primarily Microsoft's
responsibility as the developers of SenderID to:
A. publish another record specification that does work with SenderID and
that is independent of spf1
or
B. fix SenderID so that it works correctly with spf1 records
Publishing separate spf1 and SenderID records is the best short term way to
avoid problems with either or both protocols. Future work may allow record
consolidation, but at this time, there is no verified or reliable way to do so.
Mark Holm