From: Wietse Venema on 10 Mar 2010 15:49 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 10 Mar 2010 16:52 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 10 Mar 2010 17:45 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 11 Mar 2010 10:47 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.
First
|
Prev
|
Pages: 1 2 3 Prev: problem with relay, please help me... Next: conten filter and always_bcc parameter |