Re: So here it is one year later...

----- Original Message -----
From: "Douglas Otis" <[email protected]>
To: "Hector Santos" <[email protected]>
Cc: <[email protected]>
Sent: Monday, January 31, 2005 9:23 PM
Subject: Re: So here it is one year later...


> On Mon, 2005-01-31 at 16:50 -0500, Hector Santos wrote:
> > Please Doug.
> >
> > You can't guarantee that an immediate router will be CSV compliant.  So
you
> > have the same heterogeneous/mixed policy issues as SPF and all the rest
of
> > the proposals.
>
> If the sending SMTP client publishes a CSV-CSA record, then this client
> is both authenticated and authorized by the HELO domain.

The "chain of trust" issues with SPF applies to CSV as well.

What about the downlink?   Once the message is received, it is your
responsibility to deliver it.   My sender went directly to you, the MDA. If
you decide to route it instead, then you have to maintain the chain of
trust.   You can not guarantee this transaction when you become the sender.

> > In addition,  you have a MUCH higher overhead than most as you based on
> > state point #1 - HELO/EHLO.
>
> Authenticating the HELO is done within a single lookup with CSV.  How
> can this be a higher overhead?

I don't think you really understand the implementation issues of your own
proposal.  Maybe you do and are just turning a blind eye.

> > Now why would I want to do a HELO CSV check without determining:
> >
> >     - Check to see if the sender is valid,
> >     - Final vs Route
>
> MASS is addressing the need to safely authenticate the administrator of
> originating sender domain.  ....

You didn't answer the middle-ware, chain of trust issue, and you didn't
address the above.

Delay verification is a REQUIREMENT, not a BCP for all DNS based
authorization ideas..  I have statistic proof with over 1 year of product
operations in thousands of installed sites:
http://www.winserver.com/spamstats.

The functional model of CSV is:

            EPV = CSV(helo, ip)

which fails to take into the account the validity of the other process
environment parameters, MailFrom, RcptTo.   That my friend, is a overhead
issue.

> > But what if the SMTP operator does not want to use your new MAPS CSV/DNA
> > service?  What if you go out of business?   What if you get enough
support
> > headaches from thousands of smaller systems that you decide to raise the
> > price to filter out these bothersome clientele?
>
> This seems to be putting the cart before the horse.

No. It is called business and practical product experience.  You are
proposing an idea infested (wrongly placed) with capitalistic commercial
concepts, which I don't mind saying,  you will be among the first to benefit
from as the first DNA commercial service.  PR problem #1. Therefore, if we
were support and implement CSV,  we would have to include a disclaimer for
any Anti-Spam CSV support statement; "Batteries Not Included. DNA Service
Subscription Required."   We are not going to add what is suppose to be a
"technical" solution with subscription concepts behind it.  Period.  PR
problem #2.    My Advice?  Dave should take Doug out of the CSV promotion
picture.  You don't do CSV any justice.

Dont' get me wrong. I'm for making a buck as much as the next guy. But the
"Email Problem" needs an open standard technical solution free of 3rd party
dependencies.   It is a duel tier process.  Transport security must be done
using SMTP first.  Main Content Security is an separate issue, however,
there can be a tie in of the two, but not dependent on it.

The point is, if you send me mail,  I must be able to trust the transaction
before I accept your payload.  Authenticating the payload is an
ADMINISTRATIVE concept.

Using a CSV authorization domain is not sufficient WITHOUT looking at the
2821.Mail From as well as 2821.RCPTTO.  Therefore, as it has been
emperically proven, using HELO by itself would be wasteful overhead without
taken all process environment parameters into consideration.

I have PROOF of this issue. Doug. All you are doing is making assertions of
the opposite and you have no proof to show I am wrong.

Sincerely,

Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office