> As for our test server we are currently shutting down the SSL layer for
> both connections (control and data) so this might be the cause of EPIPE.

I don't understand your reasoning. These are separate connections, closing one shouldn't affect the other.

> At this proposal I suggest to move the shutdown() call from
> SSLConnection.handle_close() to DummyTLS_DTPHandler.handle_close() and 
> see what happens.

What happens is that you are taking shortcuts with SSL since you aren't trying to do a proper shutdown :)
If you really think this is a good idea, feel free to give it a try.
But please see newssl2.patch as well.

(of course this is only a test server but AFAIU you would like to make it right)

> What happens now? I mean... what do we get instead of socket.error: 0?

A normal successful return.

> Wasn't SSL_MODE_AUTO_RETRY option applied in issue 8222 supposed to 
> already do that for us?

SSL_MODE_AUTO_RETRY deals with SSL negotiation. SSL_shutdown() has its own separate semantics, which have changed *even in blocking mode*. If I disable auto-retry I get failures such as:

======================================================================
ERROR: test_storbinary (test.test_ftplib.TestTLS_FTPClassMixin)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/cpython/newssl/Lib/test/test_ftplib.py", line 505, in test_storbinary
    self.client.storbinary('stor', f)
  File "/home/antoine/cpython/newssl/Lib/ftplib.py", line 727, in storbinary
    conn.unwrap()
  File "/home/antoine/cpython/newssl/Lib/ssl.py", line 264, in unwrap
    s = self._sslobj.shutdown()
SSLError: [Errno 2] _ssl.c:1374: The operation did not complete (read)

(note how "the operation did not complete" seems to mean that the socket is non-blocking, but the error is happening with the regular blocking FTP client)