On 2021-11-30 09:00:14 (+0800), Michael Peddemors via mailop wrote:
On 2021-11-29 3:20 p.m., Bill Cole via mailop wrote:
Michael Peddemors via mailop is rumored to have said:
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).
This unambiguously permits the sender to terminate the connection as
soon as it has sent a QUIT command.
As Bill points out, RFC 2119 SHOULD (also spelled RECOMMENDED) is
stronger than a casual "should". It has a very specific definition
which is worth repeating in full:
SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
(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)
This is not allowed. Per the paragraph you cite above the client MUST
send a QUIT command.
Tangentially, in the context of RFC 5321, it's not clear to me what the
ramifications of not sending a QUIT could be. If the receiver
acknowledged the <CRLF>.<CRLF> at the end of DATA with 250 OK, it has
accepted the message. So there's not much that can be done about that.
Refusing to talk to that sender in future is likely acceptable though.
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.
It sounds to me like Bill is merely arguing for the correct
interpretation of the RFC 2119 SHOULD.
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.
I read "server" as "receiver" here, in light of the first bullet point.
I don't see this MUST NOT applying to the client/sender in any way.
Having written all that though, RFC 2119 clearly states that an
implementation must be prepared to accept the consequences of ignoring a
SHOULD. In this context, a receiver choosing to treat a sender with
suspicion for ignoring that SHOULD is perfectly germane.
Philip
--
Philip Paeps
Senior Reality Engineer
Alternative Enterprises
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
