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

On Wed, 2005-06-08 at 18:20 -0600, Aredridel wrote:
> > 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.
> 
> If there were only one post office, not many millions, the analogy might
> be more accurate.

There is certainly more domains than mail servers.  If the average
server were to handle just two domains, this still leaves considerable
room for disputes to arise.  From the perspective of a reputation
service, it is impossible to know either the number of domains sharing
the server, or what identifiers were assured.  Reputation can be very
destructive when attributing abuse to the wrong entity.


> It's not entirely firm authentication, but it's sure better than having
> no information at all. . . But would you take less than fully secured
> crypto, or is the perfect the enemy of the good in this case?

SPF does not offer authentication.  Publishing this SPF authorization
record can be much worse than not publishing, when used beyond just
white-listing.  With spammers and phishers already among the first to
offer SPF records, SPF authorization alone provides no protection.  When
reputation is applied to authorization, disaster!

SPF/Sender-ID is server authorization.  Because it is untrustworthy, (it
causes email to be lost or refused) SPF/Sender-ID has extremely little
value.  It can not be applied in any strict manner reliably.  The high
overhead associated with resolving the path registered by SPF, means
this mechanism can not offer network protection.  Nor can SPF reliably
offer recipient protection either.  Phishing and spamming is sure to
continue with SPF/Sender-ID.

I know there are some that dream of the day when "-all" does not cause
mail to be lost, and when everyone knows which identifier to check. SPF
demands additional diligence by providers, while also leaving the
providers unscathed when they are negligent. SPF may cause a behavior
change in some cases, but this change is almost certain to create even
greater damage for domain owners.

Something like DomainKeys, that will eventually be upgraded to DKIM,
does offer an alternative that is both safe and fair _authentication_.
This alternative to just _authorization_ uses less overhead than
SPF/Sender-ID.  In the case of SPF versus DomainKeys, the bad is the
enemy of the good, safe, and fair. : )

-Doug