Re: Re: [ietf-clear] Re: Make CSV backwards compatible with legacy SPF r

I appreciate Dave taking the time to write.  I think I'm a bit closer to 
understanding some of your concerns.
In general I agree with wayne so I won't repeat what he wrote (much :)

It's not my intention to bash on CSV here... I think it's a perfectly 
acceptable tool for doing exactly what it does.  I think that the issue of 
whether people would like a tool that does one job only, vs. one that does 
multiple related jobs for little incremental cost, is more of a marketing 
issue anyway.
For the purposes of whitelisting by HELO name, I'll stipulate that they are 
both sufficient to the job.  I still can't see any way that CSV is 
inherently better for that job.
--wayne <wayne(_at_)schlitt(_dot_)net> wrote:

> 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.
> >
> > 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.

Sorry, I should have been more clear.  What I meant to say is that both CSV 
and SPF successfully match a name to an IP.  Neither provides 
one-stop-shopping for a whitelist maintainer - there is still the matter of 
adding the name to the list, deciding whether the folks at that other site 
meet the criteria for listing, etc.

> 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.

Also a good point.


> > >  > 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 point I was trying to make (probably didn't make clearly enough) is 
that SPF does multiple, related jobs (checking HELO and checking MAIL 
FROM).  It's important to note that none of CSV/DNA/CSA/HNAA protect 
against inappropriate use of a domain in MAIL FROM.  So if you assume that 
a domain owner will want both, the choices are (CSV+SPF) or (SPF).

> > 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"?
I was confused about that as well.

Anyway, I think the choice of whether you want one tool that does a number 
of related jobs, versus several tools that only do very discrete jobs, is a 
style choice that doesn't have a clear answer (when viewed in the general).
A tool with a discrete function may or may not do that job better than a 
more complex tool.  At least it has the advantage that it won't go off and 
do another job while you're not looking.  Perhaps that's a concern for some 
buyers.  I don't think it's an overriding concern.
A tool with multiple functions may be more complex, but I don't think 
that's a showstopper for most.  Some folks would see this as a 
disadvantage, but I suspect many more would see it as an advantage.

If the choices were strictly a-la-carte, some people would buy CSV and come 
back for MAIL FROM protection later (when such becomes available).  But the 
choice of protocols is not an individual one.  So, if a protocol designer 
and evangelist chooses a very discrete approach versus a more complex one, 
he is putting "simple" higher on the list of priorities, higher than "does 
what you need".  And on the next block, another designer is selling a more 
complex tool that does more, maybe even does functions you don't need, but 
the operation of the various modes is quite similar.
As a protocol shopper, your highest concern is probably "how many other 
sites does this interoperate with", and a second concern might be "does it 
do what I need".  I believe that "extremely simple" is not the overriding 
concern when choosing a protocol.

> 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?
oops, I repeated some of that, sort of.


> > 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.

Whether I believe the generalization is not really as relevant as whether 
it can be successfully applied in this situation.  It's to the advantage of 
the CSV sales force to characterize SPF as a huge hulk which requires a lot 
more maintenance on account of a high number of moving parts.  To me that's 
like comparing apple pie to a slice of orange.
1. I disagree with the characterization of SPF as a "large system" 
approach.  It's not really all-in-one, it's more like 2 in one.  I disagree 
with the implication that SPF costs more, or is harder to understand.  If 
SPF has significant barriers, it's mostly because solving MAIL FROM is 
hard.  Once you decide to tackle MAIL FROM, also tackling HELO with the 
same tool is easy.
2. I think I would buy into the "small discrete functions and add to them, 
or add more" approach if it could be demonstrated to actually lead to a 
MAIL FROM solution.  In other words, CSV will always be faster on the 
100-meter than SPF is on the triathalon.
The CSV/HNA/DNA/etc approach to MAIL FROM seems to be something like:
1. Implement CSV/HNA/DNA/etc.
2.     (mumble mumble)
3. MAIL FROM is solved

If step 2 could be fleshed out a bit more, and doesn't amount to "a miracle 
occurs" or "await the natural course of evolution of the species" then I 
can see a reasonable comparison being drawn against an incremental path 
taking me where I want to go, vs. an all-in-one approach to my goal.  If I 
don't actually ever get to 3. then I'm not likely to take step 1. just on 
faith.
I know CSV and friends never claimed to be a solution to MAIL FROM.  That's 
fine.  No worries.  I just don't think it's fair to claim SPF is flawed 
because it tries to solve a more difficult problem.

> > 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.
Good point.

> 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.
Better point.


> > >   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.

BATV doesn't really solve MailFrom in the sense that other people can start 
rejecting forged mail claiming to be from me.  BATV and SES work well on 
the "blowback" symptom, not on the forgery disease.

> > >   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.

I guess I disagree with the characterization of SPF as complex and 
difficult.

> > 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 understand what you mean but I don't agree with it.  SPF is very simple 
to configure if we want to confine ourselves to solving only the problems 
CSV is also capable of solving.  For protecting your HELO name and allowing 
whitelisting on that name, it's actually much simpler.
In other words, when the goal is the same, SPF wins but CSV is a close 
runner-up.  When the bar is placed higher, SPF becomes more complex, 
whereas CSV takes a forfeit.  It's easy to criticize SPF for being more 
complex when used for more difficult jobs, but that criticism rings hollow 
if SPF-in-simple-mode still beats CSV.
Which brings me back to the original point of the thread.  Do CSV and SPF 
both work for whitelisting by HELO name?  Sure.  Is SPF easy to set up in 
that mode?  Yes.  Does CSV have an inherent advantage in the space?  Not 
really, as far as I can see.
(Again, please don't confuse any statements like "CSV is not applicable for 
X purpose" with "CSV is bad".  This message is not intended to express a 
position on whether CSV is good or bad, mostly because this is not the best 
forum for that.)
Thanks for taking the time to read.
gregc
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>