On 2/3/2007 6:05 AM, Tony Finch wrote:
So the question is whether adding a final response after the per-recipient
resposes helps with this problem.
Whichever design we choose, the client is still in trouble if it loses the
tail of the server's final per-recipient replies.
The only solution to RFC 1047 is checkpointing.
A robust mechanism only requires the server to know that the client
received the entire list of responses: if so then the client is not at
obvious risk of resending; if not the server can refuse to accept
responsibility on the grounds that the session was lost. So all we need is
a way for the client to send SOME KIND OF DATA, after the server has sent
the full list.
Using a reliable transport like TCP and decent synchronization in the
protocol, this can be done with the client merely issuing another command,
such as QUIT. This falls apart when clients are broken though, eg close
without QUIT, or client hits a bug and starts spewing commands that it
shouldn't, all of which happen often enough. I don't know if we need to
design for that level of disaster though--it's not really accommodated
anywhere else. It might be worth putting a client command in there
("DRR-DONE") just to avoid any problems that may crop up.
My current design is somewhat thinner than that--if the server is able to
write() the final response code without error, then it should be safe to
assume that the client received the full list as well as the final
response and the mail belongs to the server now. This is about the
simplest possible way to go (other than omitting the final response code
altogether, which is too weak imo).
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/