Re: rfc2821bis-01 Issue 18: Usability of 1yz replies
John C Klensin <john+smtp@jck.com> Tue, 10 April 2007 20:47 UTC
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3AKlYpk091474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Apr 2007 13:47:34 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l3AKlYvh091473; Tue, 10 Apr 2007 13:47:34 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l3AKl6M9091433 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <ietf-smtp@imc.org>; Tue, 10 Apr 2007 13:47:31 -0700 (MST) (envelope-from john+smtp@jck.com)
Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1HbNEv-000OZw-Nm; Tue, 10 Apr 2007 16:46:58 -0400
Date: Tue, 10 Apr 2007 16:46:55 -0400
From: John C Klensin <john+smtp@jck.com>
To: Hector Santos <hsantos@santronics.com>, Douglas Otis <dotis@mail-abuse.org>
cc: Tony Finch <dot@dotat.at>, ietf-smtp@imc.org
Subject: Re: rfc2821bis-01 Issue 18: Usability of 1yz replies
Message-ID: <280DF2C85C7FB2F42AB740C5@p3.JCK.COM>
In-Reply-To: <461BE431.2040201@santronics.com>
References: <5804F534F53FA45376100D12@p3.JCK.COM> <Pine.LNX.4.64.0704101640390.4230@hermes-1.csi.cam.ac.uk> <468ACDBF-6594-44DC-A6B5-9D1BAD813F1A@mail-abuse.org> <461BE431.2040201@santronics.com>
X-Mailer: Mulberry/4.0.7 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-ietf-smtp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Unsubscribe: <mailto:ietf-smtp-request@imc.org?body=unsubscribe>
--On Tuesday, 10 April, 2007 15:23 -0400 Hector Santos <hsantos@santronics.com> wrote: > First, all it says in so many words is that there no > expectation for it because unextended clients do not now how > use it. It specifically says: > > Note: unextended SMTP does not have any commands that > allow this type of reply, and so does not have continue > or abort commands. That is clearly wrong. By the time 2821 came around, it probably should have been modified to say "...a continue command to correspond to it" might have been thinking in terms of actual CONTinue and ABORt commands, the latter presumably with different semantics than RSET (although, right now, I can't imagine what they might be). I will make that fix unless the group agrees on some broader change (or concludes that the "Note" should be dropped entirely). Sorry for not understanding what you were referring to earlier. > It is clearly vague and incorrect because "unextended" clients > do have the abort commands - RSET and/or QUIT. If it is > clear that this will break unextended clients, then it should > be noted. The text, at least as I read it, tells clients that they should be prepared to see a 1yz reply and to then either send CONTinue (which they can't send because, absent extensions, it doesn't exist) or RSET. If, in practice, it can only be followed by RSET (or QUIT or anything else that implies RSET), a server that sends it to a client without benefit of an extension is generating a silly state that would better be avoided by sending a 4yz or 5yz code. One might well extend SMTP to use 1yz codes, but in a way different from what you are trying to accomplish by sending periodic "150-wait" lines. That would involve the following sort of dialogue: S: 150 I'm going to have to screw around for a while, are you willing to stand by? Client then responds with one of.. C: RSET (i.e., give up completely) or C: ABOR (i.e., don't do whatever you intended to do, but continue processing, sending me an NDN later if needed) or C: CONT nnnnn (where nnnn is a number of seconds that the server may go on with processing before either sending out another 150 code for confirmation or sending a final (for the mail session)reply) Of course, this would require an SMTP extension. See below for another version of this theme. Note that FTP (see RFC765), on which SMTP was modeled, does have a 1yz reply, but its semantics are exactly what you are trying to accomplish with the 150-please wait 150-please wait 550 forget it sequence. In FTP-land, that would be expressed as 150 content received, please stand by 550 nope i.e., without a continuation arrangement and with the expectation that the client should wait until another, final, code is sent. Probably, if this were carefully engineered, the risks of duplicates that motivated RFC 1047 could be avoided: the client would know that, if it got the 150 code, the server had successfully received the content and that, if it didn't stay connected long enough to get a real reply and then send a QUIT, it might well trigger some DSN behavior. But that has never been done with SMTP and, of course, FTP has an asynchronous data channel. FTP also supports ABORt, RESTart, and STATus commands that can take advantage of the asynchrony. And, for whatever it is worth, the text that starts "The sender-SMTP should send..." and ends "...so does not have the continue or abort commands." comes verbatim out of RFC 821. It has been with us for a very long time and this is, at least in my memory, the first time someone has identified it as pathologically confusing. That doesn't mean you are wrong of course, but it is interesting. > Second, there is no restriction in using it as part of a > continuation line. Example: > > C: DATA > S: 352 Begin sending your data > [client uploads data] > S: 150-DKIM signature found! > S: 150-Please wait while we process your DKIM message! > S: 150-Waiting for trust server to respond... > S: 150-Still waiting for trust server to respond... > C: 550-Sorry, The DKIM POLICY has failed this transaction > C: 550 Please see http://trust-r-us.com/msgid=123213123 > > Who knows? Is this not possible? It is out of the whelm of > real possibility? No, it is is clearly not impossible. However, it raises two issues in addition to the one about the codes all being the same which, IMO (and in the text of 2821), arises from one of them. One is that it is a perfectly conforming and rational implementation of SMTP as now defined for the client to do nothing but buffer a continued set of replies until the last one arrives. That would result in the "please wait" part of those 150 reply lines having no client effect and, in particular, no effect on any timeouts the client imposes on a continued set of reply codes. Second, if the client does time out, one runs directly afoul of the message-duplication principles of RFC 1047 (affirmed by 1123 and 2821). If one were doing an extension to support this, it would be, IMO, sensible to move more toward the FTP model or the somewhat related model discussed above, i.e., one in which the server sent (a non-continuing) 1yz reply with the semantics of "please stand by while I do some other processing" followed by a real reply (which might be 2yz, 4yz, or 5yz). I might even use the 1yz reply to give the client a hint about how long I expected my server-side processing to take, i.e., how long it should be expected to wait. > Maybe someone will invent a OPES-DKIM shim that needs to call > up some trust repository that is taking its sweet time > returning with a response or whatever the circumstances, I > think 2821bis should be clear either way. Either it is going > to stop such possibilities or it will allow for become a > helper in future technology. And I think that what people are saying to you, from several different perspectives, is that such an approach might be perfectly reasonable, but should be provided through an explicit SMTP extension that provides a specific 1yz code, specifies its semantics and intended client and server behavior, and explicitly modifies the normal SMTP timeout behavior. Sequences such as the one you propose above are simply not going to work (in terms of client behavior) consistently enough in practice to be appropriate solutions. > Please, lets not get into a discussion of where a DKIM or any > other DATA processing should be postpone to a POST-ACCEPT > design. Thats a not starter for our system and hopefully > others in this new era of minimizing accept/bounce potential > issues. For other reasons, I essentially substituted "some random protocol that might need to process or validate the content" for "DKIM" in your examples and discussion above. Certainly one can imagine several families of such protocols. The real question is whether, with SMTP as now defined (including the application of the mandate that formally originated with RFC 1047 to minimize time between EOD (CRLF.CRLF) and a reply indicating message receipt, one can define something in which extended and potentially time-consuming processing at that point makes sense. john
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Peter J. Holzer
- Re: RFC2821bis-02 Issue 28: Client behavior on un… Peter J. Holzer
- General-Address-Literal (was: rfc2821bis-02 Issue… Frank Ellermann
- Re: rfc2821bis-02 Issue 24 John C Klensin
- Re: rfc2821bis-02 Issue 24 Hector Santos
- Re: rfc2821bis-02 Issue 24 (was: Re: rfc2821bis-0… John C Klensin
- Re: RFC2821bis-02 Issue 28: Client behavior on un… ned+ietf-smtp
- Re: RFC2821bis-02 Issue 28: Client behavior on un… Hector Santos
- Re: New issue (was Re: rfc2821bis-01 Issue 18: Us… John C Klensin
- Re: RFC2821bis-02 Issue 28: Client behavior on un… Arnt Gulbrandsen
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Frank Ellermann
- Re: RFC2821bis-02 Issue 28: Client behavior on un… Frank Ellermann
- Re: RFC2821bis-02 Issue 28: Client behavior on un… Tony Hansen
- Re: New issue (was Re: rfc2821bis-01 Issue 18: Us… Robert A. Rosenberg
- Re: New issue (was Re: rfc2821bis-01 Issue 18: Us… ned+ietf-smtp
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Philip Guenther
- RFC2821bis-02 Issue 28: Client behavior on unreco… John C Klensin
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… David F. Skoll
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… John C Klensin
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Tony Hansen
- Re: New issue (was Re: rfc2821bis-01 Issue 18: Us… John C Klensin
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Hector Santos
- Re: New issue (was Re: rfc2821bis-01 Issue 18: Us… Hector Santos
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Claus Assmann
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… David F. Skoll
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Hector Santos
- Re: New issue (was Re: rfc2821bis-01 Issue 18: Us… Philip Guenther
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Hector Santos
- Re: New issue (was Re: rfc2821bis-01 Issue 18: Us… David F. Skoll
- Re: New issue (was Re: rfc2821bis-01 Issue 18: Us… Hector Santos
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Tony Hansen
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Tony Hansen
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Hector Santos
- Re: New issue (was Re: rfc2821bis-01 Issue 18: Us… Hector Santos
- Re: New issue (was Re: rfc2821bis-01 Issue 18: Us… Jeff Macdonald
- Re: New issue (was Re: rfc2821bis-01 Issue 18: Us… David F. Skoll
- Re: New issue (was Re: rfc2821bis-01 Issue 18: Us… John C Klensin
- Re: New issue (was Re: rfc2821bis-01 Issue 18: Us… Arnt Gulbrandsen
- Re: New issue (was Re: rfc2821bis-01 Issue 18: Us… ned+ietf-smtp
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… ned+ietf-smtp
- New issue (was Re: rfc2821bis-01 Issue 18: Usabil… David F. Skoll
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Hector Santos
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… John C Klensin
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… David F. Skoll
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… John C Klensin
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Tony Hansen
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Hector Santos
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… David F. Skoll
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Frank Ellermann
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Hector Santos
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… David F. Skoll
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Peter J. Holzer
- Re: Registration rules for extensions Frank Ellermann
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Hector Santos
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… David F. Skoll
- Nitpicking typos (was: Re: rfc2821bis-01 Issue 18… John C Klensin
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Hector Santos
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Frank Ellermann
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Hector Santos
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Hector Santos
- Registration rules for extensions (was: Re: rfc28… John C Klensin
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Peter J. Holzer
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… John C Klensin
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Hector Santos
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Frank Ellermann
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Kari Hurtta
- Re: rfc2821bis-01 Issue 17: multiline reply codes John C Klensin
- Re: Window of opportunity Tony Hansen
- Window of opportunity (was: rfc2821bis-01 Issue 1… Frank Ellermann
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Tony Hansen
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… David F. Skoll
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Hector Santos
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… David F. Skoll
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Hector Santos
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Peter J. Holzer
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Arnt Gulbrandsen
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… John C Klensin
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… David F. Skoll
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Hector Santos
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… David F. Skoll
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Claus Assmann
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Arnt Gulbrandsen
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Hector Santos
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Hector Santos
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… John C Klensin
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… David F. Skoll
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Hector Santos
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… John C Klensin
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… David F. Skoll
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Hector Santos
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Tony Finch
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… David F. Skoll
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Hector Santos
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… David F. Skoll
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Hector Santos
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Hector Santos
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Frank Ellermann
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… John C Klensin
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Douglas Otis
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… John C Klensin
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… william(at)elan.net
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… David F. Skoll
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Hector Santos
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Douglas Otis
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Hector Santos
- Re: rfc2821bis-01 Issue 18: Usability of 1yz repl… Tony Finch
- rfc2821bis-01 Issue 18: Usability of 1yz replies John C Klensin