At 08:19 AM 4/5/2005 -0700, Douglas Otis wrote:
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?
I suppose by address, since there is no name in DNS. I think what you are
saying here is that the A records will always be necessary for each
machine, because mail admins will want to access those machines using names
like server117, rather than an IP address ending in .117. I don't know
enough about mail system administration to judge this assertion.
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.
The current draft-schlitt-spf-classic-00, Dec 2004, sets a maximum of 10
lookups. There is still a risk of abuse, even with 10. See my previous
response to John Leslie on the DNS load question.
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.
Stats show that the vast majority of current SPF records fit within the
limit of 10 lookups. (See recent posts in spf-discuss by Radu Hociung,
Subject = DNS Load Research ) There is a split over the question of what
is the risk of DNS abuse. I'm on the side advocating stricter
limits. Even though the risk cannot be proven, the solution looks simple
enough, and I believe it should be done just to remove any temptation for
the freak who will devote his life to writing an SPF-doom virus.
As for the "baggage" in SPF, I think that will eventually disappear. SPF
made a mistake (in my opinion) by adding some sophisticated features with
potential for abuse. They may have had to do this to gain acceptance from
mail system admins who would refuse to adopt SPF if even the smallest
change was required in their bizarre mail setups. Whatever the reason, SPF
is now having to backpedal and discourage the use of these features.
This has to be done in a way that doesn't break existing setups. The new
"mask" feature, if designed properly, should allow most authentications to
be done in one query, and still keep the old SPF mechanisms if more queries
are necessary. This should provide a smooth migration path from the
current complex syntax to a much simpler list of IP blocks. Eventually the
old syntax can be deprecated.
<snip>
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.
I agree with you that SPF has a problem with forwarders. The faulty
assumption is that the sender will always have a prior arrangement with the
forwarder, or at least be able to count on the forwarder not moving things
around too much. There is lots of wailing when this just doesn't
happen. The latest culprit is blockbuster.com. I think the SPF folks will
eventually realize they have to authenticate each hop independently.
CSV got it right on how to handle forwarders. I think there is still a
ways to go on reducing the DNS load. ( See my reply to John Leslie.) I
don't like having to set up DNS records for every server, but that is just
an inconvenience. If I had to do it for a hundred servers, I would
probably write a little script.
--
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 *
************************************************************ *