spf-discuss
[Top] [All Lists]

Re: Performance issues

2004-02-17 20:06:56

On Feb 17, 2004, at 8:35 PM, Hector Santos wrote:
----- Original Message -----
From: "Theo Schlossnagle" <jesus(_at_)omniti(_dot_)com>
I would, however, be very interested in any information on the query
traffic patterns when performing SPF before DNS RBL as opposed to doing
it after.  My hunch is SPF-first is better, but I'd be happy to change
my outlook based on evidence.

Better in what way?

As far as DNS performance, it is good point to look at. However, unless SPF can replace RBL functionality, I sincerely doubt seeing RBL usage go down in lieu of using SPF instead. Apples and oranges, really. It is just two different pieces information gained; one is sending machine validation,
the other seeks reputation.

But then again, I'm sure there are those who believe validating the sending
machine is all you need, regardless if its reputation.

I wasn't arguing for SPF in lieu of RBL. I was exploring the optimal order of execution.

The way most people use RBL is as a blocklist. So, if your IP is in the RBL, you will reject that person right then and there. This requires 1 or 2 DNS queries. The first query is used to to determine if the person is in the RBL and how. If that returns an A record that you disapprove of, then you continue to the second query which is a TXT record explanation.

Regardless of the genre of fraud prevention you use, the first step is to perform a paranoid check on connection: (1) in-addr.arpa PTR lookups + (n) named A lookups to validate the connecting IP has adequate DNS legitimacy.

Let's look at RBL against spamhaus:

  IP: 69.6.21.17
  lookup1: 17.21.6.69.sbl.spamhaus.org A 127.0.0.2
suppose our server is configured to reject mail if the RBL return 127.0.0.2... lookup2: 17.21.6.69.sbl.spamhaus.org TXT (two records re: SBL6636 and SBL10098)

At this point we toss out the connection. So, we never even performed SPF.

SPF on the other hand would work like this:

If the person tries to send mail from @mail.com from that same IP we a single lookup:
  mail.com TXT: v=spf1 ip4:.... ip4:... ~all
  This is one lookup every 8 hours (that record has a 28800 second TTL)
Assuming that you reject message on a soft-fail (~), you can toss the connection out here.

So, my logic is as follows. There are more sending IPs than common sending domains (at least into my system). The mail.com record gives me the chance to reject emails sent "from" mail.com from an IP address based solely on my cached mail.com TXT record. I think that SPF records are broad and sweeping in the fraud they can prevent while DNS RBL is about articulately defining abusers.

If either gives a fail, the session can be dropped. The question is, which is a cheaper check to perform given the probability if a "fail" hit with that technique. While I think SPF would be more expensive without caching (because of includes explains and redirects), I think that with a cache and amortizing the cost of all your inbound email that SPF would be cheaper.

The goal is to determine whether SPF should be executed before DNS RBLs or after them to minimize the number of queries assuming that if the first one has a "fail" hit, we stop processing and drop the session.

But now that I think about it, I feel silly.  The answer is:

(1) DNS RBL check -- cache only
(2) SPF validation -- cache only
(3) SPF validation with queries if cache was incomplete
(4) DNS RBL with queries if cache was incomplete.

// Theo Schlossnagle
// Principal Engineer -- http://www.omniti.com/~jesus/
// Postal Engine -- http://www.postalengine.com/
// Ecelerity: fastest MTA on Earth


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