ietf-mxcomp
[Top] [All Lists]

Re: SPF abused by spammers

2004-09-14 11:17:08

On Tue, 2004-09-14 at 07:39, Alan DeKok wrote:
Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> wrote:
The MTA may be authorized to send on behalf of MAIL FROM, but that
is not the same as authenticating the entity associated with the
identity MAIL FROM as being the originator.

  I agree 100%.

  The problem is that because the bounce path is not verifiable, the
originator is anonymous, and the MAIL FROM identity can't be trusted
for anything.  In the absence of a method to verify the bounce path,
authenticating the MTA using the domain in the MAIL FROM identity is a
good first step.

You describe that as authenticating the MTA, but what this operation is
doing is validating the MTA as authorized to send a message containing
the MAIL FROM.  This identity has not been authenticated as originating
from the entity associated with the MAIL FROM.  

  I can think of scenarios where a domain sends mail from *only* one
MTA, and that MTA uses EHLO with another domain name.  In that case,
the first domain SHOULD have some way of saying "this MTA sends MAIL
FROM using my name".  Authenticating the EHLO doesn't get you that
information, so we need something more.

There are two things needed as independent steps.  One, authenticate the
name of the MTA to allow safe reputation assertions.  Two, determine the
MTA names authorized by the selected mailbox domain.  This can include
the MAIL FROM and the From mailbox domains.  These two steps then allow
for the reputation assertions and the blocking of spoofed mail for
either of these mailbox domains.  If the authorization list is only
nominal, then this list can be used to 'color' the mail at the MUA
rather than blocking it.

SPF or Sender-ID confirmation does not mean this entity associated
with the MAIL FROM identity had originated the message.

  But the recipient can't tell who the "real" originator is.  So far
as it seesm the SMTP client talking to it's SMTP server *is* the
originator.

But neither SPF nor Sender-ID properly identify the MTA.

  Publishers should expect recipients to do the most curious things,
for the most inane reasons.

What does this mean?

  'publishers should also expect to be black-listed when they publish
an "open" record'

  Not because it's a good idea, but because people will do anything
they want, including blacklisting domains containing the letter "a".

  In other words, our desires about how the records are interpreted
may be written down in a specification, but we should not expect
everyone to follow that specification.

This means one of two things with respect to SPF or Sender-ID. 

A) Remove all open list options.
B) Demand no reputations be based upon SPF/Sender-ID identities.

Option A breaks forwarding and several list servers.
Option B only helps reduce some of the spoofing, but does not allow a
named based reputation system using SPF or Sender-ID.

How do you arrive at publishing an SPF record being tantamount to
accepting accountability for all actions of these authorized entities? 

  If that's what the spec says publishing a record means, that's the
semantics of the record.

That has not been made clear in the draft nor would allowing open lists
reflect this reality.

If one were to authorize a provider to send mail, and their provider's
system became compromised, would it not be better to accredit the
provider for resulting abuse?

  Multiple parties were involved, multiple parties share the
reputation gained through sending those messages.

The multiple parties are the customers of the MTA provider.  By basing
reputation upon the provider by way of the EHLO name, a provider that is
not watching their logs or ensuring their server is secure, gets the bad
reputation.  This directly addresses the abuse problem by stopping the
source of the problem.  Blocking by the mailbox domain may unfairly
block innocent victims of spoofing, but blocking by the MTA EHLO name
will safely block the MTA with the problem.  If there is a mailbox
domain causing abuse, the provider must remove these problem accounts to
protect their reputation.  That is how it works today, but by using
names rather than IP addresses, history is easier to maintain.    

Won't this resolve the problem sooner than causing an innocent party
to litigate for protection from a sloppy reputation assessment?

  That's a local legal issue.  Some jurisdictions have reasonable
laws, others don't.  We shouldn't let the possibility of legal action
dissuade us from designing a solution.

The solution should be able to accurately identify the source of abuse
as a means of avoiding these legal issues.  An email reputation service
must deal with the entire world. 

The marid-mpr draft shows how the authentication of the MTA client can
be accomplished separately from the mailbox-domain authorization.  By
doing both steps independently, there is no need to hold the mailbox
domain accountable for the actions of the client MTA they authorize. 

  Interesting.  If I authorize someone to act on my behalf, I am
generally accountable for at least some of their actions.  Removing
this accountability is a unique feature of MPR.

This is establishing a hierarchy of accountability.  Those sending mail
must vet the accounts they relay to protect their reputation.  Those
holding accounts must then answer to their providers.  If a provider
fails to do their job, then as customers see their mail rejected, they
are free to find a different provider.  Providers will need their own
method to vet new accounts.  Neither Sender-ID nor SPF help in this
regard.

Sender-ID and SPF allows lax efforts of providers to hurt their
customer's reputation unfairly.  This model only seems to offer
litigation as a recourse for those unfairly harmed by this sloppy
reputation mechanism.

-Doug  




<Prev in Thread] Current Thread [Next in Thread>