Re: end of mail data response? (was: draft-hall-deferrals-00.txt)

[Claus Assmann <ietf-smtp@xxxxxxxxx>]

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".