At 09:30 AM 4/4/2005 -0700, Doug Otis wrote:
On Mon, 2005-04-04 at 09:59 -0700, David MacQuigg wrote:
Hello, I just came from the SPF camp. Please don't shoot me. :>) I'm
not
an SPF advocate. I'm an electronic design engineer hoping to find some
way
to help solve the problems with email authentication.
I really like the way CSV avoids all the complexity in SPF. I'm puzzled,
however, as to why you chose SRV records instead of a free-format TXT. As
I understand it, this limits you to authorizing just one or a few
servers. This seems like the opposite extreme from SPF.
Why not have one query produce a short list of IP blocks that are
authorized to act as mail servers for a domain? Then even a huge domain
like rr.com could give you hundreds of authorized IP servers in one
cacheable record.
For example, to specify 6 blocks of 170 IPs each and 5 blocks of 4 IPs
each
you might have a string like:
The SRV record does not require the administrator to enter any address
whatsoever. SRV records are strictly name based associations. This
also ensures only a single DNS lookup is needed to resolve the
authorization and authentication associated with the SMTP client's
connection. This simplifies the maintenance of these records, and
lowers the risk of publication error.
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.
Would it not be simpler to have one record list all the mail-serving IP
blocks for an entire domain? Take a look at the SPF record for
rr.com. They list all their mail servers in 12 blocks of 256 IPs
each. That would allow maybe 2000 servers to be moved freely among the
3072 possible IP addresses, so there isn't a maintenance problem that I can
see.
This SRV record, used in conjunction with a reputation service, may
provide DoS protections. SPF, for example, requires more than one
hundred DNS lookups, as a minimum, to ensure all clients that may send
from a particular domain can be resolved. Rather than retaining just an
manually generated address listing, (which is error prone) SPF has opted
to extend the number of queries to allow references by name for specific
clients. SRV already provides this name based reference feature.
The latest developments involve an "SPF compiler" to produce a simple list
of IP blocks from the more complex SPF "source record". This works for
most mechanisms, but there will still be problems with some. My guess is
that the troublesome mechanisms will eventually be deprecated, and SPF will
arrive at an optimum by backing off on some of their over-design.
The use of the SRV record avoids complexity by keeping within the
designed scale of DNS by attempting to only resolve the client
associated with the HELO, rather than answer a much more expansive (and
impossible) question regarding all the possible clients that send a
specific mailbox-domain.
It seems like the choice now is between CSV with a large number of
single-server records, and SPF with far fewer records but the potential for
abuse of its whiz-bang features. What I'm looking for is an optimum that
has the safety of CSV and just a few of the features of SPF. The ability
to authorize hundreds of servers in a domain, using one cacheable DNS
record, seems like a feature that CSV could use. It would be easier on DNS
than digging down six levels to query every server, and I don't see any
potential for abuse.
It seems to me the fundamental advantage of CSV over SPF is that CSV
doesn't try to associate domain names with IP addresses outside of that
domain. The disadvantage, and it doesn't seem fundamental, is that you
can't set up just one simple record to authorize all the servers in a domain.
-- Dave
************************************************************ *
* David MacQuigg, PhD email: david_macquigg at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *