nanog mailing list archives

Re: IETF SMTP Working Group Proposal at smtpng.org


From: <william () elan net>
Date: Wed, 21 Aug 2002 16:40:54 -0700 (PDT)


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.
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.
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. 
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!

At 2:15 PM -0700 2002/08/21, <william () elan net> wrote: > 
 Your quite wrong. With email we do in fact know "phone" for the calling
 party - its their FROM address and for callback we can specify if we trust
 or do not trust the other party to provide some different domain, so they
 may not be given a change to specify where to callback to. As example If
 they are trying to send email from <me () somedomain com> the callback would
 have to go to somedomain.com mail server and the callback must use the
 authorization code given during initial mail call. The callback can also be
 authenticated with TLS giving even more security that somedomain.com is a
 real operation. This will prevent 99% of spammers just there.

      It's bad enough waiting for DNS responses so that you can 
determine whether or not the envelope sender domain even exists.  Now 
you want to slow down every single e-mail transaction by many, many, 
many orders of magnitude so that you can do a callback on each and 
every connection?!?

      Man, wanna talk about ideas that would bring all e-mail to a 
complete stop across the entire Internet?  Imagine what it would be 
like if AOL did this, so that it could take five, ten, or even 
fifteen minutes just to get one callback on one message, if the 
remote server was slow enough.  Now, if you start up a sendmail queue 
runner every sixty minutes, you only need a very small number of 
messages in your queue before you start stacking up more and more and 
more sendmail processes, until such time as you run out of memory, 
your mail server crashes, and you might potentially lose all your 
queued e-mail.


      Jeezus.  Do you have to be the one guy who got blamed for 
shutting down all e-mail across the entire Internet on "Black 
Tuesday", just to see the flaws in this plan?!?




Current thread: