ietf-mxcomp
[Top] [All Lists]

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

2005-06-10 13:17:12

In 
<1118430695(_dot_)8892(_dot_)115(_dot_)camel(_at_)SJC-Office-DHCP-156(_dot_)mail-abuse(_dot_)org>
 Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> 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