ietf-clear
[Top] [All Lists]

[clear] Comparing CSV and SPF

2005-04-05 06:20:13
On Tue, 2005-04-05 at 00:25, David MacQuigg wrote:
At 05:07 PM 4/4/2005 -0700, Douglas Otis wrote:
On Mon, 2005-04-04 at 16:29 -0700, David MacQuigg wrote:

I don't see how CSV avoids entering IP addresses, or how it simplifies
maintenance, especially for a large domain with hundreds of public mail
servers.  Don't you need both an SRV record (name) and an A record (IP
address) for each one of those servers?  Fundamentally, you always have to
make an association between a name and an address.

The SMTP clients will already have an A record.  The SRV record simply
uses the name of the A record as a Target.  Therefore, DNS
administrators do not enter an address for the SRV record, just the
name.  The association is between HELO and Target name, not addresses.

If I'm setting up a rack of machines to be used for nothing but outgoing 
mail, why do these machines need to have *any* DNS records?  Sorry if this 
is a dumb question, my understanding of DNS still has gaps.  Even if we 
don't count the A records as part of the required setup, we still need one 
SRV record per machine.

When you set up the rack of machines, how would you ssh into them, by
name, or by address?  

With CSV, there is an assurance all required information will be within
a single DNS lookup.

What if the server is six levels down at 
server6.rack5.room4.bldg3.company2.com?  Doesn't that require a DNS query 
at each level?  Won't caching be less effective at the lower levels, where 
you are likely to get a different server for each email.  Compare this to 
caching one record from rr.com, then using that same record to authenticate 
5000 emails from 500 different servers in 12 different subdomains.

These SPF TXT records are not small.  There will still be the TLDs
required in the cache regardless. Unless you receive email from each and
every client within a domain, the results within cache will likely be
much more compact using CSV.  CSV assures the overhead per session is a
maximum of ONE lookup.  For SPF, the minimum is hundreds.  This is
extremely important when defending network resources.

You REALLY don't care about all the other SMTP
clients that may be used.  You only want to know about the current SMTP
client.

You get the entire list of rr.com IP addresses in one query.  The ones you 
don't care about are free, and if you keep them in a cache, the next 5000 
emails from any server at rr.com can be authenticated from the cached record.

You are not describing SPF, this is a special case.  SPF requires a
minimum of hundreds of DNS lookups.  You may hope that someone like
rr.com has taken the time to compress their lists.  You are still left
with SPF baggage that dominates the spectrum.

Addresses are not static, not even blocks of addresses.

Public mail servers should have static addresses.

Static? Yes. Permanent? No.

Large blocks of addresses also requires parsing using a script language.

This has got to be an insignificant cost, certainly less than a DNS query 
for each address.

There can be several addresses associated with a single client.  It is
not one lookup per address, it is one lookup per client.  In the case of
SPF, this script parsing may pose a serious danger when going to several
servers, as this exposes the source port used by the process running the
script.  With CSV, no complex script, no sequential lookup, and no
active content within the query.  With CSV, there is far less risk to
DNS.   

Prior to the effort to distill these thousands of addresses to CIDR
notation, there was 78 DNS lookups to obtain the address list for rr.com
when using name references.  Hand manipulating thousands of addresses is
still a maintenance headache.

The compilation, sorting, and compaction of address blocks is done once by 
the sending domain using a tool with a nice user interface.  Input is 
something convenient, like CIDR notation, and output is a compact string 
ready for the DNS server.  The user is cautioned never to attempt hand 
editing of the compiled record.

This CIDR processing is optional; it is not required.  The process is
still manual and error prone. Errors may occur within the entry or the
script.  SPF still breaks mail, even when the address records are
perfectly entered in their optimum format.  The optimum SPF format will
still likely cause your cache to grow faster than with CSV, and CSV does
not break mail.    

By using name associations, changing the
individual address record will update all related records, whether these
are the MX or the SRV records.  No special tools are required.

This might save some time for a small domain with one server having both MX 
and SRV records, but the scenario I'm thinking of would be racks of servers 
dedicated to outgoing mail only.  I would rather not have to change any 
individual address records at all.

Why optimize the DNS publishing (which you are not, by the way) without
considering the billions upon billions of times the record will be read?
Start with a square stone, chip away at the corners, and eventually you
will reinvent the wheel.

Great analogy!! SPF has a bunch of corners that need to be rounded 
off.  CSV needs some ball bearings to make it roll with less friction.

I don't think CSV needs any lubricant.  CSV defends network resources
while message signing like DomainKeys fulfills the role that SPF had
attempted.  A signature can never defend resources, nor can SPF for that
matter.

For HELO, SRV already provides this "compiled"
list of addresses.  This is done at the lowest level of complexity
possible; the single SMTP client.

"Compiling" the address blocks saves time and space if you have a lot of 
similar information to compile, like racks of dedicated outgoing 
servers.  For single servers, it seems like SPF and CSV will both require 
attention to individual server records.

Most systems don't grow by the truckload. They grow as needed, which is
often a few servers at a time.  Adding, changing, or moving a server is
far more safely done using CSV.  I can even adjust the TTLs when I know
I am about to move a server, without affecting other servers.  

In addition, the need to list all
associated addresses vanishes when DomainKeys is used, as the signature
can better associate all related sources.  Bulk emailers simply sign
their mail to achieve the same result, while not having problems with
forwarded accounts, etc.

I think it would be advantageous even with signature-authenticated messages 
to do a quick IP authentication at each hop.  That will reject most 
forgeries at the earliest opportunity and minimize Internet traffic.  Since 
a forwarder will not know without a DNS query whether a message uses 
signature or IP authentication, at least one DNS query at each hop will be 
necessary anyway.  One query should get whatever authentication information 
a domain provides, including a compact list of IP address blocks.

And how does this overcome the forwarding problem?  How does this
utilize the advantages gained by a signature?  CSV still provides the
most expedient means to obtain an authenticated domain at each hop.
Reputation based upon an authenticated entity is the only safe means to
abate abuse.  No mailbox-domain is authenticated using SPF.  SPF only
indicates the client has been authorized.  Authorization is useless from
a reputation standpoint. SPF does not prevent forgery.

The HELO should prevent any digging.

How do you find the authentication records without digging when the HELO 
name is server6.rack5.room4.bldg3.company2.com ???

server6.rack5-room4-bldg3.company2.com.

I am sure you are trying to make a point.  

When CSV is not supported, there
may be a desire to do a few more queries.

One query to company2.com should get all authentication records for the 
entire company.  The exception is SPF, where it may be necessary to follow 
a chain of "redirects" to other records.  The latest development is a 
compiler that generates a "mask" for an entire chain of SPF records.  That 
mask goes in the first record, and allows a quick FAIL of 99% of the 
forgeries, which won't have an address that is "close" to an allowed 
address.  Confirming a PASS still requires following the redirects, 
however. :>(

And when there is no SPF record at all?

Funny, that seems to be its advantage.  It provides DoS protection, in
conjunction with domain based reputations, that SPF can never provide.

??? The disadvantage is the effort to set up all the DNS records 
authorizing a large number of servers.  I don't see the connection to DoS 
protection.

You seem to only consider efforts needed to publish, when this record is
then read billion of times more.

On the DoS vulnerability issue, I think what you are referring to is the 
risk arising from the macros, redirects, and includes in the SPF syntax, 
all of which can generate of lot of DNS traffic, but none of which are 
necessary to define a set of IP blocks.

One versus hundreds, as a minimum number of lookups for CSV vs SPF.

Let's not make the mistake of assuming that *everything* in SPF is bad, 
because it has a few unsafe features.  In fact, the good features can 
actually *reduce* the DNS load much lower that what I understand CVS will 
generate.

This is nonsense.  SPF will not reduce any load.

A properly set up SPF record can deliver the authentication 
information for an entire large domain in one query.

SPF does not provide AUTHENTICATION!  SPF simply indicates the
mailbox-domain has AUTHORIZED the client.  SPF does not provide any
assurance the mailbox-domain originated the message. SPF is NOT about
authentication.

A poorly set up SPF record can be an opportunity for a DoS attack.  I
would like to see CSV adopt the good features of SPF.

Which feature of SPF is good?  CSV authenticates the HELO which allows
the safe application of reputation.  SPF does not authenticate anything,
nor does it allow the safe application of reputation.  CSV assures a
single lookup which provides resource protection, when used in
conjunction with reputation.  SPF offer NO resource protection.  CSV
includes only the information required to AUTHENTICATE and verify the
AUTHORIZATION of the HELO.  SPF includes an entire domain's
infrastructure, far beyond that needed to verify just the mailbox-domain
AUTHORIZATION.  SPF mailbox-domain AUTHORIZATION is expected to fail
when a message is forwarded.  CSV is not expected to fail for
AUTHENTICATION or AUTHORIZATION in any case.

-Doug





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