Subject: [Emailcore] Ticket #16 - Proposed Text for Applicability Statement

From: Todd Herr <[email-masked]>
Date: Wed, 19 Jan 2022 08:41:58 -0500

Greetings.

Alexey mentioned in a separate message that I would be posting proposed
text for the subject ticket. This is that posting.

The ticket is ticket number 16 -
https://trac.ietf.org/trac/emailcore/ticket/16 - and the topic is the
timeout specifications in RFC 5321, specifically whether or not they might
be too generous.

Discussion at IETF 110 (https://codimd.ietf.org/notes-ietf-110-emailcore)
seemed to land on "Leave 5321 alone, but maybe add something to the
Applicability Statement"

Here is the initial proposed text for something to add to the Applicability
Statement.

===================== cut here ========================

7. Timeout Specifications

The current SMTP specification (5321bis), as well as the two before it
(RFC5321 and RFC2821) contain recommendations for minimum timeout values
for various operations. Given the age of RFC 2821 (published in April 2001)
and advances in networking and computing technology since then, it might
seem that these timeout values are far too generous. However, those same
advances have been relied on by MTA implementers to add more features and
functionality to SMTP transactions.

The recommended minimum timeouts are specified as SHOULD, not MUST, and so
implementers may choose to use shorter timeouts if operational needs or
experience indicate that to be appropriate.
===================== cut here ========================

Please discuss...

-- 

*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* [email-masked]
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

---

From: Hector Santos <[email-masked]>
Date: Wed, 19 Jan 2022 11:02:14 -0500

On 1/19/2022 8:41 AM, Todd Herr wrote:
> The current SMTP specification (5321bis), as well as the two before 
> it (RFC5321 and RFC2821) contain recommendations for minimum timeout 
> values for various operations. Given the age of RFC 2821 (published 
> in April 2001) and advances in networking and computing technology 
> since then, it might seem that these timeout values are far too 
> generous. However, those same advances have been relied on by MTA 
> implementers to add more features and functionality to SMTP 
> transactions.
>
> The recommended minimum timeouts are specified as SHOULD, not MUST, 
> and so implementers may choose to use shorter timeouts if 
> operational needs or experience indicate that to be appropriate.
>

+1. I believe this is closer to modern receiver behavior (SHOULD use, 
may reduce).  With senders, I don't believe we have reduced the 
timeouts - only on the server side are the options available (to 
revert back to std).  I like the text you have but I would also 
consider the sender is a MUST to be protocol correct with "standard" 
receiver logic.

MTA  MUST use but be aware of MDA, MSA. ALWAYS be ready for drops no 
matter what.
MDA SHOULD use, may reduce.
MSA  SHOULD use, may reduce.

Thanks

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos