On Tue, Feb 02, 2021 at 06:49:31AM -0800, Leo Bicknell wrote:
> In a message written on Tue, Feb 02, 2021 at 09:23:56AM -0500, Viktor
> Dukhovni wrote:
> > There is no issue, because SMTP is self-framing. The SMTP transaction
> > is cleanly terminated via QUIT or RSET at the application layer. There
> > is no need for the transport protocol to provide end-of-stream
> > integrity.
>
> Perhaps there is no RFC compliance issue, but I submit there is a
> troubleshooting issue. On the far end, the mail admin is likely
> to get an error in their logs that the connection was dropped
> uncleanly. How are they supposed to distinguish the case of
> legitimate network problems clobbering connections from the case
> of the software doesn't bother to handle shutdown properly?
There is no problem, both sides send a "close_notify" alert when closing
their "write side" of the transmission channel. So neither reader will
ever see an abuptly lost connection. However, keep in mind that TLS or
no TLS, Postfix will by default close the connection after sending
"QUIT":
smtp_skip_quit_response = yes
*without* waiting for the "221" response from the server. Which means
that servers may encounter write errors when sending "221" or the
subsequent TLS close_notify. The best thing to do in that case is
just ignore the error, and not waste the administrator's time chasing
ghosts.
> I am clearly not as well versed in SMTP protocol nuances as yourself,
> however I did find this in the exim source code, src/transports/smtp.c:
>
> /* Before passing the socket on, or returning to caller with it still
> open, we must shut down TLS. Not all MTAs allow for the continuation
> of the SMTP session when TLS is shut down. We test for this by sending
> a new EHLO. If we don't get a good response, we don't attempt to pass
> the socket on. */
There is no "STOPTLS" in SMTP to negotiate tear-down of TLS in a manner
that leaves the connection open to new cleartext traffic. After
STARTTLS, closure of the TLS session implies closure of the transmission
channel. If someone writes a draft to define a "STOPTLS" ESMTP
extension, then if the client requests a TLS session that can be closed
without closing the socket, and the server agrees, they should certainly
do the bilateral TLS shutdown dance, to return back to clear text.
As it stands, that speculative, Exim comment but not comport with
reality.
> In order for that code to work, the tls_close() operation must complete a
> proper shutdown. Also from https://tools.ietf.org/html/rfc8446#section-6.1:
No, in order for that to work, there would need to an RFC that defines
STOPTLS, so it could be properly negotiated, rather than just hacked
in speculatively.
> That would seem to turn the requirement into a MUST when the TLS session
> is terminated, so the connection can be used in the clear after that point.
> And that means _both_ sides must properly perform the termination.
The SMTP protocol is a half-duplex exchange of messages, framed at the
application layer. Any coordination transition from TLS (started with
STARTTLS) back to cleartext would require a new STOPTLS ESMTP feature.
> Perhaps Postfix does not support returning to clear text from a
> STARTTLS session and doing futher protocol operations. I have not
> looked. But if it does, I believe the proper shutdown behavior is a
> MUST.
Postfix does not support such an SMTP protocol non-feature, because it
is a non-feature of the SMTP protocol. :-)
If some other MTA supports such a feature, it is doing so outside the
SMTP protocol, and in conflict with expected SMTP behaviour where all
transitions are driven at the application layer via appropriate SMTP
command sent and positive responses received.
--
Viktor.
