Ken Rossman (sy.Ken@CU20B.COLUMBIA.EDU)
Thu 26 Feb 87 21:44:19-EST
> The server should NOT make the client wait while a message is
> being delivered...
I faced this issue when implementing our mail relay. I decided that the
client SMTP would have to wait while the relay delivered the message...
I think the furthest the acknowledgement process should go is essentially
"message received by this host and queued for delivery locally". In so
many cases, there's often too much processing involved in delivering to the
final destination mailbox that the sending system should NOT have to wait
for all of this to go on. I see the cases of local mailbox delivery and
mail forwarding as the same. For example, host A wants to send to host C,
not on host A's network. It must therefore forward through host B. Should
host A have to wait while host B tries to forward the mail through all the
way to host C? This case is clearly unreasonable. The local delivery
process can often be just as unreasonable for a variety of reasons, and
thus, the mail should be stuffed into some local delivery queue (which
would presumably be a fast process), and actual local delivery can then
happen asynchronously with the SMTP dialog. If there is some fatal case
where the mail cannot actually be delivered after being queued on the
target system for local delivery, then the entire message can be returned
to the sender by the mailer. This is how the TOPS-20 mailer works, and it
seems like a fairly airtight procedure in practice as well as in theory.
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:37:42 GMT