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

[Hector Santos <[e-mail]>]

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