From: Wietse Venema on
Victor Duchovni:
> 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.

This is OK when a connection will not be used further, but that is
a decision that should be made above the TLS layer.

> > 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 never want even the remotest possibility of plain-text I/O after
STARTTLS. For this reason, Postfix redirects all further I/O to
the bit-bucket, once TLS is turned off. Better safe than sorry.

Wietse

> 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.
>
>

From: Jerry on
On Wed, 10 Mar 2010 15:49:16 -0500 (EST)
Wietse Venema <wietse(a)porcupine.org> replied:

>Victor Duchovni:
>> 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.
>
>This is OK when a connection will not be used further, but that is
>a decision that should be made above the TLS layer.
>
>> > 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 never want even the remotest possibility of plain-text I/O after
>STARTTLS. For this reason, Postfix redirects all further I/O to
>the bit-bucket, once TLS is turned off. Better safe than sorry.
>
> Wietse
>
>> We still have soft (remember good IPs) connection re-use on the
>> drawing board. Most likely the above will never be needed.
>>
>> Viktor.

Wietse and Victor, from what I have deduced from reading your posts is
that I can safely ignore the warning. Is that correct? I am really
interested though in why this has suddenly started happening. I have
not touched Postfix or claws-mail, my MUA, in months. Except for
updating FreeBSD, nothing has changed that I am aware of.

--
Jerry
postfix.user(a)yahoo.com

TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail
TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html

You never know how many friends you have until you rent a house on the
beach.

From: Wietse Venema on
Jerry:
> Wietse and Victor, from what I have deduced from reading your posts is
> that I can safely ignore the warning. Is that correct? I am really
> interested though in why this has suddenly started happening. I have
> not touched Postfix or claws-mail, my MUA, in months. Except for
> updating FreeBSD, nothing has changed that I am aware of.

You can ignore the warning. The change is in the remote system not Postfix.

Wietse

From: Victor Duchovni on
On Wed, Mar 10, 2010 at 04:52:19PM -0500, Jerry wrote:

> Wietse and Victor, from what I have deduced from reading your posts is
> that I can safely ignore the warning. Is that correct? I am really
> interested though in why this has suddenly started happening. I have
> not touched Postfix or claws-mail, my MUA, in months. Except for
> updating FreeBSD, nothing has changed that I am aware of.

The connection closes before Postfix sees the "close-notify" SSL
alert from the remote party. Most likely no such alert is sent by the
application. You can safely ignore the warning.

--
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.