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

In <[email protected]> Douglas Otis <[email protected]> writes:

>> >> The draft-schlitt-spf-classic-* series of I-Ds is an attempt to
>> >> document what is, not what should or could be.
>> >
>> > This is not entirely true.  This draft can still recommend deprecating
>> > the use of version 1 records, and document how version 2 records ARE
>> > being used.  
>> 
>> The whole point of spf-classic-* is to document how SPFv1 is being
>> used.  From what I can tell, version 2 records *aren't* being used,
>> and therefore the MARID protocol *isn't* being used.
>
> Does this change you mind?
> http://informationweek.com/story/showArticle.jhtml?articleID=164301210

Considering that I posted a link to a similar story on the spf-discuss
list when the MS PR went out, no, of course it doesn't change my mind.

Note that I when I said "from what I can tell ... the MARID protocol
*isn't* being used", I used the present tense, while that article
talks about the future.

> Hotmail only publishes v=spf1 records, by the way.  Consider the impact
> the announced program will have.  It is irresponsible to ignore this.

I have not ignored this.

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
experiemental 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.



> While you may espouse some ideal for what is contained within
> spf-classic-*, there have been extensive efforts to re-engineer SPF
> within this document's many iterations.  Dropping version 2 records from
> the start,

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


>            redefining record limits,

The record limits have existed in the libspf2 implementation (the one
I wrote) since Feb 2004, long before MARID was even opened.  It is my
understanding that some other SPF implementations have also
implemented these limits.  This is an existing practice, and a change
to the spec that I feel is needed in order to make sure that SPF can
not be used as an effective DoS amplifier.  Yes, I did studies of the
actual packets when I came up with these limits.  Unfortunately, that
study was done a year and a half ago, and don't have all the results
now, just the conclusion.


>                                      depreciating the wildcard,

I'm not sure what you mean here.  SPF doesn't use wildcard DNS
records. 


>                                                               , adding
> zone-cuts, removing zone-cuts,

Zone cuts were indeed added to the mengwong-spf-01 draft a over a year
ago, and they were indeed removed from the schlitt-spf-classic-02
draft because they were not widely implemented and they were not
popular with the folks on namedroppers.  Several other unused features
have been dropped from the schlitt-spf-classic-02 I-D.  I think this
is a good thing, YMMV.

>                                changing HELO handling, and then changing
> HELO handling again.

Since the Dec 2003 "frozen" spec of SPF, the HELO handling has been
changed from "when MAIL FROM is null", to "MAY be done always" in
mengwong-spf-01, to "RECOMMENDED to be done always" in
schlitt-spf-classic-02.  SPF implementations that follow the Dec 2003
spec are still compliant today.


>                       Documenting version 2 of the SPF record may
> diminish an illusory claim of greater acceptance.  However, when
> Sender-ID uses v=spf1 records, these claims reveal only wishful
> thinking.

I'm not involved in the documenting of the spf2.0 records.


> Perhaps I should recommend an spf2.0/admin white-listing record.  In my
> view, the only safe use of SPF would be for white-listing, where this
> should also have an explicit scope for this use as well.  Such a
> white-listing scope may in effect say "Do not base my customer's
> reputation upon any server authorization, as mailbox-domain exclusivity
> is not assured."

Feel free to write up an I-D saying so.  



-wayne