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

On Wed, 2005-06-01 at 00:43 -0700, william(at)elan.net wrote:
> On Tue, 31 May 2005, Douglas Otis wrote:
> 
> > The HELO name would be indicative of the domain administrator running
> > the MTA, irrespective of the mailbox-domains contained in messages sent
> > by the MTA.  If the MTA is not properly administered, it would be this
> > MTA and the administrator of this MTA identified by a reputation scheme
> > that rates HELO names.
> 
> People here are not saying that being able to tag responsibility to MTA is 
> a bad idea. People are just saying that there are also other ways it 
> can be done and that MTA responsibility is one thing while domain owner
> responsibility is another and that both are useful when making decisions.

To authenticate the mailbox-domain, use a signature.  It is unfair to
hold the mailbox-domain owner accountable, when there remains doubt
about who actually initiated the message, as with SPF.  Dunning the
mailbox-domain owner for abuse can not be effective, when the source of
the problem is a mystery to them.  The only avenue available to the
mailbox-domain owner would involve a discovery process in an expensive
litigation, to force the MTA administrator to produce requisite
transaction logs.  Otherwise, the MTA administrator would be obligated
to keep these logs private, and may not be cooperative when the logs
indicate they were negligent in some fashion.

> > Those that would normally send messages over a HELO blocked MTA would be
> > free to look elsewhere to obtain email services.  If the mailbox-domains
> > were rated and blocked instead, as with SPF, a poorly maintained MTA
> > could continue to send abusive and even forged emails, but then the
> > domain owners would find use of their domains blocked, no matter which
> > other provider they tried.
> 
> I think what you're trying to argue here that when domain owner is using
> shared MTA that does not have strong policies in regards to its network
> than it may become target of abuse and abusers may choose to use other
> domains maintained by that MTA at random, i.e. its the case of large dsl
> provider and user having to use that provider's MTA and is subject to
> the MTA being used by zombies located on the provider's network and zombies
> choosing domains of various users (that come through that mta) at random.
> Is that what you're worried about?

Only by naming the actual source of abuse, not just finding a name to
blame, would reputation provide a means to ensure the MTA administrator
remains diligent.  Only a diligent MTA administrator can be effective at
squelching abuse.  The number of techniques used to circumvent security
is many.  Two rather obvious concerns would be open-proxy or open-relay,
which have specific dedicated black-hole lists for just these possible
administrative errors.  Some of these errors require third-party
real-time verification to isolate the source.  Hardly a legitimate duty
to be expected of the mailbox-domain owner.

In addition to normal security concerns, with SPF/Sender-ID, the MTA
administrator MUST apply mailbox-domain limitations based upon
permissions for either authenticated users or an MTA being relayed.
This will cost the MTA administrator support calls.  Because SPF depends
upon ambiguous defaults defining which identities are assured within a
message, SPF records may be used as a basis for applying the PRA or the
bounce-address.  Therefore, any MTA administrator failing to make the
same limitations for the PRA, as for the bounce-address, place the
mailbox-domain owner's reputation at risk.

The only safe option presently available for the mailbox-domain owner
would be to NOT publish SPF records.  Otherwise, the mailbox-domain
owner runs a serious risk of being assumed culpable for any forged
abusive messages that may appear.  With these SPF records being very
public, an already far too common nefarious abuser employing the use of
Zombied systems, will also know who they should try to forge.  Abusers
may be successful due to an MTA administrator's lapse in applying either
some or all of the expensive mailbox-domain restrictions.  Even if the
Zombied system were owned by the actual domain owner, the MTA
administrator is best able to detect abuse to alert the domain owner.

On a per-MTA basis, CSV ensures the administrator is held accountable
for the operation of the server.  It is foolish to hold a feckless
mailbox-domain owner accountable.  Signatures, while not providing any
network resource protection, do offer a fair and safe method to hold the
administrator accountable from where the message originated.  Signatures
can track the mailbox-domain and offer real anti-phishing protections as
well.  While there have been some to suggest Sender-ID offers
anti-phishing protection, it is not safe due to reliance on hidden
headers and server authorizations.

To increase the integrity and safety of email delivery, an
identification and reputation scheme needs to be as close to go/no-go as
possible. Otherwise, the junk folder becomes the nemesis of a large
number of gray transactions.  It is unfortunate that SPF has four levels
of server authorization.  This multilevel aspect has a multiplicative
affect on reputation assessments, as there may be a desire to track each
level separately to form some kind of proprietary fuzzy-logic
aggregate.  

As I said when I started my comments, SPF is fundamentally flawed.  SPF
and Sender-ID in combination is a disaster.  The filtering paradigm used
by SPF to handle its many shades of gray will ensure the problems
created will be intractable.  The only means I see to extricate SPF from
making things far far worse, would be to depreciate the use of version 1
SPF records.  Recommend that they be removed.  For those that don't want
to be trusting an MTA provider to assure their reputation, offer a new
scope called 'ADMIN' to allow SPF to be used for white-listing purposes
only.

Should SPF/Sender-ID reputation schemes become used as promised, there
will be a new industry servicing email forensics to assist a booming
civil discovery process.  The harm created will be intractable and
extremely damaging.  Domain constraints will cause a loss of customers
and enumerable support calls.  SPF/Sender-ID provides two very difficult
paths to choose, when attempting to avoid administrative accountability.
Adjust your budget accordingly, there is no free lunch.

CSV, on the other hand, indicates that you accept administrative
accountability without unfairly foisting this onto your customers.  Only
signatures offer an alternative that can safely apply accountability
from where the message initiated.

-Doug