On 2007-02-04 09:06:07 -0800, Claus Assmann wrote: > On Sun, Feb 04, 2007, Peter J. Holzer wrote: > > 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? Saving the information that the message should be delivered to the recipient and telling the client that responsibility for further delivery has been accepted. The deferrals draft only commits once for all recipients: Either all or none get the message. Consequently if the client doesn't receive the final reply, it has to assume that none of the recipients will receive it and resend it to all of them. In LMTP, the server commits for every recipient. If the client receives only replies for some of the recipients, it has to assume that those for which it got replies will be delivered and resend only to those for which it got no replies. > 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. Yes. It's more expensive but more robust than Eric's draft, I think. (Also, I'm not sure how expensive fsync() really is if there are lots of fsync() requests - AFAIK order doesn't have to be maintained, so the OS can optimize quite a lot there - but does it?). > 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. Why doesn't it have a reply? It has one reply for every remaining recipient, and since there must be at least one (otherwise DATA returns a 503 reply) there is at least one 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. "end of mail data" sounds to me like it is sent before the individual rcpt replies. But from your reasoning I think you want it after the individual replies, like the "final response code" in Eric's draft. Right? hp -- _ | Peter J. Holzer | I know I'd be respectful of a pirate |_|_) | Sysadmin WSR | with an emu on his shoulder. | | | hjp@xxxxxx | __/ | http://www.hjp.at/ | -- Sam in "Freefall"
Attachment:
signature.asc
Description: Digital signature