Re: WG to close ; Re: Make CSV backwards compatible with SPF? (new revisions)

On Wed, 2004-09-22 at 22:18, Hector Santos wrote:

<snip>
> CSV is a solution based on two methods: CSA vs. DNA.

CSV is a suite of specifications that also includes DNA. I would expect
DNA to become useful after inroads have been made to help promote the
use of CSV.  I would imagine typical white-listing services together
with rhsbl services would get the ball rolling. 

>   I understand all the arguments for your design, however, I don't
> think you (among others) have completely understood the deployment and
> real operations paradigm that makes CSV conflictive:
> 
> First, this applies to all proposals.  The EHLO/MAIL FROM validation is
> useless if RCPT TO is invalid.

CSV allows the construction of name based relationships to relate
mailbox domains with the mail channel, as example, without requiring
subsequent lookups.  This alone is a significant advantage from several
perspectives.  The identity obtained from CSV relates directly to those
that administer the MTA and must be held accountable if to curtail
abuse. 

>   We already covered this in our emails a few months back.   I believe
> I concluded that it should be mentioned in the specs.
> 
> Second,  it is possible to use CSA only for True Negatives.

I have shown in the marid-mpr draft, the results of these lookups
provide the same results over a scope of MAIL FROM, From, or even PRA. 
The basic difference is a deterministic DNS overhead that needs but a
few lookups.

> What are true negatives?.
> 
> Here is my extended terminology for establishing the level of trust in the
> email arena:
> 
>     False Positives - a Pass that was deemed incorrect upon inspection
>     True Positives - a Pass that was deemed correct upon inspection
>     False Negative - a Reject that was deemed incorrect upon inspection
>     True Negative - a Reject that was deemed correct upon inspection

I do not think you understand what it is that CSV provides by going into
these details.  You get the same results with three really major
differences.
  
1) CSV provides the strongest possible identity that DNS allows which
   happens to relate to the MTA administration.

2) The mailbox-domain/mail-channel association can optionally act in the
   role of a gate-keeper without an open-ended association being
   exploited.

3) The overhead is always low and deterministic.  

> For example:
> 
> A EHLO check that results in a REJECTION is a 100% Trusted result.  This can
> be fundamentally proven with local domain EHLO checks, i.e.,  An anonymous
> IP trying to use your own domain(s) for the EHLO command is an easy spoof
> check.
> 
> However, an EHLO check that results with a PASS is not a 100% trusted result
> and needs further scrutiny.

CSV provides the means to apply this additional scrutiny at the smallest
possible cost by using a simple name list.

> This is where you use DNA as a well to check the trust of the result. What I
> am saying, you only need to do this for a PASS, not a rejection.   What this
> means is that your lookup method needs to take into  account this overhead
> reduction concept.   Currently, the lookup says to do DNA first, then CSA.
> I say CSA first because .....
> 
> Third,  DNA is too exclusive.

DNA provides for a large market of white-listing services without
requiring a polling process across many to be made.  By no means does
CSV limit what can be used.  The drafts mention any rhsbl can be used. 
Of course rbls can be used as well, but it is my view a rhsbl would
over-ride the rbl.

> CSV will not get adopted unless it has ready DNA sites. The problem I have
> is how to offer it to customers from a marketing standpoint.   We can't make
> a claim for "new anti-spam technology using CSV" with a footnote that says
> "requires double A batteries (DNA) in order to work."

Good point, but but you don't need DNA.  With CSV in place, the ability
to offer comprehensive name based information will change what can be
obtained from these types of services and the relative overhead needed
to maintain this information.  A lower cost of business in this area is
good all around.  It also means having a name that you can confidently
protect.  With Sender-ID and SPF, you must cross your fingers the
service provider you use gets it right, or you suffer.

>    If they are only 1 DNA site (MAPS for example), then this will
> critical some issues that need to get worked out.  So at this point in
> time,  CSV is put on the back burner.

Although they are small at this point, there are other rhsbl.  There are
other service providers that, for the most part, specialize in
white-listing.  CSV is ideal for both dropping the hammer and
white-listing the good guys.  You could not ask for a better tool.  

> I think overall, it will continue to have this DNA stigma.  But I think we
> can use CSA by itself.  The same applies to SPF for EHLO "True Negatives"
> checks.   But SPF suffers from its relaxed provisions.  SPF HELO checks can
> only be TRUE or FALSE, not soft or neutral.  It is not logical.

I see CSV and an MPR approach removing one of the major stubbing blocks
found with SPF.  Among several that are all related to the same issue,
leaving the association "open" with SPF is an exploit waiting to
happen.  The CSV MPR method removes that invitation.  I feel like the
guy in the movie Graduate giving advice, but rather than saying
"Plastics", I am saying "Names".  "Names" is the future in DNS.

-Doug