inline
However, I don't see the "NG" going to have to same effect
today, not as a answer to the spam problem. The industry
cost would be too vast to have a
revamp to a NG. While NG is on its way and many already
feel they already
have a NG system, such as our own, specifically our issue is
the external interface into the system, the INTERNET gating
into our backend framework.
So in my opinion, it is unrealistic to believe a NG is going to be our
"solution." You will still need to deal with the outside world.
Yes, the industry cost is to great do to ANYTHING that requires
abrupt adoption, which is an obvious plug for tools like BATV that depend on
no one else to be effective. But I honestly believe that the tradeoff needs
to be made, and made in favor of the future at all times. ESPECIALLY in
cases like spam and viruses, which are merging anyway, where the problem
adapts as soon as a hole is plugged. We need to deal with customers (which
is really who we're talking about here) in the now. I'd love to see a
comprehensive db/wiki/website cataloging spam behavior much like viruses
are by security companies, with testing code and examples for people to
reference because that would help us all. And that certainly would involve
analyzing the characteristics (I'll avoid failures and weaknesses) of SMTP,
but the fact remains that things like SPF/Sender-ID/CSV/BATV/Y! DK/Cisco
IIM/ etc. are here to address the situation now. All I was ever trying to
point out was that any analysis of SMTP specifically precludes itself from
aiding the current situation.
But this is besides the point. No one, at least not me, nor
anyone else I believe, is suggesting a complete change to the
SMTP system. What I am suggesting to look at the protocol to
see what is wrong and what can be done
TODAY to fix the key issues with it. People who have analyzed it
thoroughly along with analyzing the proposal add-ons, can
gain from having a common new ESMTP or expected mode of operations.
Be careful here. Any change is a complete change, and MANY people
are saying that. MANY people are saying "so and so is afraid to say SMTP is
flawed because it's holy" and "We need to analyze SMTP to fix the problem."
Now mind you in that case that's exactly what people are doing. The reality
is that most MUAs and MSAs (which frequently are the same or badly
classified) as well as many MTA's don't conform to standards completely and
that as well is an issue. All of these problems originate from the openness
desired by designers of the original internet's conditions. The reality is,
that not only is SMTP not perfect for secure(from a authent/author
standppoint) transfer, it has no business being involved in it at all. That
again is why I keep pressing the forward looking attitude.
IMO, MARID failed because of this lack of analysis. This
lack of analysis
has provided a no-win situation for many of the proposals
which all come back to the same thing - how is SMTP used.
Besides the IP issues with it, one required it to work this
way, the other required it to work that way.
One doesn't require a change at all while another requires a
drastic compliancy change, etc, etc.
Right....how SMTP is used which is improperly. People don't conform.
People are not authenticated. Systems are not idiot proofed. People are
confused. Obviously the first issue is that perhaps any communications
protocol for human interaction MUST have only MUST and SHALL NOT qualifiers.
Of course we've moved into an era where *hopefully* people realize the
ramifications of non compliance in light of the past.
What are the common issues here? I know some answers to
that. Do you
(speaking in general)? These needs to be debated widely
and IMO, I
believe strongly that the proposals will benefit from having
a common expectation of how SMTP will work, and then some.
I agree in the end. This all kinda leads back to real engineering. QA and
process refinement, which can also solve many of the technical burden issues
revealed in the RFC on IETF problems and IESG workload. We do indeed need a
compliancy change. And a process change. I think a good analysis of the
issues here, as well as the aruable issues with IPv6 as well as some of the
other protocols which have never been adopted, or failed seriously is in
order. This isn't just a simple little protocol. Really it's the future of
communication we're looking at here. Alas how to factor in the pragmatic
realization of endless struggle?
-Tom
smime.p7s
Description: S/MIME cryptographic signature