--On Tuesday, 10 April, 2007 15:23 -0400 Hector Santos
<hsantos(_at_)santronics(_dot_)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