On Wed, Mar 10, 2010 at 03:08:18PM -0500, Wietse Venema wrote:
> > With TLS sessions, after "QUIT" processing, the server tries to perform
> > a clean SSL_shutdown() of the SSL/TLS session. If the client closes
> > the connection without performing the SSL_shutdown(), you'll see the
> > above warning. [...]
> >
> > Another option (given that Postfix does not have a "STOPTLS" feature that
> > would allow re-use of the physical connection for further I/O after SSL
> > shutdown)
>
> The Postfix SMTP client does properly shutdown the connnection.
Yes, my point was that it would legal to do just a one-sided
SSL_shutdown(), instead of a full bi-directional SSL_shutdown().
> smtp_session_free() calls tls_client_stop().
> tls_client_stop() is an alias for tls_session_stop().
> tls_session_stop() calls tls_bio_shutdown().
> tls_bio_shutdown() is an alias that calls SSL_shutdown().
Yes, it calls SSL_shutdown() twice, once to notify the peer, and another
time to read the peer's shutdown alert. We could omit the second step
if we wanted to, and thereby avoid the condition that generates this
(harmless) warning.
> Sending application-level data after turning off TLS is definitely
> a no-no.
At this time there is no standard for reverting an SMTP connection to
plain-text and resuming TLS on the same connection (or even continuing
in plain-text). Technically, this is possible, and potentially even
an interesting SMTP extension that would allow caching of TLS connections,
by suspending TLS, caching the socket, and then resuming TLS when the
plain-text socket is re-used.
We still have soft (remember good IPs) connection re-use on the drawing
board. Most likely the above will never be needed.
--
Viktor.
P.S. Morgan Stanley is looking for a New York City based, Senior Unix
system/email administrator to architect and sustain our perimeter email
environment. If you are interested, please drop me a note.
