RFC 1047


Mark Crispin (Crispin@SUMEX-AIM.Stanford.EDU)
Fri, 26 Feb 88 14:01:38 PST


[Please forgive any partial message which may have gotten out...]

Craig -

     I read your RFC 1047 with a great deal of interest, since I've been
battling this problem for many years. I suggest that RFC 1047 should be
included with any distribution of "Internet mail RFC's", since the issues
it addresses are important.

     I am in full agreement with your recommendations, and in fact the
TOPS-20 mailsystem has always used that strategy. More specifically, the
TOPS-20 SMTP client will wait up to 5 minutes for a response from the SMTP
server, and the TOPS-20 SMTP server limits its actions upon receiving the
EOF "." to closing the mail queue disk file and sending a "wake-up" interrupt
to the mailer, both of which are relatively fast operations.

     I have found that the law of diminishing returns comes into play with
much greater timeouts. Specifically, an SMTP client which waits twice as
long (10 minutes) before its patience is exhausted does not receive much of
a reward in terms of additional successfully delivered messages, but does
receive a punishment in terms of reduced throughput due to servers which
never do come back.

     I am also not convinced that the delay in sending the "wake-up"
interrupt to the mailer is worth the benefit (the mailer starts work on the
queue right away instead of waiting as long as five minutes for a wake-up
from other sources) of immediate delivery of incoming netmail. In perverse
circumstances, a delay of as long as 20 seconds can happen in the course of
attempting to send the "wake-up", and another delay of 20 seconds to receive
an acknowledgement. Since these "perverse circumstances" generally happen
during periods of extreme load, the resulting 40 seconds can, in theory, be
stretched to a much longer period of time. I have never observed any
problems of this nature; the SMTP synchronization problems I've observed
with the TOPS-20 server have been either a lower-level (TCP or IP) problem
or a bug in the other system's SMTP client. However, it is something that
I worry about.

     In general, with electronic mail, if there's a choice between doing
a time-consuming act in the server and doing it asynchronously, pick the
latter choice. Make your SMTP process be a minimal bit-pusher.

-- Mark --



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:41:30 GMT