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

On Tue, 2005-05-31 at 09:49 +0000, Graham Murray wrote:
> Douglas Otis <[email protected]> writes:
> 
> > You can not prevail on an assumed record scope.  Both Sender-ID and SPF
> > attempt to transform "server authorization" into "sender
> > authentication."  If I were to authorize an email provider, would that
> > mean any message using my email domain from that provider be from me?
> 
> I cannot comment on Sender-ID, but as I understand it (as the one who
> publishes SPF records for the domain) SPF does not attempt to do this. An SPF
> pass does *NOT* indicate that the mail is genuinely from the domain (though in
> the cases of the domains I control it probably does as I also control the mail
> servers), but an SPF fail indicates that the mail is definitely NOT genuinely
> from the domain. So an SPF pass should not be counted as sender
> authentication, even domain keys does not do this (it only authenticates the
> domain and that the mail has not been 'tampered with')- if you want to
> authenticate the sender you will have to use an MUA cryptographic system like
> S/MIME or PGP/MIME etc.


Not granting an RFC for Sender-ID will not prevent the promised use of
the PRA algorithm with version 1 SPF records.  While you may not desire
such PRA treatment of your email, publishing _any_ SPF record, as
currently defined, enables use of the PRA algorithm.  The way this use
can be prevented would be to depreciate version 1 SPF records, and to
define scopes with version 2 SPF records that clearly indicate which
identities are 'assured' within messages.  Also add a scope of 'ADMIN'
where no identifiers are assured, to allow the SPF records be used for
purely white-listing purposes.

Being practical, remove the HELO scope from the SPF records.  CSV can
assure a single lookup for this purpose, and CSV offers a mechanism to
declare domain-wide email policies, to increase email requirements of
such things as CSV itself, or email signing, etc.  In this way, CSV
offers DoS protections for any subsequent email extension.

Many have commented that a "benefit" of SPF is it forces abusers to use
their 'real' domain name, so they can be identified and stopped.  This
comment illustrates an expectation that SPF provides "sender
authentication" where an abuser can not forge the mailbox-domain.  While
possible, with add restrictions imposed by the email provider, the
domain owner remains completely at the mercy of an email provider's
diligence at _every_ MTA involved in the transport of the message, and
not just those MTAs that have been directly authorized by the SPF
record.  A mistake on the part of an email provider, such as
misconfiguration of a firewall, and the domain owner's reputation
suffers.

A domain owner will have few resources to know the cause of their
reputation woes, and will need to wait for the TTL of their SPF records
to expire, before ill-advised publishing can be retracted, assuming they
even know which servers are at fault.

SPF offers many shades of gray, such as Pass, Neutral, SoftFail, or
TempError.  An abuser could have their forged messages accepted at any
of these levels.  Reputation and "assumed sender authentication" will
combine to sort out these results.  It is very likely an abuser, finding
they _can_ forge a domain with a published SPF record, will cause the
messages from that domain to become filtered and redirected into junk
folders.  As the reputation factor becomes more significant, there may
then be an outright rejection of the message from the forged domain.

Once the message becomes rejected, meaning the reputation is now badly
tainted, the recovery of the domain for email may be extremely
difficult.  Such a system is sure to cause the integrity of email
delivery to suffer.  Controlling abuse requires the administrator of the
email server to play a critical role.  Essentially, it requires that
they control access to the server.  Use of an IP address or the
DomainKey signature will directly impact the administrator of the
significant (offending) email server.  SPF may not affect such
administrator.  Hence a possible lackadaisical attitude regarding their
obligations. 

To abate abuse, there must be a low tolerance for abuse, and strong
identifications for the source of the abuse.  Once there is any blocking
put in place, it should directly impact the administrator of the email
server causing the problem.  SPF may eventually provide feedback to the
domain owner, but the domain owner may have no ability to meaningfully
respond in a timely manner.  At that point, they may also have no
ability to recover either.

It is not surprising so little is being said about the implied duties
required to protect domain owners when they publish SPF records, or the
potential for the harm that may result.  As far as the email provider is
concerned, the less said the better.  A naive domain owner is willing to
risk their reputation without asking for any indemnification from their
provider.  At this time, there is no SPF record that can be published
without also requiring the PRA be examined and assured.  The many
different mailbox-domains must be limited to those domains allowed for
each authenticated user.  With SPF, providers must vet who is allowed to
use a particular domain, and be sure to enforce each and every identity
that _could_ be used in any SPF related reputation scheme.

The "opt-out" scenario described by Sender-ID is really little more than
a ploy to have domain owners publish PRA specific records.  This record
strategy is already prone to the Machiavellian "user feedback" button.
Ignoring Sender-ID would be at your peril.  At some point, snap.

-Doug