Introduction; SPF proposes a configuration layer

On Wed, Oct 01, 2003 at 12:07:04PM -0400, Yakov Shafranovich wrote:
| 
| When you have subscribed yourself to the list, send out a short
| message about yourself, your role and your proposal.

Hi!

I founded pobox.com in 1995 and have CTOed it since then.  Pobox
provides me with the time and funding to pursue interesting projects
such as SPF.

I learned about Hadmut's RMX earlier this summer and became very
enthusiastic.  Soon thereafter I learned about Gordon Fecyk's DMP.

I have tried to combine the best features of both into SPF, whose
details are at http://spf.pobox.com/dns.html.  I presented SPF at OScon
2003; it was very well received.  I was expecting to announce it at
ISPcon, but now I hope that together we can come up with something
better so we can make the announcement with ASRG's official blessing.

The primary purpose of SPF is to prevent return-path forgery by
unauthorized SMTP clients.  The result is fewer worms and viruses that
forge addresses, fewer bogus "You sent us a virus" autoresponses from
naive MTAs, and less spam --- particularly of the PayPal variety.

"Classic" SPF has these disadvantages:

  1) Scaling: If 100 hacked machines send the same spam to 1 ISP, an
     innocent domain will get 100 different queries.  SPF does not benefit
     from caching.  RMX is much nicer in this regard because it serves
     up the approved list right away, and that list can be cached.

  2) The HELO domain name is less reliable.

  3) It's a burden on admins of small sites to keep MX vs SPF records
     consistent.  Mail::SPF::Publish was written to help solve this
     problem, but everybody will use it.

Two other disadvantages are shared by all designated-mailer schemes:

  4) Forwarding services need to implement sender rewriting.

  5) Users have to call home to their ISPs using SMTP AUTH.

Advantages:

  1) Only one DNS query is needed; this minimizes lookup times during SMTP.

  2) SPF has good momentum, with 66 people on the mailing list.
     Mail::SPF::Query has been published.  The SpamAssassin folks are
     working to integrate SPF support into the next version.  SPF
     patches or plugins are available for Exim, Postfix, Sendmail, and
     Qmail.  Dyndns.org plans to to publish SPF records on an
     experimental basis.

  3) SPF is not aimed at spam per se, but at viruses, worms, and forgery
     in general.  To work effectively as an antispam solution, RHSBLs
     are needed to determine who's good and who's bad.

				 * * *

	    Solving Classic SPF's problems with Enhanced SPF

RMX and DRIP are strong where SPF is weak, and vice versa.  How do we
solve all our problems?  We add another level of indirection!

A configuration step allows MTAs to query the sender domain and figure
out what kind of further lookup to perform.

If a very simple domain just wants to designate its MX servers, it can.

If a more complex domain wants to say that its permitted RMX are its
MX, but it should also specially allow one or two others, that works too.

If a domain prefers full-blown SPF, it can specify that too.

Here's how it works.

1) Perform an initial TXT query against a configuration label for the
   domain, eg. config._smtp_client.DOMAIN

2) That returns a set of configuration directives representing the
   designated-mailer policies of a purported sender domain.  We have
   been focusing on the SPF scheme so my examples may lean in that
   direction but the design is meant to be general.

   Suppose we query "config._smtp_client.DOMAIN TXT" and get the response

     "permit:mx; permit:a=designated-mailers.DOMAIN; permit:spf; include:OTHERDOMAIN; deny:default"

3) Each configuration directive represents a different approach to
   answering the "is this client for real" question.

     "permit:mx; permit:a=designated-mailers.DOMAIN; permit:spf; include:OTHERDOMAIN; deny:default"

4) permit:mx.  Do an MX -> A lookup on the sender domain.  The set of A
   records returned defines the designated mailers.  This is useful for
   simple setups where the inbound MXes are the same as the outbound.
   This bypasses the potential O(N) traffic of SPF, and permits O(1)
   caching by resolvers, which is one advantage of the RMX design.

5) permit:a=designated-mailers.DOMAIN.  Do an A lookup on the hostname
   "designated-mailers.DOMAIN".  The set of A records returned defines
   the designated mailers.  This provides the essentials of RMX
   functionality without adding new record types, and also has the
   benefit of caching.  If CIDR records are needed, they can be sent
   using a variation on this technique, such as
   permit:txt/cidr=designated-mailers.DOMAIN

6) permit:spf.  Do an SPF/DMP style lookup on
   4.3.2.1.in-addr._smtp_client.DOMAIN according to the SPF/DMP spec.
   This may be preferred by large domains who want to know who's forging
   their addresses.  On the downside, in a large spam run, you get O(N)
   DNS volume, which may prove to be undesirable.

7) include:OTHERDOMAIN; if none of the preceding lookups has
   short-circuited to "permit", recursively repeat the lookup using
   OTHERDOMAIN.

8) default:deny.  Mechanism, not policy; we should refrain from
   specifying that by default everything should be denied; that decision
   should be up to individual domains.  By default the answer would be
   "unknown", as if the sender domain did not participate in the protocol.
   A recipient MTA might also downgrade a "default:deny" to "unknown" if
   a sender domain specified a mechanism that the MTA did not recognize.