Subject: [ietf-smtp] SMTP Reply code 500

From: Geethapriya Liyanage <[email-masked]>
Date: Wed, 04 Mar 2020 08:30:45 +0530

Hello,

In SMTP communication, normally SMTP client sends commands and SMTP
server replies to that with reply codes.  As in RFC 5321 , section
4.2.4, if the command is not recognized, code 500 should be returned.
My doubt is, if the SMTP server sends unrecognized command or code to
SMTP client , will the client also replies the same 500 code.  if not,
how the SMTP client should handle it.

Thank you,
Geethapriya

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 4 Mar 2020 10:10:00 +0100

Hi

On Wed 04/Mar/2020 04:00:45 +0100 Geethapriya Liyanage wrote:
> 
> In SMTP communication, normally SMTP client sends commands and SMTP server
> replies to that with reply codes.  As in RFC 5321 , section 4.2.4, if the
> command is not recognized, code 500 should be returned. My doubt is, if the
> SMTP server sends unrecognized command or code to SMTP client , will the client
> also replies the same 500 code.  if not, how the SMTP client should handle it.

SMTP clients can work well by just recognizing the first digit of the reply
code.  "5", in that case, more or less means that the last command failed,
client should stop the transaction if it's in the middle of one, and not retry
sending without prior human intervention.

A client that cannot recognize the first digit of a reply code is not an SMTP
client.

To precisely recognize the meaning of a reply can be useful to fine tune an
SMTP client's behavior.  Interpretation of reply codes can be done by humans
who read the log files or the bounce messages, or by machines.  The so called
extended (or enhanced) status codes, which some servers display between the
reply code and the human readable text string, can help machine interpretation.

Usually, however, the fine-tuning that can result from a correct interpretation
does not affect the immediate future of the current client/server session.  The
first digit is enough to make immediate decisions.

Best,
Ale
--

---

From: Paul Smith <[email-masked]>
Date: Wed, 4 Mar 2020 09:33:49 +0000

> how the SMTP client should handle it.

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, which all start with a three digit number where the first 
digit is 1 to 5

A buggy SMTP server could send an invalid response to the SMTP client  
(ie a response not starting with a three digit number beginning with 1 
to 5). In that case, the SMTP client should do whatever it wants to do, 
ranging from ignoring it, to dropping the connection in disgust and 
reporting an error to the user/administrator/log/whatever (I'd probably 
advocate for the latter).

-- 

Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

---

From: John C Klensin <[email-masked]>
Date: Wed, 04 Mar 2020 09:57:34 -0500

--On Wednesday, March 4, 2020 09:33 +0000 Paul Smith
<[email-masked]> wrote:

> A buggy SMTP server could send an invalid response to the SMTP
> client  (ie a response not starting with a three digit number
> beginning with 1 to 5). In that case, the SMTP client should
> do whatever it wants to do, ranging from ignoring it, to
> dropping the connection in disgust and reporting an error to
> the user/administrator/log/whatever (I'd probably advocate for
> the latter).

In the interest of cleanliness (i.e., the fact that they are
breaking the rules doesn't mean I should, even if I'm
disgusted), I would probably advocate for sending a QUIT command
prior to dropping the connection, but yes.

Certainly trying to continue a session with a server that is
badly implemented enough, or has gotten confused enough, to send
responses that don't start with a digit in the 1-5 range would
be ill-advised.

   john

---

From: Geethapriya Liyanage <[email-masked]>
Date: Thu, 05 Mar 2020 08:09:33 +0530

On Wed, 2020-03-04 at 09:57 -0500, John C Klensin wrote:
> _______________________________________________
> 
Hello,
Thank you very much for the reply. 
My doubt was, how client should handle receiving an out of rage code
(Eg 600).    Now it is clear, client should gently drop the connection
with QUIT. 
Thank you,
Geethapriya

---

From: Geethapriya Liyanage <[email-masked]>
Date: Thu, 05 Mar 2020 08:13:30 +0530

On Wed, 2020-03-04 at 10:10 +0100, Alessandro Vesely wrote:
> > server
Hi Ale,
Thank you very much for your reply.
Regards,
Geethapriya

---

From: Paul Smith <[email-masked]>
Date: Thu, 5 Mar 2020 09:17:30 +0000

> (Eg 600).    Now it is clear, client should gently drop the connection 

Yes - there is no clue what a response code of '600' would mean. I'd 
assume it failed, and give up.

But, don't take it too far. If you got a response code such as 492 
that's not listed in any SMTP documentation, I'd treat that as any other 
4xx code and treat it as a temporary failure. Strictly, it's invalid 
because the second digit is supposed to be 0-5 according to RFC 5321, 
but the first digit is sufficient for most processing, so I'd go with that.

--

---

From: Hector Santos <[email-masked]>
Date: Thu, 05 Mar 2020 11:28:56 -0500

On 3/4/2020 4:33 AM, Paul Smith 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

---

From: Hector Santos <[email-masked]>
Date: Thu, 05 Mar 2020 12:56:01 -0500

>     1yz   Positive Preliminary reply

I had forgotten that RFC5321 had removed this 1yz code.

https://tools.ietf.org/html/rfc5321#section-4.2.1

All because of the 1yz potentially used as a "preliminary" multiple 
lines "1yz-" response before the final response was issued and a 
possible legacy 821 client that looked only at the first response line 
because it didn't expect multiple lines.

I don't fully recall the discussions. While I would had accepted the 
decision for backward compatibility reasons over a decade ago, I am 
pretty sure I would of been somewhat disappointed by the removal of 
"1yz Positive preliminary reply" codes, removing even the possibility 
of a keep alive concept.  Today speeds allow for fast data processing, 
so even today, 5, certainly 10 minutes of idle timeout is outdated and 
probably should be a design taboo today.  If we don't want ESMTP 2821 
clients to use 1yz, well, maybe for RFC5321bis, we can lower the 
timeouts. I already do for after a successful transactions where there 
is additional 5 minutes wait for a new transaction.  I reduced to less 
than 1 minute to because clients from the BIG boys were 99.9% of the 
time holding up my servers and never doing a 2nd MAIL transaction.  So 
wcSMTP will drop clients who chews up available mail service time from 
the server threads.

-- 
HLS

---

From: John C Klensin <[email-masked]>
Date: Thu, 05 Mar 2020 15:05:48 -0500

Hector,

I have added a placeholder for this to the list in Appendix G
Section 7 of the working draft.  

FWKW, my personal opinion is that would be a significant change,
outside the scope contemplated for 5321bis.  YMMD and that is,
IMO, a decision that can be made only by the WG when there is
one.  However, if others agree with me, your best course forward
is to write and post an I-D explaining what you think would be
desirable and why, see if you can get it standardized and
implementation reports generated, and then propose it for
inclusion in 5321bis.  

best,
   john

--On Thursday, March 5, 2020 12:56 -0500 Hector Santos
<[email-masked]> wrote:

> All because of the 1yz potentially used as a "preliminary"
> multiple lines "1yz-" response before the final response was
> issued and a possible legacy 821 client that looked only at
> the first response line because it didn't expect multiple
> lines.
> 
> I don't fully recall the discussions. While I would had
> accepted the decision for backward compatibility reasons over
> a decade ago, I am pretty sure I would of been somewhat
> disappointed by the removal of "1yz Positive preliminary
> reply" codes, removing even the possibility of a keep alive
> concept.  Today speeds allow for fast data processing, so even
> today, 5, certainly 10 minutes of idle timeout is outdated and
> probably should be a design taboo today.  If we don't want
> ESMTP 2821 clients to use 1yz, well, maybe for RFC5321bis, we
> can lower the timeouts. I already do for after a successful
> transactions where there is additional 5 minutes wait for a
> new transaction.  I reduced to less than 1 minute to because
> clients from the BIG boys were 99.9% of the time holding up my
> servers and never doing a 2nd MAIL transaction.  So wcSMTP
> will drop clients who chews up available mail service time
> from the server threads.

---

From: Hector Santos <[email-masked]>
Date: Thu, 05 Mar 2020 21:31:11 -0500

John K,

I don't think it matters because SMTP design docs do not talk about 
client/server "Keep Alive" concepts.

We could of corrected the semantics of mixed reply codes without 
removing (without explanation) 1yz reply codes.  Modern RFC5321 
clients should not have a problem.  I think the original RFC2821 4.2.1 
last paragraph applies more correctly than the current RFC5321 
paragraph replacement which asserts persistent multi-line reply codes.

I don't know what the answer is but if RFC821 legacy compliancy is 
still important, then please allow for IP literals to remain a part of 
the basic protocol.  Engineering Consistency is all implementers can 
ask for.

-- 
HLS

On 3/5/2020 3:05 PM, John C Klensin wrote:
> ietf-smtp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-smtp
>
>

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Thu, 05 Mar 2020 21:45:33 -0500

John K, regarding the Timeouts, I was more facetious than serious 
here. However, there are situations we already talked about in the 
past. We could highlight some of them, but I believe the main one was 
the 5 mins after the transaction was completed and a RSET/MAIL can 
start a new transaction. The server has to wait 5 minutes. This is a 
wasteful timeout. By far, the majority, and for most system, 100% of 
the time, a new shorter wait time would be more scale efficiency, 
offer more load management friendliness.

This should be an adjustable per domain timeout state. The known sites 
that correctly issue multiple transactions in a single session can be 
allowed a longer period to start new transactions.

-- 
HLS

---

From: Paul Smith <[email-masked]>
Date: Fri, 6 Mar 2020 09:02:21 +0000

On 06/03/2020 02:45, Hector Santos wrote:
> start a new transaction.

I thought the main one was with delays after the the terminating '.', 
where the client is meant to wait 10 minutes for the server 
acknowledgement, but usually gives up a lot sooner than that, leading to 
duplicate messages.

--

---

From: Hector Santos <[email-masked]>
Date: Fri, 06 Mar 2020 10:22:31 -0500

On 3/6/2020 4:02 AM, Paul Smith wrote:> On 06/03/2020 02:45, Hector 
Santos wrote:
>> past. We could highlight some of them, but I believe the main one
>> was the 5 mins after the transaction was completed and a RSET/MAIL
>> can start a new transaction.
>
> acknowledgement, but usually gives up a lot sooner than that, leading
> to duplicate messages.

There are basically two:

At all the states EHLO, MAIL, RCPT and DATA, etc. Each state can spawn 
scripts, shims, hooks, mfilters, etc. Once upon a time, a concern was 
scripts, current or future, can potentially take longer than the 
allotted idle timeout period per state. So there is technically 
runtime limits & restrictions at all states.  10 mins for DATA, 5 for 
the rest.

But the one that was real and significant, are with clients who do 
complete the DATA state, get a 2yz, 4yz or 5yz response to complete a 
transaction. Then instead of issuing a QUIT, it keeps the socket 
connection open and waits for a new outbound message to be queued to 
begin a new RSET/MAIL command to start a new transaction.  This may 
help scale clients but not servers because of wasteful session 
residence time. Depending on your server load settings, the server 
threads/processes/ports could be consumed honoring the 5 minute wait. 
  However, most of the time, no new transaction begins.  So it is very 
wasteful and wcSMPT provides an operator option to shorten it.

I think since the last review of this, over a decade ago, some 
operators reading the threads got some operational, practical input on 
this, agreed it was wasteful for the server and probably shorten the 
"new transaction" wait time so that the client does not chew up server 
resources.  I recall one big domain waiting the 5 minutes but today, 
looking at the logs, I see they have cut that down to 5 seconds!  So 
if no new mail is queued on the sender side within 5 seconds, it 
issues a QUIT.

Here is one example where the client is waiting and my particular 
wcSMTP server setup disconnects after 35 seconds.  It is set in the 
registry "PostDataTimeoutSecs" DWORD 35  and the default is 0 (the 
SMTP 5 mins limit to wait for a new transaction).

**************************************************************************
Wildcat! ESMTP Server v8.0.454.9
SMTP log started at Thu, 05 Mar 2020  20:27:49
Connection Time: 20200305 20:27:49  cid: 00003F96 tid: 00001390
SSL-Enabled=YES No-Quit-Cancel=OFF Receiver-Bin=ON
Client IP: 143.228.181.88:25678 (unknown) Host IP: 76.245.57.69:25
20:27:49.763 ** WCX Process: smtpcmd-connect  ret: -1
20:27:49.763 S: 220-winserver.com Wildcat! ESMTP Server v8.0.454.9 ready
20:27:49.763 S: 220-************** WARNING:  FOR AUTHORIZED USE ONLY! 
**********************
20:27:49.763 S: 220-* THIS SYSTEM DO NOT AUTHORIZE THE USE OF ITS 
PROPRIETARY COMPUTERS    *
20:27:49.763 S: 220-* AND COMPUTER NETWORKS TO ACCEPT, TRANSMIT, OR 
DISTRIBUTE UNSOLICITED *
20:27:49.763 S: 220-* BULK E-MAIL SENT FROM THE INTERNET. THIS SYSTEM 
WILL RESTRICT ACCESS *
20:27:49.763 S: 220-* TO CAN-SPAM (US S. 877) COMPLIANT CLIENTS ONLY. 
                      *
20:27:49.763 S: 220 
************************************************************************
20:27:50.120 C: EHLO s-bulk2-p.house.gov
20:27:50.126 ** WCX Process: smtpcmd-check-ehlo  ret: -1
20:27:50.126 S: 250-winserver.com, Pleased to meet you.
20:27:50.126 S: 250-SIZE 102400000
20:27:50.126 S: 250-8BITMIME
20:27:50.126 S: 250-SUBMITTER
20:27:50.126 S: 250-ETRN
20:27:50.126 S: 250-AUTH CRAM-MD5 DIGEST-MD5 LOGIN PLAIN PLAIN-MD5 SHA-1
20:27:50.126 S: 250-AUTH=LOGIN
20:27:50.126 S: 250-HELP
20:27:50.126 S: 250 STARTTLS
20:27:50.535 C: STARTTLS
20:27:50.536 S: 220 Ready to start TLS
20:27:50.536 ** Begin SSL negotiation
20:27:50.807 ** SSL negotiation successful
20:27:50.863 C: EHLO s-bulk2-p.house.gov
20:27:50.869 ** WCX Process: smtpcmd-check-ehlo  ret: -1
20:27:50.869 S: 250-winserver.com, Pleased to meet you.
20:27:50.869 S: 250-SIZE 102400000
20:27:50.869 S: 250-8BITMIME
20:27:50.869 S: 250-SUBMITTER
20:27:50.869 S: 250-ETRN
20:27:50.869 S: 250-AUTH CRAM-MD5 DIGEST-MD5 LOGIN PLAIN PLAIN-MD5 SHA-1
20:27:50.869 S: 250-AUTH=LOGIN
20:27:50.869 S: 250 HELP
20:27:51.022 C: MAIL From:<[email-masked]> SIZE=30462
20:27:51.023 S: 250 <[email-masked]>... Sender validation 
pending. Continue.
20:27:51.081 C: RCPT To:<[email-masked]>
20:27:56.555 ** WCX Process: wcsap ret: -1 (5473 msecs)
20:27:56.555 S: 250 <[email-masked]>... Recipient ok
20:27:57.502 C: DATA
20:27:57.502 S: 354 Start mail input; end with <CRLF>.<CRLF>
20:27:59.441 ** end of data received. (bytes: 31708) (15.9 K/s)
20:28:00.539 ** WCX Process: SmtpFilterHookLoader  ret: 1 (1098 msecs)
20:28:00.539 ** Authentication-Results: dkim.winserver.com;
20:28:00.539 **      dkim=pass header.d=mail.house.gov 
header.s=November2012-msg-mhg header.i=mail.house.gov;
20:28:00.539 **      dkim=pass header.d=mail.house.gov 
header.s=November2012-msg-mhg header.i=mail.house.gov;
20:28:00.540 ** message copied to router prespool
20:28:00.540 ** Router signaled to begin handling new messages
20:28:00.540 S: 250 Message accepted for delivery. (bytes: 31708)
20:28:37.045 S: 421 Idle Timeout - Server closing transmission channel.
20:28:37.045 ** Completed. Elapsed Time: 47300 msecs

-- 
HLS

---

From: John C Klensin <[email-masked]>
Date: Fri, 06 Mar 2020 11:24:22 -0500

A placeholder for whether we need to review some of all of the
timeouts has been added to the working copy of 5321bis-03.  As
with all of the other Appendix G entries for which there is not
already text in the I-D (text that was inserted either as an
obvious fix or after extended discussion on this list), I am
taking no position about what, if anything, should be done: I'm
just keeping a list.  One implication of that is that, if anyone
is going to suggest something that they don't think belongs on
the list... well, either say that or don't suggest it. 

Each one of those I add is more work for a possible WG to do
although I continue to hope and believe that such a WG could
quickly go through the list and divide things up into:

	* Handle in an Applicability Statement
	
	* Hold for future work to supplement SMTP (or other
	email protocols)
	
	* Requires work on 5321bis.

For the last category, I also continue to hope that, at least
for the subset of issues for which we do not already have
proposed text, there will be no, or almost no, entries.

Question for this list: I have not planned on posting -03 until
we have a WG.  It differs from the current draft on the servers
(-02) only in that Appendix G has been expanded a bit, most
recently with the "1yz" and timeout topics.  If anyone thinks
having it posted before IETF 107 would be helpful, e.g., to
facilitate any informal conversations that might occur then,
please say so and say so soon.  

best,
   john

--On Friday, March 6, 2020 10:22 -0500 Hector Santos
<hsantos=[email-masked]> wrote:

> On 3/6/2020 4:02 AM, Paul Smith wrote:> On 06/03/2020 02:45,
> Hector Santos wrote:
>>> John K, regarding the Timeouts, I was more facetious than
>>> serious here. However, there are situations we already
>>> talked about in the past. We could highlight some of them,
>>> but I believe the main one was the 5 mins after the
>>> transaction was completed and a RSET/MAIL can start a new
>>> transaction.
>> 
>> I thought the main one was with delays after the the
>> terminating '.', where the client is meant to wait 10 minutes
>> for the server acknowledgement, but usually gives up a lot
>> sooner than that, leading to duplicate messages.
> 
> There are basically two:
> 
> At all the states EHLO, MAIL, RCPT and DATA, etc. Each state
> can spawn scripts, shims, hooks, mfilters, etc. Once upon a
> time, a concern was scripts, current or future, can
> potentially take longer than the allotted idle timeout period
> per state. So there is technically runtime limits &
> restrictions at all states.  10 mins for DATA, 5 for the rest.
> 
> But the one that was real and significant, are with clients
> who do complete the DATA state, get a 2yz, 4yz or 5yz response
> to complete a transaction. Then instead of issuing a QUIT, it
> keeps the socket connection open and waits for a new outbound
> message to be queued to begin a new RSET/MAIL command to start
> a new transaction.  This may help scale clients but not
> servers because of wasteful session residence time. Depending
> on your server load settings, the server
> threads/processes/ports could be consumed honoring the 5
> minute wait.   However, most of the time, no new transaction
> begins.  So it is very wasteful and wcSMPT provides an
> operator option to shorten it.
> 
> operators reading the threads got some operational, practical
> input on this, agreed it was wasteful for the server and
> probably shorten the "new transaction" wait time so that the
> client does not chew up server resources.  I recall one big
> domain waiting the 5 minutes but today, looking at the logs, I
> see they have cut that down to 5 seconds!  So if no new mail
> is queued on the sender side within 5 seconds, it issues a
> QUIT.
> 
> Here is one example where the client is waiting and my
> particular wcSMTP server setup disconnects after 35 seconds.
> It is set in the registry "PostDataTimeoutSecs" DWORD 35  and
> the default is 0 (the SMTP 5 mins limit to wait for a new
> transaction).
> 
> 20:27:49.763 S: 220-************** WARNING:  FOR AUTHORIZED
> USE ONLY! **********************
> 20:27:49.763 S: 220-* THIS SYSTEM DO NOT AUTHORIZE THE USE OF
> ITS PROPRIETARY COMPUTERS    *
> 20:27:49.763 S: 220-* AND COMPUTER NETWORKS TO ACCEPT,
> TRANSMIT, OR DISTRIBUTE UNSOLICITED *
> 20:27:49.763 S: 220-* BULK E-MAIL SENT FROM THE INTERNET. THIS
> SYSTEM WILL RESTRICT ACCESS *
> 20:27:49.763 S: 220-* TO CAN-SPAM (US S. 877) COMPLIANT
> CLIENTS ONLY.                       *
> 20:27:49.763 S: 220
> 20:27:51.023 S: 250 <[email-masked]>... Sender
> validation pending. Continue.

---

From: Hector Santos <[email-masked]>
Date: Sun, 08 Mar 2020 12:00:00 -0400

Hi John,

> the list... well, either say that or don't suggest it.

You have much in Appendix G. All appears to be legit issue to review. 
  Thanks for the addition of my recent comments. The only thing that 
stood out and can't get it out of my mind, is the change to the 
Acknowledgments. I personally don't feel good about it. But as part of 
my stress reduction therapy, I just deleted a paragraph describing my 
feeling about that change. I will just say, it has served as a "small 
badge" of honor to be recognized as a long time participant and 
implementor of SMTP for a number of decades.

> please say so and say so soon.

+1 I think I-D -03 should be submitted before IETF 107 for the reasons 
you stated.

-- 
HLS

---

From: John C Klensin <[email-masked]>
Date: Sun, 08 Mar 2020 14:12:37 -0400

(top post)

Hector,

Ok.   Unless someone has a convincing reason wh7 not and
expresses it before I get around to it, -03 will be posted
before the deadline.  I-Ds are cheap and I don't need to do a
lot of work to get from the current XML to a posted version.

The note at the end of the Acknowledgments section started out
as strictly a comment about errata.  I've changed the date,
rather arbitrarily, to 1 July.   I am keeping a list although it
is currently scattered through the document and my internal
comments.  I actually have a reason for not including a specific
list at this time:  Suppose someone suggested modifying 5321bis
to require the use of DNSSEC records and validation before an MX
record could be believed.  Because I'm trying to not make
judgments, I would include that request in Appendix G even
though I can predict with great confidence that it would swiftly
be taken off the list for 5321bis when a WG reviews (or triages)
it.  I would like to discuss with the WG whether the person and
others who made similar suggestions (but were otherwise not
influential in contributing  to the document) should be included
in the acknowledgments.  If the conclusion after that WG
discussion is "no", I don't want to remove names between
versions of the I-D.  So, until there is a WG, no explicit
acknowledgments.  One that the WG does the triage and has that
discussion, you and others will be picked back up and, if the WG
so concludes, I'll copy the whole lists of those who contributed
to 2821 and 5321 into this document as well.

best,
   john

--On Sunday, 08 March, 2020 12:00 -0400 Hector Santos
<[email-masked]> wrote:

>> with all of the other Appendix G entries for which there is
>> not already text in the I-D (text that was inserted either as
>> an obvious fix or after extended discussion on this list), I
>> am taking no position about what, if anything, should be
>> done: I'm just keeping a list.  One implication of that is
>> that, if anyone is going to suggest something that they don't
>> think belongs on the list... well, either say that or don't
>> suggest it.
> 
> You have much in Appendix G. All appears to be legit issue to
> review.   Thanks for the addition of my recent comments. The
> only thing that stood out and can't get it out of my mind, is
> the change to the Acknowledgments. I personally don't feel
> good about it. But as part of my stress reduction therapy, I
> just deleted a paragraph describing my feeling about that
> change. I will just say, it has served as a "small badge" of
> honor to be recognized as a long time participant and
>> Question for this list: I have not planned on posting -03
>> until we have a WG.  It differs from the current draft on the
>> servers (-02) only in that Appendix G has been expanded a
>> bit, most recently with the "1yz" and timeout topics.  If
>> anyone thinks having it posted before IETF 107 would be
>> helpful, e.g., to facilitate any informal conversations that
>> might occur then, please say so and say so soon.
> 
> +1 I think I-D -03 should be submitted before IETF 107 for the
> reasons you stated.