On 2021-11-29 at 16:57:54 UTC-0500 (Mon, 29 Nov 2021 13:57:54 -0800)
Michael Peddemors via mailop <mich...@linuxmagic.com>
is rumored to have said:
On 2021-11-29 6:57 a.m., Larry M. Smith via mailop wrote:
On 11/24/2021, Michael Peddemors via mailop wrote:
CONN: 40.107.96.87 -> 25 GeoIP = [US] PTR =
mail-sn1anam02on2087.outbound.protection.outlook.com OS = Windows NT
kernel
Returning 250 ok [qp 3539411] for data
QUIT command received, args:
And then it terminates the connection, SSL collapses, without
waiting for the remote mail server to acknowledge the QUIT.
I get it that they 'might' think that closing when 'they are done'
and we gave a 250ok on the DATA, and they sent the QUIT.. I don't
know, thinking to shave a few milliseconds off of the connection,
but the RFC is pretty clear that a QUIT .. AND .. and acknowlegement
is part of RFC.
Comments? (And no, there is zero lag before they terminate)
If I understand you correctly;
When sending mail, *.outbound.protection.outlook.com appears to send
DATA, terminate via <CRLF>.<CRLF>, wait for a response, then issue
QUIT immediately followed by a TCP FIN packet.
Operationally, I don't think it makes a difference. RFC pedantics?
Maybe. Does the receiving system advertise the Pipelining SMTP
Service Extension?.. Does setting/un-setting that response to EHLO
make a difference to outlook.com's behavior? If so, does and/or
should RFC2920 allow for QUIT->TCP FIN?
No, Pipeline is not advertised, the RFC's say that when you send a
command, if you are NOT using pipelining, you need to wait for a
response, and that includes the QUIT.. wait for the receiving system
to send an OK in this respect, not only does it satisfy RFC's but also
helps differentiate from the many spamming systems that terminate as
quickly as they can to reduce overhead when spamming.
Review the precise wording of
https://datatracker.ietf.org/doc/html/rfc5321#section-4.1.1.10
SHOULD in RFCs is stronger than it is in casual use, but it is still
SHOULD, not MUST.
SMTP clients of all sorts have done this (and worse, e.g. just FIN after
getting a 250 at end-of-data) for at least 3 decades. I don't see how it
could possibly be useful at this late date to try to enforce that SHOULD
which only exists for a human sense of elegance and tradition. The
"polite" pattern doesn't serve any functional purpose at QUIT, because
there's no ambiguity for either side if the reply is simply lost. Even
if QUIT is never sent and the client just sends a FIN packet after its
last message is acknowledged, the only ambuiguity is that the server
doesn't know whether the client failed in some way or was just finished
sending messages, and that's not something a server should usually care
about.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
