On 2021-11-29 3:20 p.m., Bill Cole via mailop wrote:
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.
For anyone not familiar with the passage..
Bill is 'technically' correct on this point..
4.1.1.10. QUIT (QUIT)
This command specifies that the receiver MUST send a "221 OK" reply,
and then close the transmission channel.
The receiver MUST NOT intentionally close the transmission channel
until it receives and replies to a QUIT command (even if there was an
error). The sender MUST NOT intentionally close the transmission
channel until it sends a QUIT command, and it SHOULD wait until it
receives the reply (even if there was an error response to a previous
command).
(And yes Bill, we do see the odd system sending a FIN without even a
QUIT, and it is more complicated when the remote end tears down the SSL
connection before QUIT)
It does sound like you are arguing for dropping QUIT altogether, but the
protocol was designed for robustness, and there is a reason for the
general use of COMMAND/ACKNOWLEGEMENT.
However, he is missing that earlier in the same RFC we see.. (Notice the
MUST NOT, which over reaches the later SHOULD)
3.8. Terminating Sessions and Connections
An SMTP connection is terminated when the client sends a QUIT
command. The server responds with a positive reply code, after which
it closes the connection.
An SMTP server MUST NOT intentionally close the connection under
normal operational circumstances (see Section 7.8) except:
o After receiving a QUIT command and responding with a 221 reply.
o After detecting the need to shut down the SMTP service and
returning a 421 response code. This response 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).
o After a timeout, as specified in Section 4.5.3.2, occurs waiting
for the client to send a command or data.
In particular, a server that closes connections in response to
--
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada
This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
