IETF SMTP Working Group Proposal at smtpng.org

Wed Aug 21 23:40:54 UTC 2002

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 at 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 at 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?!?
> 