Subject: [Emailcore] Ticket #28: Erratum 1851: Location of text about TCP connection has closure/reset

From: Alexey Melnikov <[email-masked]>
Date: Mon, 14 Dec 2020 11:50:48 +0000

Hi,

Alessandro Vesely wrote in the erratum 1851:

------------

Section 4.1.1.5. says:

   There are circumstances, contrary to the intent of this
   specification, in which an SMTP server may receive an indication that
   the underlying TCP connection has been closed or reset. To preserve
   the robustness of the mail system, SMTP servers SHOULD be prepared
   for this condition and SHOULD treat it as if a QUIT had been received
   before the connection disappeared.

Notes:

That text seems inappropriate in the RESET (RSET) section. It should 
presumably be moved to section 4.1.1.10. QUIT (QUIT), or, better yet, to 
section 3.8. Terminating Sessions and Connections.

------------

Strawman proposal: Section 4.1.1.5 is indeed a wrong place for this 
text. I think Section 3.8 is the right place for it. The last paragraph 
of 3.8 already contains the following text:

    SMTP clients that experience a connection close, reset, or other
    communications failure due to circumstances not under their control
    (in violation of the intent of this specification but sometimes
    unavoidable) SHOULD, to maintain the robustness of the mail system,
    treat the mail transaction as if a 451 response had been received and
    act accordingly.

So I think the text mentioned in the erratum should be moved after the last paragraph of Section 3.8.

Please provide feedback on this strwman proposal. In absence of feedback, this issue will be resolved as proposed above.

Best Regards,
Alexey

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 15 Dec 2020 11:09:28 +0100

On Mon 14/Dec/2020 12:50:48 +0100 Alexey Melnikov wrote:
> That text seems inappropriate in the RESET (RSET) section. It should presumably 
> be moved to section 4.1.1.10. QUIT (QUIT), or, better yet, to section 3.8. 
> Terminating Sessions and Connections.
> 
> ------------
> 
> Strawman proposal: Section 4.1.1.5 is indeed a wrong place for this text. I 
> think Section 3.8 is the right place for it. The last paragraph of 3.8 already 
> contains the following text:
> 

+1, that's the proper place.

Best
Ale
--

---

From: Julien ÉLIE <[email-masked]>
Date: Sat, 26 Dec 2020 10:56:26 +0100

Hi all,

>     treat the mail transaction as if a 421 response had been received and
>     act accordingly.
> 

A bit earlier in the same Section 3.8, we have:

    o  After detecting the need to shut down the SMTP service and
       returning a 421 reply code.  This reply code can be issued after
       the server receives any command or, if necessary, asynchronously
       from command receipt (on the assumption that the client will
       receive it after the next command is issued).

I'm wondering whether the part in parenthesis really occurs in practice, 
notably when the closure is asynchronous from command receipt.  Maybe it 
should be reworded this way:  "on the assumption that the client will 
receive it after the next command is issued or read it before closing 
the connection at its side"?

Another suggestion for the new paragraph:

    SMTP clients that experience a connection close, reset, or other
    communications failure due to circumstances not under their control
    (in violation of the intent of this specification but sometimes
    unavoidable) SHOULD, to maintain the robustness of the mail system,
+  try to read a possible asynchronous reply from the SMTP server, and
+  otherwise
    treat the mail transaction as if a 421 response had been received and
    act accordingly.

Naturally, if you think it makes sense.  Just opening the discussion.

-- 
Julien ÉLIE

« Les trois journées de 1830 ont renversé 89. »

---

From: "Alexey Melnikov" <[email-masked]>
Date: Thu, 31 Dec 2020 16:08:18 +0000

Hi Julien,

> the connection at its side"?

I think we should open a separate ticket on this.

>     treat the mail transaction as if a 421 response had been received and

Personally I am fine with this addition.

Best Regards,
Alexey