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

On Fri, 2005-05-27 at 18:22 -0400, Alan DeKok wrote:
> Douglas Otis <[email protected]> wrote:
> > Publishing SPF, even offering low levels of "server authorization," is
> > mistakenly viewed by some as "sender authentication" of the domain.
> > Publishing SPF provides these recipients with what they believe to be
> > confirmations, albeit flimsy, that your domain has actually sent the
> > message.  Publishing any SPF record unfortunately exposes your domain to
> > these widely promoted, but contemptibly false assumptions.
> 
>   Let's correct the false assumptions then, rather than throwing out
> the proposal.  Many people believe putting their computer on the net
> is OK.  When they get viruses, the answer isn't to ban the net, it's
> to fix their beliefs.

One major assumption needing corrected is the assumed scope implied by
an v=spf1 record.  There are vendors able to exercise significant
influence with respect to their view of the scope implied by this
record.  You have another group that feels they can declare a default
scope, in a manner they consider appropriate, albeit in conflict.  Those
holding the Presumed is better than Purported need to recognize they
will not prevail.

A reasonable means to extricate the draft from this situation would be
to depreciate the use of v=spf1, advise its removals, and then document
a new spf2 scope.  Even define a scope like "ADMIN", that indicates
there are _no_ assurances being made within mail stream regarding any
identifier.  It would simply be used to indicate addresses being
administered by a particular domain.  One could say "To ensure this
administrative domain does not accidentally get blocked, apply this to
your white-list." 

> > Not offering this damning confirmation is the only sure means to avoid
> > being assessed in this manner.
> 
>   Not giving people tools is the best way to ensure they won't hurt
> themselves.
> 
> 
>   I find it curious that there's opposition to a "harmful" proposal
> like SPF, but the "harmful" practice of sending unauthenticated email
> from anywhere on the net is called "roaming", and is deemed to be a
> requirement of SMTP.

I would not hand a child a circular saw, and then say don't worry about
pulling this trigger.  SPF is handing a dangerous tool to the domain
owner without advising them of the serious risks they assume when
publishing.  I find that outrageous.

I am not against authenticating the source of email.  The use of SPF
does not authenticate the sender, it only provides "server
authorization" which is being construed as being "sender
authentication."  There are valid alternatives that I would happily
endorse, such as DomainKeys, or even CSV.  A mailbox-domain assertion
depends on too many assumptions to ever be safe as an identifier serving
as a basis for reputation.

>   Weird.

As difficult as dealing with IP addresses are, they represent a stronger
identifier when logged against repeated events of abuse.  They also more
directly impact the administrator.  If there is an open-proxy or address
spoofing situation, perhaps assisted by way of a tunnel, they need to
squelch that problem.  I too would like to see authentication move into
the name space.  As I said, DomainKeys or CSV provides both safe and
fair names that can be authenticated.  These identifiers can be
defended, and do not put the average consumer at risk of seeing their
domain's utility being destroyed by a negligent provider.  Yes,
providers will be required to remain vigilant, unlike that suggested by
some SPF proponents.

>   All I know is that SPF has harmed me a lot less than "roaming" has.
> The endless dribbles of email from clueless people to "postmaster" or
> "webmaster" claiming that my domain has spammed them is tiring.

I offered suggestions that a domain assertion could be added to the CSV
record that indicates all of a domain's emails are signed.  This would
be a lightweight, single lookup extension that could allow any domain a
means to identify any message that purports to be from your domain, but
then must validate their signature.  There are other issues related to
signatures where this would be a useful tool.  

I describe this at:
http://www.kelkea.com/ietf/draft-otis-mass-reputation-01.html

-Doug