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

On Wed, 2005-06-01 at 14:19 -0400, Alan DeKok wrote:
> "william(at)elan.net" <[email protected]> wrote:
> > 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,
> 
>   If an MTA is shared, the reputation would seem to be shared, too.
> That's life.

I agree with William's statement.  With SPF or Sender-ID, reputation
accrual would damage a mailbox-domain owner, and not the MTA
administrator.  The mailbox-domain owner may have been singled-out and
forged by some zombied customer, until the victim's reputation is
thoroughly destroyed.

The administrator of a shared MTA must apply mailbox-domain constraints
on both the bounce-address and the PRA for each and every message.  This
constraint must limit the domains permitted for the authenticated users
or relayed MTAs.  Lack of this domain constraint operation imperils
their customer's domain reputation.  I doubt many email providers would
provide a virtual MTA with an isolated IP addresses, just to avoid the
need to assure this mailbox-domain constraint.  I have little doubt the
MTA administrator would do nothing, and consider this as not their
problem.

IP address space pressures has caused much of the sharing of IP
addresses for both MTAs and Web servers.  One reason to deploy a name
based reputation system, is to overcome the problem of IP address
aggregation affecting so many different domains.  The application of
reputation makes domain/user isolation critical for the domain owner.


>   We could require that abuse of a shared MTA by one domain not affect
> the reputation of another domain also at that MTA.  But we can't use
> the HELO field as part of a solution to meet that requirement, as the
> only information it presents is the name of the shared MTA.

The lack of HELO validation would not be considered a reason to reject
the message, based on either SPF or Sender-ID validation.  Had just the
MTA identifiers, IP address or HELO, been solely utilized as a basis for
accruing reputation, then indeed reputations would be shared by every
domain using the MTA.  Then the domain owner could recover use of their
domain by employing a different MTA.  Relying upon the MTA identifiers
for reputation accrual provides the MTA administrator an incentive to
aggressively disable abusive accounts.  They would maintain diligence by
either monitoring logs for volumes and errors, or by checking abuse
reports.  This incentive is real and valuable.

Once an MTA administrator buys the notion that SPF/Sender-ID takes care
of abuse, where reputation no longer affects them directly, they have
less incentive to do the real job of abating abuse before it is sent.
While this may be seen as a great feature by email providers, it should
cause network providers and any domain owner great concern.  Abusers
controlling millions of zombies will jump on this weakness, much to the
detriment of mailbox-domain owners sharing an MTA, and that have also
published SPF records.  Unless you run your own MTA and are willing to
allow some mail to be lost by those that have forwarding accounts, do
not publish SPF!  Consider DomainKeys for now, and then upgrade to DKIM.


>   If the *message* is authenticated, and not the *transport* layer,
> then it doesn't matter how the message is transported.  But that's
> another issue...

Yes it is.  That is the reason DKIM is so desperately needed.

-Doug