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