Subject: RE: Disappointed

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 22 Sep 2004 18:36:51 -0700

>   I am also disappointed at the putting off of the extremely important
> non-technical IPR issue until it was too late.  The members of IETF,
> wanting to be faithful to the 'E' in the name, naturally want to
> concentrate on engineering issues at least primarily, but even ONLY
> engineering, if that's possible.  I would like to suggest that if that
> is the desire, it is an impossibility.  You cannot 
> compartmentalize your work that way. 

The engineering issues are trivial and more or less irrelevant.

The problem has always been how to get ubiquitous deployment.

The spammers have won this round. That has consequences.

Those arguing that the ITU take over responsibility for Internet
standards will probably cite this result as evidence.

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 22 Sep 2004 19:59:36 -0700 (PDT)

I'll note a from the start that I'm dissapointed as well that IETF has
decided to close MARID, I was not expecting this outcome. However I do
not believe this is the end of standartization efforts of these
technologies as far as IETF is concerned.

> The engineering issues are trivial and more or less irrelevant.

Engineering issues are never irrelevent and they are certainly not trivial.
I'll note that current proposal based on CallerID algorithm basicly is
flowed as far as IETF existing standards are concerned. And I'm not 
certain Microsoft would ever agree to modifying algorithm if this were to 
cause it to no longer be subject its CallerID patent application. 

> The problem has always been how to get ubiquitous deployment.
True. And trying to push through proposal that can not be deployed by
open-source community is not a way to go forward with the process. 
You seem to forget here that 75% of MTAs in the world are in fact using
open-source email servers at their core...
 
> The spammers have won this round. That has consequences.
On this I do not agree for several reasons.

First - neither SPF nor Sender ID are anti-spam technologies, they are 
designed to provide better email security and anti-forgery protection, but 
they are not the "silver bullet" to spam. 

Second - the technology is not dead, we'll continue with SPF. It'll be
deployed (though admitedly it'd not be deployed quite as quickly and as
widely as it would happened were it to become IETF standard rather then
experimental RFC).
 
> standards will probably cite this result as evidence.

I'm somewhat sceptical about UN bureaucrats in general...
So I don't particularly see ITU as a solution in place of yet much smaller 
icann bureaucracy or non-bureaucratic ietf (which may well not be the
"perfect" standards organization but certainly comes much closer to 
representing interests of individual internet users then ISO or OASIS 
which are designed to provide forum of standartization primarily only for 
large organizations)

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 23 Sep 2004 00:33:06 -0400

----- Original Message -----
From: "Hallam-Baker, Phillip" <[email-masked]>
To: <[email-masked]>
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

---

From: Andrew Newton <[email-masked]>
Date: Fri, 24 Sep 2004 11:56:50 -0400

> standards will probably cite this result as evidence.

FUD!

-andy