Re: [ietf-smtp] SMTP Reply code 500

[Hector Santos <[e-mail]>]

On 3/4/2020 4:33 AM, Paul Smith wrote:
> On 04/03/2020 03:00, Geethapriya Liyanage wrote:
>
> An SMTP server will never send a command to the SMTP client. That's
> just not SMTP. In SMTP, the client sends commands, the server sends
> responses,

Hi Paul,

Rarely will a server issue an unsolicited response and the only place 
done, officially, is at the initial connection welcome (220) response 
line.  I suppose one can say the "connection" is a "open or knock on 
door" command.

But additionally, at least in Wildcat! SMTP, is for idle timeouts, 
Example:

12:41:04 S: 421 Idle Timeout - Server closing transmission channel.
12:41:04 ** Completed. Elapsed Time: 30043 msecs

So in this case, the client was idle for 5 mins.  This is logged on 
the server side. The client may log it if it is listening.  Having it 
in the session trace log helps for support diagnostics.

"Keep Alive"

On a related now, once upon a time, in dealing with the concept of 
timeouts, the question I once had was whether clients are listening 
for responses so we can use this as a  "Heart Beat" or "Keep Alive" 
concept to avoid clients prematurely disconnecting if the server was 
busy processing a command during DATA scripts.  I tested 2 MUAs who 
would disconnect if the server did not respond in time but they will 
"keep alive" if the server was issuing "xyz-" responses (with the 
dash) every X secs.  Example:

C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>

So the client sends the payload at this moment and before the server 
responds, I explored a script that would issue the following every X 
seconds:

S: XYZ-Processing DATA. Keep Alive #n

So the question was, what would a heart beat-like "XYZ" reply code 
value be? The main logical problem is that you don't know if the final 
response is 2yz, 4yz or 5yz.   So the question was can you mix reply 
codes groups when  using continuation lines? For example, would this work?

C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
S: 150-Processing DATA. Keep Alive #1
S: 150-Processing DATA. Keep Alive #2
S: 150-Processing DATA. Keep Alive #3
S: 150-Processing DATA. Keep Alive #.
S: 150-Processing DATA. Keep Alive #.
S: 150-Processing DATA. Keep Alive #N
S: 250 Message OK

I used the reply group:

    1yz   Positive Preliminary reply

This was explored during RFC2821Bis when we began to consider dynamic 
DATA processing for DKIM, ADSP and SenderID ideas among other things 
people were doing at DATA like scanning for keywords and phases, AVS 
stuff, Challenge/Response ideas and so on.   This was all relatively 
new in the SMTP workd where more packages were now allowing for 
dynamic online processing at each state. What happens if a script was 
taking too long?  Do we have an Keep Alive concept?

You may recall, I did bring it up during 2821bis and it was decided 
that the reply code numbers must match in multiple lines after it was 
found that at least one legacy client was using the first line as the 
reply code value regardless of the additional lines sent.  So the 
following last paragraph in section 4.2.1 for 2821bis (RFC5321) was 
removed and replaced:

    4.2.1.  Reply Code Severities and Theory

    ...

Removed:

    In many cases the SMTP client then simply needs to search for a line
    beginning with the reply code followed by <SP> or <CRLF> and ignore
    all preceding lines.  In a few cases, there is important data for the
    client in the reply "text".  The client will be able to identify
    these cases from the current context.

Replaced with:

    In a multiline reply, the reply code on each of the lines MUST be the
    same.  It is reasonable for the client to rely on this, so it can
    make processing decisions based on the code in any line, assuming
    that all others will be the same.  In a few cases, there is important
    data for the client in the reply "text".  The client will be able to
    identify these cases from the current context.


Of course, it was just exploration and nothing to depend on because as 
you mentioned, its not a CLIENT/SERVER model in the true sense - 
Clients issues commands, Servers sends responses.  SMTP was not 
designed for a Keep Alive concept. What it did for wcSMTP was to make 
sure the increasing usage of dynamic SMTP scripts running back to back 
during DATA would not take a long time. So the script manager had to 
be given a Maximum Global Time limit.

#-----------------------------------------------------
# v2.0
#
# Maximum Scanning Time (secs) allowed. This
# time is to help prevent SMTP timeouts in the DATA
# state.  10 mins is official wait time for DATA
# termination timeout. However, 5 mins is pretty
# common (unfortunately) for many SMTP clients. The
# default value is a little less than 5 minutes
# (4 mins, 30 secs).  What this means is that
# all the WCX filters in the [hooks] sections MUST
# complete within this time.  To disable, set it
# too zero, however, keep in mind, SMTP clients will
# timeout and disconnect if the filters are taking
# too long. This can cause dupes and unnecessary
# retries by the client.
#-----------------------------------------------------

;GlobalTimeout = 270          # use this for "5 mins timeouts"  (default)
;GlobalTimeout = 570          # use this for "10 mins timeouts"
;GlobalTimeout = 60           # TESTING ONLY

Note, any script may still issue a keep alive "xyx-" line on its own 
if it believe it may too long. I don't have any stock scripts that do 
this. As mentioned, it does keep a client alive (the ones I tested 
over a decade ago).

-- 
HLS