When an explicit TLS session is started, the negociation goes fine. Your
client properly sends "AUTH TLS", the encryption layer is turned on on the
connection socket, then "PBSZ" is sent. All is ok.
The problem comes when the server is configured to use SSL/TLS on the
connection socket, but the data socket is intentionnaly left unencrypted.
Your client sends the "PROT" command to ask for possible SSL/TLS encryption
on the data socket. Then, if the server replies with a 200 error code
everything goes on with SSL/TLS.
But the server can also reply with a 534 error code which according to RFC
means "I don't want _this_ protocol on the data socket".
When your client get that 534 error code, it immediately ends the session.
Maybe it would be nicer in this case to retry with "PROT C" to fallback to
cleartext.
Your software wouldn't break with servers that only want the connection
channel encrypted.
Sure, there is an option in your software to explicitely have a clear data
connection. But this is rather confusing for end users. An automatic
fallback would be more convenient.
Please let me know if this issue is addressed in a newer release so that
the part about your product in the TLS documentation of Pure-FTPd can be
updated on
http://www.pureftpd.org/README.TLS
SSL/TLS and PROT command suggestion
Threaded Mode