draft-schlitt-spf-classic-02.txt

1.  Introduction
...
,----
| An additional benefit to mail receivers is that after the use of an
| identity is verified, local policy decisions about the mail can be
| made based on the sender's domain, rather than the host's IP address.
| This is advantageous because reputation of domain names is likely to
| be more accurate than reputation of host IP addresses.  Furthermore,
| if a claimed identity fails verification, local policy can take
| stronger action against such e-mail, such as rejecting it.
`----

2.5.3.  Pass
,----
| A "Pass" result means that the client is authorized to inject mail
| with the given identity.  The domain can now, in the sense of
| reputation, be considered responsible for sending the message.
| Further policy checks can now proceed with confidence in the
| legitimate use of the identity.
`----

This is where SPF and Sender-ID make a very serious mistake.  This
assumes "server authorization" is equivalent to "sender authentication."
It would be like me making a declaration that the postal service is
authorized to deliver my letters, where recipients are then claiming any
letter received from the postal service bearing my name is authentically
or genuinely from me.  Of course that would be a false assumption, yet
this draft describes the sender as "considered responsible for sending
the message."  Review the many assumptions being made before arriving at
this conclusion.  This false assumption is also why publishing SPF
records is unwise for the majority of domain owners.



2.1.  The HELO Identity
,----
| The "HELO" identity derives from either the SMTP HELO or EHLO command
| (see [RFC2821]).  These commands supply the SMTP client (sending
| host) for the SMTP session.  Note that requirements for the domain
| presented in the EHLO or HELO command are not always clear to the
| sending party, and SPF clients must be prepared for the "HELO"
| identity to be malformed or an IP address literal.  At the time of
| this writing, many legitimate e-mails are delivered with invalid HELO
| domains.
|
| It is RECOMMENDED that SPF clients check not only the "MAIL FROM"
| identity, but also separately check the "HELO" identity by applying
| the check_host() function (Section 4) to the "HELO" identity as the
| <sender>.
`----

There is an expression, when your only tool is a hammer, everything
looks like a nail.  While checking the HELO may extend the use of name
reputation into the initial exchange, the use of SPF to confirm the HELO
is using a rather heavy hammer.  The need for checking the HELO would be
to protect network resources using a unified name reputation service.
The potential for hundreds of DNS queries to resolve something as simple
as HELO means this scheme has a rather basic flaw.

While there is no reason for SPF to define how results are tallied,
effectively this check could double an already sizeable overhead.  Would
the HELO override the MAILFROM?  With respect to finding a means to stop
abuse at the source, the HELO would prove more useful.  However, SPF is
poorly suited to fulfill this function.

The prior justification for attempting to resolve the HELO was limited
to the handling of a DSN message with a null MAILFROM.  With SPF failure
expected in this case, wouldn't something like BATV be more effective in
this situation?



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?  Sender-ID advocates will be quick to
indicate they use both methods looking for any authorization.  This
becomes potentially a disaster when reputation is then misapplied, due
to there being a lack of sender assurances.  If you insist at retaining
the v=spf1 record, providers should expect needing a license to assure
the PRA.

I fail to see the justification for not offering a positive means to
express the scope of the record.  Depreciate the version 1 record.  Both
SPF "new classic" and Sender-ID may continue to utilize these older
records.  Moving forward, a scoped version of the record offers a safer
approach.  It would also permit SPF records to be used for white-listing
only.

There have been many technologies thwarted by a large company's ability
to dictate the definitions they promulgate.  A large company may not be
right or fair about their selection.  Something as simple as data
compression caused sizeable losses by a last minute imposition, even
when eventually adjudicated as unfair.  Accept this banal reality.

-Doug