Re: [Asrg] MTA registration means Path registration

[Jim Witte <jswitte at bloomington.in.us>]

Alan DeKok wrote:
> > DC> in any event, it it does not warrant calling an infrastructure 
> > with a
> > DC> 30-year history 'broken'.
>   Oh, I see.  Nothing's wrong with SMTP, nothing's wrong with the
> current implementation and deployments, the whole virus/spam problem
> is a figment of our imagination.  Right...

  There may be nothing wrong with SMTP, *for the purpose and original 
populataion* for which it was intended.  A population which did *not* 
(for the most part) include virus-writers and spammers.  To make a 
biological analogy: Viruses and spam can be seen as an invading 
pathogen in that respect (I've seen stretchier analogies in this 
thread..)  What does a biological organism do when a new parasite 
evolves?  It adapts!  Perhaps that's what needs to happen to SMTP, and 
I think this is what Alan is saying.

  An interesting question: if there *were* another email protocol out 
there that were as easy to use, and as widely deployed as SMTP relays, 
that somehow (magically) did *not* have a problem with spam - and not 
because spammers did not *try* to use it, but because it was designed 
(or evolved, if you prefer) in a way to thwart spam attacks - would the 
current SMTP protocol last a minute?  I don't think so.  People would 
move to the new system, and the current SMTP protocol would "die", just 
a a non-evolving biological organism faced with a new pathogen would.

  Now, does anyone here know what that system is?  No, of course not.  
If we did, it would be written into a spec, and used (by some people at 
least).  But to say that the current system is handling the *current* 
population of email users (which includes spammers) just fine (with no 
detriment to other, "legitimate" users of the system, is wrong.

  The SMTP protocol came out of an environment of trust, the same 
environment out of which came the open-source movement.  One of the 
tenants of the OSS movement is that if a program doesn't suit one's 
needs, one can get the source and change it.  Evolve it, if you will.  
If we as a community accept that model for *individual* programs and 
*individual* users/developers, why do (some of us) reject it for entire 
*systems* and *populations* of users?

> > AD>   The confusion arises because you're trying to treat each MTA as
> > AD> being identical.  They're not.
> DC> there is nothing in the current Internet mail service that 
> supports your
> DC> view, technically.

  Technically, no, there is not anything to distinguish different MTAs. 
 But I don't think Alan was not trying to *techniclaly* distinguish 
them.  He was trying to create terminology to describe their *function* 
as part of the entire email system.  To make another biological 
analogy: 50 years ago, all we knew to describe DNA was base pairs.  
Over the past 50 years, as our knowledge of how DNA works, we have new, 
higher-level ways (a new "language" if you will) for describing DNA: 
protein-coding genes, control genes, introns, exons, transposons 
("jumping genes"), SINEs, LINEs, etc..  And we are starting to develop 
a new language for describing cellular processes related to DNA: 
histone proteins that control folding of DNA in the nucleus, repressor 
proteins (and molecules), activator molecules, etc.

  My point is this: does this new language make the old language of 
describing DNA in terms of only base-pairs obsolete?  Of course it 
doesn't.  It just adds another layer on top of it.  We all know about 
the OSI model here, right?  SMTP is at the top in the application 
layer.  Perhaps we need another layer to describe *how* people use 
applications when they are interconnected into systems which may have 
malevolent components (spammers and viruses/worms).  Note that I am 
using 'system' here to describe not just the commuicating SMTP 
processes on different computers, but to describe the *humans* (or 
other agents, like mailing-list processors) which actually use these 
applications.

Jim Witte
jswitte at bloomington.in.us
Indiana University CS


_______________________________________________
Asrg mailing list
Asrg at ietf.org
https://www1.ietf.org/mailman/listinfo/asrg