Proposed Remedy
===============
Change the relevant part of draft-lyon-senderid-core-01, section 3.4
"Compatibility", to read:
Sender ID implementations MUST interpret the version prefix "v=spf1"
as equivalent to "spf2.0/mfrom", provided no record starting with
"spf2.0" exists.
In any case, draft-lyon-senderid-core should not be published until this
conflict is resolved.
The proposed remedy is the only correct one. However, MS will be
determined to make use of all those SPF records in the field.
I don't know where to send helpful suggestions to MS, but I can see two ways
to meet their own alleged goal of anti-phishing by using the SPF deployed
base without destroying it:
1) Cause Outlook & friends to display Return-Path in place of Sender
when the PRA cannot be authenticated (NONE), but MFROM gets a PASS.
2) "Make it so": Add/replace Sender to make PRA match MFROM from when
PRA cannot be authenticated (NONE) but MFROM gets a PASS.
The above might also be useful when PRA gets a NEUTRAL, but MFROM gets a PASS.
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.