On Wed, 01 Dec 2004 23:00:45 -0800, Greg Connor wrote:
My understanding of whitelisting:
Quickly determine if the IP of the client goes with the HELO name
Quickly determine if a name is on the OK list
Manage the list of allowed names easily (e.g. by domain suffix)
My understanding of CSV as it relates to whitelisting:
Can determine if the IP of the client goes with the HELO name
My understanding of SPF as it relates to whitelisting:
Can determine if the IP of the client goes with the HELO name
What this comparison ignores is where the names come from. Client MTAs choose
their RFC2821.EHLO name on a different basis than posters choosing
RFC2821.MailFrom names.
In other words, it is not enough that one can fine some entry that matches a
name to an address. The semantics of the matching needs to.... match the use.
You want a physician. I claim to be one. You fine my name listed on the
membership of the IEEE. Does that mean that I am valid as a physician? I
don't think so. The semantics that are the basis for listing me have nothing
to do with my (actually non-existent) medical skills.
CSV's proponents have made the point that since CSV has a much more limited
application (i.e. it *only* does HELO name::ip correlation) that this
therefore means it is inherently better for the applications it does
We have several decades of experience with the difference between trying to
field simple, narrow application services, versus complex functions that have
the potential for complex, unexpected interactions. From an operational
standpoint, "better" does not begin to convey just how profound the lesson has
been.
> I. Surely, you understand that the SPF record discovery algorithm is
> inherently less efficient/more costly than CSV's. That's obvious, no?
> How many DNS queries does it take to resolve elvey.com's SPF record to a
> list of IPs? A dozen or so?
This line of reasoning (IMO) breaks down to something like:
CSV is simpler because it has fewer moving parts (some might say "fewer
features")
You need a way to associate names to IPs for your HELO name
As simple as you need, but no simpler.
Good argument, but it hinges on a fourth crucial point:
User wants HELO name protected, and nothing else.
The logic behind 'simple is better' is a bit more... complicated. So let's
make sure that the right issue is being discussed.
The real choice is between a complex of different functions, all packaged
together, versus a set of discrete functions.
Experience is quite consistent on this point: Start with small, discrete
functions and add to them, or add more, over time. This makes things easy to
adopt, easy to understand, and easy to use. The "all-in-one" large system
approach has been repeatedly demonstrated to cost vastly more to adopt, to be
very difficult to understand, and have significant barriers to use.
One of the more amusing aspects of the large system approach is that it tends
to be unstable. Folks tend to be constantly adding to it, or correcting it, so
that it is very difficult to know whether a reference is to something under
development or something being deployed. This is something the SPF world
demonstrates nicely.
On the other hand, if you want MAIL FROM or any other SPF features, you
will want to implement SPF, not SPF and also CSV. Meaning that if you
Yet this ignores choices for the other functions, such as BATV for MailFrom
protection.
believe that simplicity and fewer moving parts is of paramount importance,
CSV is your thing. If you want the other features too, SPF is your thing.
Wrong. If you believe that easy adoption and clear, direct dynamics is of
paramount importance, then discrete, narrow functions (like CSV) are your
thing. If you want complex dynamics and difficult configuration, then SPF is
your thing.
Let me anticipate the hue and cry against my configuration slam. Yes, SPF can
be simple to configure, but only if you use it in its simplest form. As soon
as you try to take advantage of all that functionality, configuration errors go
up astronomically. I'm told that even Meng's configuration tool makes
significant mistakes.
The trouble is that it isn't a decision you can make by just shopping for
the right thing for your needs, like you can with shrinkwrapped software.
It's all about interoperability, so as a big player you need to decide
which protocol serves most of the needs of most of the people the best.
Interoperability is affected mostly by complexity in the specification,
complexity of deployment/administration, and complexity of use.
Check out X.400 vs. SMTP/822, or X.500 vs. LDAP, or TCP vs TP0/1/2/3/4, and so
on. In the case of each OSI choice, there was vast industry and government
support, yet they failed. In every case, they were so complex that they were
never able to achieve any broad base of deployment and use.
The major design lesson of the Internet is to keep it narrow and simple.
I submit that simplicity is not the paramount issue when dealing with
protocols. A wide variety of users will want a wide variety of features.
Please provide example of this trade-off, where your own assessment is
validated. I can't think of any.
I don't see how ?mechanism: is a problem. CSV has an "unknown" mode too,
No.
There is a fundamental difference between a mechanism that has a formal
"unknown" response, versus cases that are not covered by the mechanism at all.
I submit that simplicity is not the paramount issue when dealing with
protocols. A wide variety of users will want a wide variety of features.
can you offer some empirical data for this assessment?
what is there, in the history of Internet protocol work, that demonstrates the
adoption efficacy of feature-rich, rather than protocols that have a simple
core?
> III. SPF provides no mechanism for determining how to determine a
> domain's reputation. CSV does.
Wait a second, I didn't see that in the draft I read. Anyway I'm confining
myself to whitelisting right now, not reputation.
Take a look at the DNA spec. It's about reputation.
> the meaning of "checking the HELO domain against SPF records" is vague;
It needn't be. If we decide to use SPF HELO as a criteria for
Thanks for demonstrating my point about confusion. "It needn't be" applies to
the limitations of almost any specification.
What matters is what is specified and whether it gets deployment and use, and
what factors affect that. It is not productive to respond that a limitatation
"need not" be present. Crime and war "need not" be a problem, if only we would
all just get along...
d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
www.brandenburg.com