John C Klensin wrote:
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.
No problem john. I vote towards dropping the note, or clarify it with
something to akin to this:
Note: This specification does not have any current commands
that defines usage for 150 non-continuation
COMPLETION reply-code. As such, there is no guidance as
to what command a client can issue next or what state
the client should move into in response to a server 150
reply-code. Such definitions are out of scope and primarily
intended for Extended SMTP definitions.
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
That's correct. All this had stem from FTP work where a keep alive
concept was necessary to resolve FTP CLIENT 30 second socket timeouts
issues. That engineering was extended to SMTP when it was becoming
apparent with new dynamic backend operations was a high consideration,
AVS, OPES, DKIM, etc.
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?
Side note: Someone pointed out that typo above. Thought it should be
mentioned: The last two lines should be server S: lines:
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.
I am not sure I agree because buffered or not, the client must look for
each EOL. But more important, the timeouts are typically programmed into
the socket timeout as well. It depends on how the socket I/O is done.
It can be a telnet like session with interactive character I/O or its
buffered until a timeout or a EOL is sensed or both.
I think the more robust design is to MAKE sure each line begins with a
numeric xyz code. If there is garbage (non-numeric), how a client reacts
is undefined, but most likely abort. In C, it is easy since atoi() is
delimiter with a non-numeric character or null.
IMO, I don't think it will be good engineering on the client part if it
does not reset a SMTP timeout when reading each line buffered or not.
As long as each line begins with a XYZ- number, its all good
Now, is there a limit?
There might be. We have a 100 line limit at the welcome because we found
a few zombies that spew out non-stop "220-" lines.
(Thats another note that might be considered - is there a limit in the
total lines for a multi-line response?)
Second, if the client does time out, one runs directly afoul of
the message-duplication principles of RFC 1047 (affirmed by 1123
and 2821).
Right, thus why the server needs the ability to keep the client live in
such scenarios.
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.
Agree. I agree that the extension would be useful, but I also think
2821bis clarification would have a current transparent benefit as well
and also prepare such new extensions.
In in mind that DATA is the best example here, but in general, it also
applies to all states with their own 5 minute recommended minimal timeout.
C: MAIL FROM:<foobar @ whereever.com>
S: 250 Ok, Return Path Verification Pending...
C: RCPT TO: <someuser @ host.com>
[for some reason, backend is taking long time, 4 mins uses up,
so it sends 150- with the idea of keeping the client alive]
S: 150-Please wait, still trying to verify...
S: 250 Its all good, continue.
Is that desirable? Of course not.
Is it possible? Yes
Should the backend put a 5 minute cap on the backend thread residence
time? That would be a design goal for maximum reliability.
In practice, we have a maximum time local policy 5 minutes default
maximum time and I can't recall a situation off hand where its taken
longer than 1 minute if that.
--
HLS