----- Original Message -----
From: "Dave Crocker" <dhc(_at_)dcrocker(_dot_)net>
To: "Alan DeKok" <aland(_at_)ox(_dot_)org>; "MXCOMP"
<ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Sunday, November 21, 2004 2:18 AM
Subject: Re: FTC stuff 0) Lies 1)Yahoo & DK. 2)GoDaddy DNS & SPF & CSV.
3)Dean & FUSSP. 4)Testing 5)EFF, Anonymity.
> For three, my statement was talking about failures of a model, not
When you referred to SMTP you said nothing about a "model",
nevermind a security model. To the extent that you really
meant to refer to a particular security model, then by all means
please state that, rather than broadly describing that a long-standing,
well-functioning protocol as a "failure".
We all know that SMTP has not been a failure.
What Alan is suggesting, for which I strongly agree, is that the focus in
solving the "problem" needs a revisiting of the SMTP model or more
specifically, the functional specification. We have tried to "plug in"
ideas that simply fail to account for the entire MODEL for not only
maximum
compliancy but for productive and maximum adaptability. In some cases, we
attempted to plug in concepts that simply doesn't fit or is out of place.
Just consider this one very simple realistic fact:
A system that employs stronger SMTP compliancy enjoys a higher SMTP level
protection against abuse.
We have more than 1 year of steady on-going Anti-Spoof technology in place
with a consistent result on a
day to day, month to month basis. A simple emphasis on compliancy will
provide you atleast a 60-90%
solution. I can't dispute these. These are the hard core empirical
facts.
The point?
The majority of the problem is solved by concentrating at enforcing a new
level of "proper" operations.
We need to get over the "silly" arguments about what "MAIL FROM:" means.
We know what it means because its been operating in a consistent DEFINED
way
for decades.
We need to be consistent.
If we discuss functional SMTP design flows for system notifications which
is
based on the expectation that the return path is "usable" then we need to
stop with idiotic suggestions that the return path is only "usable" at the
point is it required - a system notification, and not before then. We
need to make sure the specifications makes it very CLEAR that the RETURN
PATH is expected to be valid, regardless of who it points too when it is
initially issued. The idea of how a particular system may which to
implement that is an independent idea. It has nothing to do with the
validity of it.
Now, can we improve SMTP to better describe what the RETURN PATH is?
user,
system, some list or whatever? Sure, but what is common in all, is that
its
a valid address.
Can we add new commands to help a "new process?"
I think so. But we need to first look at what are the "holes" or factors
that are "missing" to help define what these commands should be.
Do we need to consider future payload transaction protocol methods?
Sure, I strongly think so. This is one area I felt very strongly that
didn't not help Sender-ID, it failed to 100% recognize the payload issue
and
how important that is. But I personally see the payload issue in a
bigger
concept than just for security, but for efficiency.
This is the kind of SMTP R&D WG discussion that needs to take place. I
doubt this can happen in IETF-SMTP. The type of people and attitude is
just
wrong for it. We need new open minded people who can think out of the
"box", and also understand the issues, and then with the help of the
'experts" like yourself, help bring it all back together. What we don't
need is are show stoppers who nix everything right at the start.
Once we get a consistent understanding of the issues with SMTP at each
step,
removing the ambiguities, adding/merging BCP concepts/RFCs for "today"
operations, then we have a basis, an baseline, a framework to begin
implementing "Security Plug-ins" that will not only work better, but make
sense.
This may all sound simplistic to you, but that is what we need; getting
back
to basics, taking a step back in the balcony.
The #1 improvement we can make or the IETF can make is a major cleanup of
the 2821 and related specifications as one new document.
Sincerely,
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office