IETF SMTP Working Group Proposal at smtpng.org

Brad Knowles brad.knowles at skynet.be
Thu Aug 22 23:27:28 UTC 2002


At 3:50 PM -0700 2002/08/22, <william at 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 at 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(+++)



More information about the NANOG mailing list