RE: A new SMTP "3821" [Re: FTC stuff...........]

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