ietf-mxcomp
[Top] [All Lists]

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

2004-11-26 09:43:32
Again.....it's incredibly short sited to think that email will be a forever
pervasive medium. While we need stopgap measures, trying to redesign SMTP is
a waste of time. I think we're all much better off putting our efforts into
making sure next generation messaging technologies don't have the same
flaws, than bothering a lick with changing SMTP. Perhaps helping to prod
everyone into using all the standards that are out there already for mail
transport and handling, and implementing them properly is a good idea. The
next generation is already on it's way......

-Tom

thomasgal(_at_)lumenvox(_dot_)com  

-----Original Message-----
From: owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org 
[mailto:owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of 
william(at)elan.net
Sent: Thursday, November 25, 2004 4:18 PM
To: Alan DeKok
Cc: MXCOMP
Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] 



On Thu, 25 Nov 2004, Alan DeKok wrote:

  It's not 1984.  20 years have gone by.  SMTP won those 
wars and all 
of the protocol wars which followed.  No one is arguing 
that we should 
replace SMTP with X.400, or any other non-SMTP scheme.  I'm 
not one of 
the X.400 people.

I've argued and will be happy to argue again that SMTP needs 
to be replaced with new protocol entirely instead of putting 
more and more band-aids on 20 year old protocol that was 
designed for "simple" mail transactions.

But creating new mail protocol to replace SMTP would take 
long time (both in terms of IETF process to create this new 
protocol and process for it to achieve wide-spread adaption) 
and spam is a serious problem in our current and immediate 
situation of using email so we have to do something with what 
we have (i.e. SMTP) to get this under control and only after 
that can we take a look at entire thing and see if we can 
come up with something better taking into the account all the 
lessons with have learned with what works and what does not in SMTP.

--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net

Attachment: smime.p7s
Description: S/MIME cryptographic signature

<Prev in Thread] Current Thread [Next in Thread>