Re: draft-schlitt-spf-classic-02.txt

On Fri, 2005-06-10 at 15:16 -0500, wayne wrote:
> Douglas Otis <[email protected]> writes:
> 
> You may have already seen this, but it looks to me like the MARID
> protocol has a little ways to go before it accepted even as an
> experimental standard.  See:
> 
> https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1573&filename=draft-lyon-senderid-core
> 
> While it is quite possible that Microsoft will release Exchange 2003
> SP2 with the MARID protocol despite "the conflicting use of the spf1
> records between this proposal and the SPF proposal is harmful to the
> Internet."  Microsoft is not immune to PR.

SPF defines DNS record handling and syntax, but oddly was not included
in the list of I-Ds considered.  It will fall upon spf-classic to
resolve remaining record scoping conflicts.  Perhaps the next time this
comes up, there will be umpteen million copies of Sender-ID distributed.
Surely you are not surprised by this?

Do not depend upon anyone understanding the "scope" issue, when even the
SPF draft gives this subject such short shrift.  The average person will
trust the system based upon misleading claims made in either draft,
without becoming aware of the factors that may place them in peril.
Explain the dependency on the provider making requisite exclusivity
assurances of determinate mailbox-domains.

As painful as this seems, plan on requesting the v=spf1 records be
removed and replaced with "spf2.0/mfrom".  (Perhaps you could see fit to
define "spf2.0/".)

> Version 2 records were never part of SPFv1, they were never discussed
> in SPFv1 specifications, and so they were never dropped.

These newer records preceded the spf-classic documentation effort, which
is what I meant by dropped at the start.  Do you remember why the newer
scoped record was created?  It seems an understandably hostile decision
to exclude documenting use of this newer record.  Had this scoped record
been defined initially in this series of drafts, it would have been more
widely employed.  You want Sender-ID to be unable to utilize existing
records, and don't want a method to define the scope.  This needs to
change.

-Doug