On Sun, Feb 04, 2007, Eric A. Hall wrote:
This is basically the DEFERRALS model with two changes. One is that you've
dropped the 352 response to RCPT, which I'm not married to. The other
Initially I had that listed as an optimization, but then dropped
it from the mail as I didn't want to complicate matters.
change is that you've dropped the 353 response code to signal the start of
deferred RCPT responses, which is a bit of a problem.
See the discussion on reliability timers earlier--a start code is going to
be important. Also see the last post by me in re global filters--this is
Your draft requires a first response after 1 minute and then each
RCPT command within 10 minutes. I don't see why that first response
is important wrt timeouts, but I'll look at that discussion again.
Anyway, we could write an additional RFC that defines a generic
"stay tuned" reply code[*]: if the server isn't done with the command
yet but the timeout is almost reached, it can send a "stay tuned"
reply code telling the client to reset the timeout (obviously there
must be some limit to the overall timeout, e.g., 10 times the
default). The implementation of that RFC could be made a requirement
for "DRR".
the right place to issue such a response. Frank's is also correct that
there is some efficiency and reliability if we can avoid enumerating long
lists of response codes. For all those reasons I'd like to ask you to try
using it and see if it's not too hard.
I implemented your draft first (didn't I write that before?), and
it required significant code changes because of all the "optimizations".
Then I tried the LMTP model and the only (but significant) problem
I ran into is the missing ("final") reply to the data which makes
error handling more complicated than your proposal. That's why I
suggested a "compromise" to get the best (IMHO) from both models.
I understand that your proposal is the most complete and offers all
kind of optimizations. As a consequence of that it also the most
complex and hence most complicated to implement. As I wrote before:
that may prevent other MTA authors from implementing it and it may
introduce implementation errors. Remember: it is _S_imple Mail
Transport Protocol :-)
As I wrote before: maybe others can look at the implementation
effort in other MTAs for the various proposals and give some statement
wrt complexity and error handling?
Footnote:[*]: that's what we implemented in milter to deal with
this kind of timeouts during processing of the mail body.