[Top] [All Lists]

Re: rfc2821bis-01 Issue 18: Usability of 1yz replies

2007-04-11 05:35:26

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

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 @>
   S: 250 Ok, Return Path Verification Pending...
   C: RCPT TO: <someuser @>

      [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.


<Prev in Thread] Current Thread [Next in Thread>