At 3:50 PM -0700 2002/08/22, <william@elan.net> wrote:
Why you think server should wait for callback or that I was proposing that?
Okay, so you queue the incoming messages until you can get an asynchronous callback. One of the biggest performance wins for mail servers is to completely avoid any disk I/O at all in the case of the successful initial delivery attempt. You would cause this feature to be effectively eliminated, by forcing the majority of all incoming mail to be queued. Now, I guess you could temporarily refuse to accept the message, forcing it to be queued on the remote end. But certainly large mailing lists take big advantage of the "no disk I/O" feature, so you would be penalizing all your users who are subscribed to mailing lists that operate this way. Indeed, by making their mail delivery significantly slower, there's a good chance that the mail might be removed from the queue before the callback is successful, and they would be likely to be much less happy with slow message delivery caused by your system.
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).
Right. Check the logs of your mail servers. How many unique servers contact your machine to deliver mail to your users in a day? Maybe at your site this would be a manageable number, but I can guarantee you that with many millions of messages handled per day, this kind of thing is simply unthinkable at larger sites.
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.
Setting up your own mailing list for this stuff is not likely to result in any useful outcome. If you want to create your own proposal and write it up, please do so. But when you're done, you should discuss that proposal in the places that already exist to discuss these sorts of things, such as some of the IETF mailing lists, certain other popular mailing lists (other than NANOG), certain popular USENET newsgroups, etc.... -- Brad Knowles, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)