ietf-mxcomp
[Top] [All Lists]

Re: Disappointed

2004-09-22 21:36:47


----- Original Message -----
From: "Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com>
To: <ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Wednesday, September 22, 2004 9:36 PM
Subject: RE: Disappointed


The engineering issues are trivial and more or less irrelevant.

Phillip, I respectfully disagree.

I believe this has been the fundamental reason why there was no censensus.
These administrative based proposals were crippled from the onset due to the
lack of understanding technical SMTP operations in the market place, which
include concepts such as Dynamic vs POST SMTP mail analysis. A important
distinction in how these proposals work or do not work, and more important
how it related to product and operator liability issues.

The problem has always been how to get ubiquitous deployment.

and this begins by with stepping back and understanding the barriers to
deployment.

What is needed is a clarification of the SMTP functional specification with
the removal of all loop holes at the "specification" level.   Once that is
done,  then the software vendors and administrators have a basis to get a
clear picture for the operability and reliability of ESMTP based security
proposals (MARID) and how the software is implemented by administrators.

Basic example:

Both CSV can work, it needs to lay the ground with a new 2821 specification
that will enforce the CVS entities to exist.  Current software developers
can upgrade their software based on the new 2821 alone and new SMTP
developers have new 2821 document to use a framework.  This will great a
market of growing compatible products.  Once this is done, then CSV and SPF
proposals will work better.

Until that happens,  what is left is a suite of solutions required by the
vendors. Just consider a product like ours which provides a 98% reject rate
based on 5-6 suite of methods in place.   We must write and run our SMTP
software such a way that is based on the idea that no one single method will
cover it all.

At the moment, we get one or two high reliable methods, people will adopt
because the software vendors will adopt the technology.

But that won't happen until we revisit SMTP and get that straight.

Anyway, this is all deja-vu: "Administrative vs. Developer" philosophical
conflicts has always hampered progress, especially in an area so important
that requires a costly revamp of operations from end to end.

Sincerely,

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



<Prev in Thread] Current Thread [Next in Thread>