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

Is this a CANNED reply message?   It sure reads like it.

Look,  CSV does not pass the test for consideration.  That might explain why
no commercial vendor has implemented it.

And we were not talking about MASS.  We are talking about the fallacy of CSV
being immune to heterogeneous/mix policy topologies and lacks overhead
issues.   You are wrong in both cases.

I think you are saying MASS solves these problems for CSV.

Well,  that's a PAYLOAD solution so it doesn't address the heterogeneous/mix
policies and overhead issues at the SMTP level.   So I believe you are
incorrect here as well.

Anyway, I don't wish to get another canned reply, so I think I'll stop
here.:-)

Thanks for the chat

Sincerely,

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



----- Original Message -----
From: "Douglas Otis" <[email protected]>
To: "Hector Santos" <[email protected]>
Cc: <[email protected]>
Sent: Tuesday, February 01, 2005 3:46 PM
Subject: Re: So here it is one year later...


>
> On Tue, 2005-02-01 at 08:23 -0500, Hector Santos wrote:
> > On Mon, 2005-1-31 at 9:23 -0500, Douglas Otis wrote:
> > > 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.
>
> CSV does not make assurances for MAILFROM or FROM mailbox-domains.  The
> HELO identifies the administrator of the specific MTA.  It is the
> administrator trusted and not millions of users that may be using the
> server.  When there is a problem, ONLY the administrator is able to
> rectify the situation.  In essence, mail is not secure and the source of
> a message is not assured beyond the immediate server.  It is wrong to
> assume a "chain of trust" is maintained, as this could be injurious to
> those assumed to be the source of the message.
>
> MASS avoids the fallacy of a "chain of trust" by using a digital
> signature.  SPF assumes identities are checked at each stage against a
> lengthy resolution of path registrations.  There is also no consensus
> which mailbox-domain is checked, if any, even assuming these checks were
> practical and safe.  Schlitt's SPF draft says to use some identity as an
> alternative without indicating whether this is the PRA identity or
> something else. : (
>
> > 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.
>
> Most MTAs only accept mail from anonymous sources being sent to their
> immediate domains.  Most MTAs also decide whether to accept from an
> anonymous source based upon reputations of the IP address.  Without such
> checks, few could afford the bandwidth needed to permit legitimate mail.
> You are describing a practice that could put the reputation of the MTA
> IP address at risk.  A reputation service should never consider an
> unauthenticated identity within the message as being culpable.
>
> > > > 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.
>
> Information provided by SPF only indicates who may have sent the
> message, and not who actually sent it.  Resolving issues of abuse by way
> of SPF is potentially injurious to mailbox-domain owners.  CSV ensures
> accountability remains with those administering servers and not a
> possibly hapless customer.   Essentially SPF is a weapon that does not
> always shoot straight and therefore should not be used as an abatement
> tool.  SPF does not eliminate the need for administrators to control
> access to their servers nor remove the need to watch for abusive
> accounts.  In addition, SPF is a paper tiger easily destroyed.  MASS
> however is attempting to safely provide a real means to control use of
> the sender mailbox-domain.
>
> MASS provides this domain control to protect users, whereas CSV and BATV
> protect networks.  SPF is unable to offer any real protection for either
> users and definitely not networks.
>
> > > > 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.
>
> The use of a digital signature avoids false assumptions of there being a
> "chain of trust" as the mail channel is not secure.
>
> > 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.
>
> Inordinate overhead must not be placed upon the receiving MTA.  CSV
> delegates source control overhead onto the administrator accountable for
> the server.  There are many tools to assist in their effort.  Monitoring
> the SMTP error logs, unusual traffic patterns, as well as abuse
> reporting.  CSV helps ensure this reporting is directed to the
> accountable administrator.  SPF alone will not abate abuse, while it may
> produce victims as it is applied in conjunction with reputations.
> Spammers will simply adapt and take advantage of these false assumptions
> being made by SPF.
>
> > > > 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.
>
> CSV is offering an authenticated name for the sending MTA that helps in
> many ways with respect to dealing with the email abuse problem.  The
> transition to the use of names will likely be an immediate benefit to
> those already providing vouching services.
>
> > 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.
>
> An immediate benefit of CSV comes from being able to associate an
> authenticated name with the immediate sending MTA.  MASS offers the
> feature that allows control over the sender mailbox-domain regardless of
> the immediate sending MTA.  The blunt instrument provided by CSV
> protects the network from grossly negligent administrators.  MASS should
> be able to protect users from those wishing to spoof sender
> mailbox-domains.  MASS/CSV can work together in a unified name basis for
> guarding mail.  SPF will not remove the need for some form of
> reputation/vouching service, nor remove the need for some form of
> network protection.
>
> > 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.
>
> There were several companies touting reputations services at the FTC
> Email Authentication Summit.  I was not promoting such a service.  I was
> insisting upon adoption of a safe and accurate means to assess abuse.  I
> remain convinced MASS and CLEAR are considering viable solutions.
>
> > 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.
>
> Authenticating the payload is the subject of an ongoing effort in MASS.
> I want to see MASS succeed in providing an effective solution that can
> protect the sender mailbox-domain.
>
> > 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.
>
> Holding the sending domain accountable offers substantial relief without
> a need to sort through millions of users employing various
> mailbox-domains within thousands of various providers.  There is a fair
> amount of experience that supports this view.
>
> > 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.
>
> This is not the proper venue for product related data.  Most of the
> benefits claimed by SPF are related to changes in behavior, and not
> cessation of abuse.  As an immediate source for relief, BATV would be
> more effective in preventing the unwanted bounce traffic as this can be
> done unilaterally.
>
> -Doug
>
>