On Sun, Feb 04, 2007, Peter J. Holzer wrote:
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.
That's an obvious violation of RFC (2)821. The server has to commit
the message before it sends the reply.
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.
What does "committing" mean for you here? What exactly do you want
to commit? Do you want to do like this:
- is there any RCPT that is accepted?
. yes: commit data
- for each RCPT:
is it accepted?
- yes: commit RCPT
send reply
. no: trivial case
That's not very efficient as a "commit" (e.g., fsync()) is the most
expensive I/O operations on conventional hardware.
I've implemented "DRR" in my SMTP server, and I noticed that the
LMTP model, i.e., no explicit "end of mail data" reply, introduces
some problems:
- it requires special code to deal with the fact that a command
doesn't have a reply.
- the error handling in case of a lost connection is more complicated.
Hence I'm strongly in favor of an "extended" LMTP model where
additionally to the individual RCPT responses a separate "end of
mail data" response is used. This matches the existing model better
(no special case code, no "per RCPT commits"), and makes the error
handling simpler: the server accepts the responsibility for the
mail only if there is positive "end of mail data" reply (just as
it does without this extension), there is no "partial success".