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