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" <dotis(_at_)mail-abuse(_dot_)org>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
Cc: <ietf-mxcomp(_at_)imc(_dot_)org>
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