On 2007-02-03 09:20:18 -0500, Eric A. Hall wrote:
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.
Not when pipelining is enabled. The client must wait for the 3xx reply
to DATA, but then it can send the message content, the final "." and
QUIT all in one fell swoop.
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.
I don't think this assumption is safe. Also if you commit the
transaction only after sending the final reply code, your server could
crash after sending the reply and before the commit. In this case the
message will be lost.
The more I think about it, the more I'm convinced that committing on a
per-recipient basis (as LMTP does) is more robust. I do agree that it is
more difficult to implement on the server side, though.
hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hjp(_at_)hjp(_dot_)at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
signature.asc
Description: Digital signature