Re: [ietf-smtp] SMTP Reply code 1yz Positive Preliminary reply

Hector Santos <> Fri, 06 March 2020 02:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 91D953A1178 for <>; Thu, 5 Mar 2020 18:45:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=Bpydg9M8; dkim=pass (1024-bit key) header.b=s0BjfFc9
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dodP0aXIofmx for <>; Thu, 5 Mar 2020 18:45:43 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4EF963A1177 for <>; Thu, 5 Mar 2020 18:45:43 -0800 (PST)
DKIM-Signature: v=1;; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3160; t=1583462732;; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=l9xeou1t3XOv7i+KWYQUCQXVuu4=; b=Bpydg9M8nN1b/J74iyapK0PjRFGEzbyLiK0etZxFyYANjqCeCzJ7YCIFIYKMJr PaxQoJ8TIxF/911OPPIwyC8EWhMJnq8lIwtSeBpXLdkB+JumDmQCntFYmxO2YR5q MvDXwKVR6Dk9r9UmQ1C2xnbYjYtatnHc1lZ40mm+tr+/I=
Received: by (Wildcat! SMTP Router v8.0.454.9) for; Thu, 05 Mar 2020 21:45:32 -0500
Authentication-Results:; dkim=pass header.s=tms1; dmarc=pass policy=reject (atps signer);
Received: from ([]) by (Wildcat! SMTP v8.0.454.9) with ESMTP id 2780069693.16278.7500; Thu, 05 Mar 2020 21:45:31 -0500
DKIM-Signature: v=1;; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3160; t=1583462462; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=VHr2KWk UyyhZtnBLEXpz0TE/4IhI268+iHULCFMvQmI=; b=s0BjfFc9Iqef0mUYHFOugE8 VaU0R4ei76Lb7O+jndaPuALbKJdtVhOKP0YVdyQ4ThN91oacQYSEaK1TTCjQAtiV xwJltuVzIAdPRdghxBkKwP29C5mv8Y8l25vFxa5HpKJQFmvEB9ET0RhaZQ2meZyA 9tnof1kgvhNQXBgF54vQ=
Received: by (Wildcat! SMTP Router v8.0.454.9) for; Thu, 05 Mar 2020 21:41:02 -0500
Received: from [] ([]) by (Wildcat! SMTP v8.0.454.9) with ESMTP id 2628101953.4.14820; Thu, 05 Mar 2020 21:41:01 -0500
Message-ID: <>
Date: Thu, 05 Mar 2020 21:45:33 -0500
From: Hector Santos <>
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: John C Klensin <>
References: <> <> <> <> <CFEDA025D86BD13BB8D15A56@PSB>
In-Reply-To: <CFEDA025D86BD13BB8D15A56@PSB>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [ietf-smtp] SMTP Reply code 1yz Positive Preliminary reply
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 06 Mar 2020 02:45:46 -0000

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.

On 3/5/2020 3:05 PM, John C Klensin wrote:
> 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
> <> wrote:
>> On 3/5/2020 11:28 AM, Hector Santos wrote:
>>> I used the reply group:
>>>      1yz   Positive Preliminary reply
>> I had forgotten that RFC5321 had removed this 1yz code.
>> 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.
> _______________________________________________
> ietf-smtp mailing list