spf-discuss
[Top] [All Lists]

Re: Draft IETF appeal

2005-08-24 05:48:46


Stuart D. Gathman wrote:
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.

Practically what you just did was make the PRA check the MFROM in some cases. Only you don't get the SMTP time rejection. And you laden the MFROM check with IPR. And you don't get the supposed anti-phishing protection that comes with PRA.

I don't see it as a positive accomplishment.



--
Terry Fielder
terry(_at_)greatgulfhomes(_dot_)com
Associate Director Software Development and Deployment
Great Gulf Homes / Ashton Woods Homes
Fax: (416) 441-9085