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