Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!UCBARPA.BERKELEY.EDU!jordan
From: jordan@UCBARPA.BERKELEY.EDU.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re: When to acknowledge SMTP messages
Message-ID: <8702270047.AA17154@ucbarpa.Berkeley.EDU>
Date: Thu, 26-Feb-87 19:47:02 EST
Article-I.D.: ucbarpa.8702270047.AA17154
Posted: Thu Feb 26 19:47:02 1987
Date-Received: Sat, 28-Feb-87 06:14:45 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: Experimental Computer Facility (XCF), UC Berkeley
Lines: 18
Approved: tcp-ip@sri-nic.arpa

Kevin Crowston writes:

	I decided that the client SMTP would have to wait while the
	relay delivered the message.  Otherwise, the relay could
	acknowledge the message and then crash or discover that the
	destination mail server was unable to take the message.

Sendmail seems to handle this correctly, since "delivered" to that part
of the code means "placed in the queue" (i.e., wrote it to disk ... if
the machine then crashes, the daemon will pick up where it left off
since the queue file is still there) -- you can't acknowlege the
message as being sent before you have firm control of it.  That's what
lock-step is all about.  Once you have done that, if you find later
that you can't deliver it, it's up to the recipient SMTP process to
send it back to where it came from.  This can be handled
asynchronously.

/jordan