In <2004123173227(_dot_)588226(_at_)bbfujip> Dave Crocker
<dhc(_at_)dcrocker(_dot_)net> writes:
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.
Yes, that is obvious.
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.
Yes, that that is why when SPF-classic checks a 2821.MAILFROM name,
it checks the SPF record at the domain of the 2821.MAILFROM and when
SPF-classic checks a 2821.HELO name, it checks the SPF record at the
domain of the 2821.HELO.
You keep talking about semantics. You've talked about SPF "changing
the semantics of the 2821.MAILFROM". You don't give concrete
examples of when SPF will give an answer that is different. You don't
even give contrived cases. If two functions always return the same
answer, they are isomorphic, and therefore the semantics that each
define are isomorphic.
> 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.
So, is CSV/DNA/CSA a "complex of different functions, all packaged
together", or "a set of discrete functions"? Is Unified-SPF, with
it's separate I-Ds for HELO checking, MAILFROM checking, PTR checking,
and accreditation a "complex of different functions, all packaged
together", or "a set of discrete functions"?
Is SPF more complex because it re-uses a common syntax, letting you
pick and choose which things are appropriate in each circumstance, or
is it simpler because of that?
Moving around the stuff into separate drafts or combining everything
into one doesn't really change the complexity. When doing proofs, you
generally like a very simple system, such as a Turing machine, because
that makes proofs much easier. This simplicity, however, makes doing
any really functional with it very complex. On the other hand, when
doing something really functional, you like lots of tools so you
express things very clearly, but that makes proofs very complex.
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.
Well, I guess the proof of the pudding is in the eating. SPF had more
records deployed at the HELO domain level a year ago, only 3 months
after it was added to the spec, than CSV has now after 6 months. SPF
had more code deployed checking the HELO domain a year ago than CSV
has now.
It is not at all clear to me that SPF has made the wrong decisions and
CSV/DNA/CSA/HNA/whatever has made the write decisions.
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.
I think there are many people who are greatly regretting letting SPF
get worked over by the IETF committee. That has been the sources of
the constant changing. I agree, we certainly haven't recovered from
the damage that getting involved with the IETF has caused, but I hope
that we can recover soon.
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.
As I explained to you at the MARID Interim meeting, SES and SRS had
already been investigated. People have been actively deploying SRS
and SES since before the MARID Interim meeting. Looking at the most
recent BATV I-D, it appears that you have not learned lessons that
have already been learned by this deployment. The people working on
SES have made several advances that in the last 6 months, and it looks
like a much more useful spec to me than BATV.
SRS and SES are useful tools and I have long encouraged the use of
both of them. They do slightly different things, and do different
things than SPF does. Uh, wait, is this a "complex of different
functions" or a "set of discrete functions"? I can't tell.
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.
Well, if CSV is so much easier to deploy, why hasn't it even caught up
to where SPF was a year ago? CSV has gotten *FAR* more publicity than
SPF had at that time.
My guess is that the abuse of SRV records by CSV is a really bad
decision. Not only doesn't CSV use SRV records the way SRV records
are documented to be used, but you have to encode all sorts of bit
patterns and redefine the semantics of fields. Lots of people have
shown that they can create SPF records quickly from the top of their
heads. How many people are there in the world that could create a SRV
record as redefined by CSV without consulting the spec?
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.
Please give some examples of Meng's SPF wizard making mistakes, as a
opposed to people using Meng's SPF wizard incorrectly.
-wayne