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

On Thu, 2005-06-09 at 20:34 -0500, wayne wrote:
> Douglas Otis <[email protected]> writes:
> 
> > On Wed, 2005-06-08 at 21:12 -0500, wayne wrote:
> >> Douglas Otis <[email protected]> writes:
> >> 
> >> The above language for "Pass" is actually somewhat less strict than
> >> the responsibilities assigned in the draft-mengwong-spf-* drafts.
> >
> > The results remain unchanged. "Considered responsible for sending the
> > message" represents an irresponsible conclusion.  What assumptions
> > permit this conclusion?  Is it the domain owner that should know better
> > than to trust their email provider?  Or is it the recipient that should
> > know better than trust the mailbox-domain to be legitimate?  The
> > statements in the introduction and what is implied by a Pass condition
> > will result in considerable harm.
> 
> Well, SPFv1 has been deployed by thousands of domain owners since
> early 2004.  After a year and a half of experience, only a very few
> people seem to think this risk is significant.  I'm not going to
> debate this issue with you since we have done so in the past and I see
> no productive result of debating it again.

While you may have an opinion that risks of being mistakenly attributed
for abuse is small, you should still offer a warning.  Unfortunately
your Introduction and description of PASS contributes to this risk,
rather than providing requisite cautions.  I doubt those finding
themselves blocked will be comforted by claims their situation is not
significant, nor worthy of consideration.

Due to this lack of concern, their provider was not made aware of the
added requirement of assuring mailbox-domain exclusivity to guard domain
owner's reputations.  You should also be aware of programs being
announced that will increase the level of risk that continued spoofing
may cause.  I am not asking you to anticipate the actions of an abuser,
but rather read announcements of major vendors.

Consider where this is headed.  Unlike IP address reputations, domain
names may be treated on a more permanent basis, perhaps waiting for
evidence of ownership change.  A reputation based upon the domain name
also provides no alternatives.  Unlike a bad reputation for an IP
address, a bad reputation for a domain name, even for a brief period,
could be extremely damaging.  In addition, there is no practical method
for restitution, as these authorization/reputation systems will likely
be processing the SPF record's multi-level results using a
filtering-paradigm.  This strategy may route a large number of messages
into a never visited junk folder. : (


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

While I am pleased to see the majority of major providers avoided
publishing either version of an SPF record, there is always the
possibility some provider will attempt to assert influence by way of
acceptance criteria, perhaps found in some setup menu.  Review AOL,
ReturnPath, DoubleClick, or Skylist for examples of spf2.0/pra records.
Hotmail only publishes v=spf1 records, by the way.  Consider the impact
the announced program will have.  It is irresponsible to ignore this.

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, redefining record limits, depreciating the wildcard, adding
zone-cuts, removing zone-cuts, changing HELO handling, and then changing
HELO handling again.  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.

A claim of SPF versus Sender-ID acceptance would be possible, only by
allowing the scope of the record to be explicitly declared.  Once it
becomes understood that providers must assure mailbox-domain
exclusivity, and unless there is a means to ensure the PRA is not
assumed, a responsible provider has the option of licensing the PRA
algorithm or not publishing SPF 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."


> >> > 2.4.  Checking Authorization
> >> > ...
> >> > ,----
> >> > | Without explicit approval of the domain owner, checking other
> >> > | identities against SPF version 1 records is NOT RECOMMENDED because
> >> > | there are cases that are known to give incorrect results.
> >> > `----
> >> >
> >> > Do you really think this sentence will cause a company to change their
> >> > released version of Sender-ID?
> >> 
> >> I don't know, but I do think that it is important to let people know
> >> about the dangers.
> >> 
> >> I think it is likely that developers will need to update their MARID
> >> protocol implementations anyway.  Instead of using the marid-protocol
> >> document, they are now using the spf-classic document, and these two
> >> documents are not completely compatible.
> >
> > When you say MARID, do you mean Sender-ID?
> 
> Yes, when I say "the MARID protocol", I mean what was one called
> Sender-ID on this list.  Andy checked with the powers that be within
> the IETF and they said that another name should be chosen due to the
> trademark conflicts with Sender ID.  I am simply trying to follow
> that request.

I'll refer to the draft-lyon-senderid-core as Sender-ID to avoid
confusion.  I am not writing a spec using this term, nor making claims
of use or ownership.

-Doug