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
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp