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?
Basically, your argument sounds a lot to me like proposing to end
all TCP sessions with a RESET packet, since completing a shutdown
handshake should be unnecessary. After all, you said "There is no
need for the transport protocol to provide end-of-stream integrity."
> After sending a close notify, a TLS application is NOT required to wait
> for a matching close notify from its peer, that is only needed for
> applications where half-closed connections can still carry relevant
> data, but SMTP is not such an application.
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. */
tls_close(sx->cctx.tls_ctx, TLS_SHUTDOWN_WAIT);
sx->cctx.tls_ctx = NULL;
smtp_peer_options = smtp_peer_options_wrap;
sx->ok = !sx->smtps
&& smtp_write_command(sx, SCMD_FLUSH, "EHLO %s\r\n", sx->helo_data)
>= 0
&& smtp_read_response(sx, sx->buffer, sizeof(sx->buffer),
'2', ob->command_timeout);
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:
If the application protocol using TLS provides that any data may be
carried over the underlying transport after the TLS connection is
closed, the TLS implementation MUST receive a "close_notify" alert
before indicating end-of-data to the application layer. No part of
this standard should be taken to dictate the manner in which a usage
profile for TLS manages its data transport, including when
connections are opened or closed.
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.
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.
--
Leo Bicknell - bickn...@ufp.org
PGP keys at http://www.ufp.org/~bicknell/
