On Tue, Feb 02, 2021 at 05:26:52AM -0800, Leo Bicknell wrote:
> I have been recently debugging some corner cases in OpenSSL's
> SSL_shutdown call in sendmail (I ask your forgiveness) and now that
> I seem to have it right there I have decided to look at other mailers
> for similar issues.
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.
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.
https://tools.ietf.org/html/rfc8446#section-6.1
Each party MUST send a "close_notify" alert before closing its write
side of the connection, unless it has already sent some error alert.
This does not have any effect on its read side of the connection.
Note that this is a change from versions of TLS prior to TLS 1.3 in
which implementations were required to react to a "close_notify" by
discarding pending writes and sending an immediate "close_notify"
alert of their own. That previous requirement could cause truncation
---> in the read side. Both parties need not wait to receive a
---> "close_notify" alert before closing their read side of the
---> connection, though doing so would introduce the possibility of
---> truncation.
> That's why I'm on a quest here to see if I can get all mailers to
> handle all of the cases correctly, and make the Internet a better
> place.
Perhaps there are less quixotic quests that are worthy of your energy.
--
Viktor.
