Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: IETF SMTP Working Group Proposal at

  • From: william
  • Date: Thu Aug 22 19:08:08 2002

Why you think server should wait for callback or that I was proposing that?
I'd not want seconds of latency either. Maximum that would happen is need 
to keep hash of key codes for expected callbacks (cashed in memory or on 
disk). In any case, I'm not going to debate this here any more, number of 
people do not understand what I have in mind and have misconceptions about 
it so per multiple requests I'm putting my notes in order and will publish
them on the website to be futher discussed on the maillist I setup. If 
you're interested take a look at the website in a week or two and read 
the notes there.

On Thu, 22 Aug 2002, Brad Knowles wrote:

> At 4:40 PM -0700 2002/08/21, <> wrote:
> >  1. I want to create specification that would allow server operators
> >  themselve to decide what kind of verification they want, if you do not
> >  like callback, do not implement it.
> 	If it's not implemented by default in the standard MTAs, then it 
> is useless.
> >  2. Most estimate that up to 50% of mail system resources are used for
> >  processing unwanted email, viruses, etc. The amount of processing time due
> >  to new specification will be smaller then what has been gained from not
> >  having to deal with unwanted emails as much.
> 	No, the numbers are more like 75-80% at many sites.  But you're 
> talking many, many orders of magnitude worse.  You'd cause 99.999999% 
> of all work done on all mail servers around the world to be nothing 
> but waiting for callbacks to occur, and maybe some year an actual 
> mail message might be delivered.
> >  3. The processing is server cpu resource, while sending email is bandwidth
> >  used. I'll give up some more cpu resources to decrease used bandwidth.
> 	This has absolutely nothing whatsoever to do with bandwidth. 
> You're trading a few milliseconds of latency for dozens, hundreds, 
> thousands, millions of seconds of latency.  Try doing the math 
> sometime.
> >  4. For last years cpu speed & hardware have been increasing at 2x per 2
> >  years and are more and more powerfull. Even if the initiative goes
> >  through fairly fast (I projected2 years, that is already too optimistic),
> >  it'll be another 4 years at least before its used, by that time servers
> >  would be 8 times faster!
> 	The biggest thing that you need to work to eliminate in any 
> heavily loaded mail server is latency.  Specifically, what you tend 
> to work hardest to eliminate is latency caused by waiting on the disk.
> 	Now, disks typically have latencies measured in terms of a few 
> milliseconds, and you want to replace this latency by another process 
> that will have latency that can be measured in minutes, hours, and 
> days?!?
> 	So, just what kind of drugs have you been taking lately, eh?

Discussion Communities

About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home

Merit Network, Inc.