Re: Problems with SPF, solutions, and a timeline.

John Levine <[email protected]> wrote:
> If I were a bad guy, I'd register some throwaway domains, or I'd
> forge some badly managed third-world domains with no LMAP data, use
> them in the bounce address to pass LMAP checks, and forge like crazy
> in the From: and Sender: lines that people see.

  This has been known since day 1 of the proposals.  There are ways
around it.  See my recent post about a system to combine MTA-MARK and
LMAP, so that the owner of the rDNS can publish delegation
information, and thus control who can publish LMAP information for
that IP.

  e.g. enhanced LMAP for a domain publishes a signed authorization,
and rDNS publishes the public key.  The IP owner can thus control who
can publish LMAP information.  Presto: no forged LMAP entries.

  e.g. rDNS publishes a list of domains which are permitted to
associate themselves with that IP.  This method has the benefit of not
involving crypto.

  There are many ways of getting around the problem of forged LMAP
entries.

> Another issue is one-way mail domains like Meng's pobox.com.  They can
> publish SPF data saying mail's OK from anywhere, which is like a "kick
> me" sign inviting spammers to forge it,

  If they're willing to accept such responsibility, that's their
problem.  "Solving" that problem involves removing that choice from
the proposal, which I believe to be unacceptable.  LMAP allows people
to be stupid, as well as to be smart.

> or you can demand that the sender use the real address of the place
> where he sends it, which has privacy problems,

  If you mean the sender uses the MTA for the "from" domain to send
the mail, then there are no privacy problems.  The responses already
come through that MTA, and if the sender wants protection from that
MTA, he shouldn't use it, or should encrypt his messages.

> The first problem is the biggest, whether preventing envelope forgery
> will in practice deter spammers.  If not, the whole LMAP exercise is
> pointless.

  I see.  So because one proposal isn't the perfect magic bullet in
and of itself, we shouldn't use it.  I thought we had rejected this
argument *months* ago on ASRG.

  There is no magic bullet.  All we have is a series of methods which
will help address the problem.  In isolation, each proposal may not be
perfect, but the overlap of the proposals may be sufficient to stop
spam.  And systems which help recipients fight spammers are useful,
even if those systems don't act as deterrents in and of themselves.

  The only question is then cost.  If the proposals cost more to
implement than the current spam problem costs, they're pointless.

  But I don't see people doing cost/benefit analysis.  I see people
saying "Your proposal isn't perfect, so we shouldn't implement it."  I
don't know about anyone else, but I don't have delusions that I'm
omnipotent, perfect, or all-knowing.  I don't believe any one solution
will be the "magic bullet" to stop spam.  I'm willing to accept
imperfect solutions if they are better than the alternatives.

  Can we please agree that there is no one perfect magic bullet, and
stop wasting our time denigrating solutions because they're *not* the
magic bullet?

  Alan DeKok.