> First of all, I should say I'm implementing partial features of protocols
> which are practically useful and necessary at the time.
No complaints from me; delegate already implements a lot of stuff.
> As long as I know, FTPS using port #990 applies SSL without any
> negotiation and nothing to do with RFC2228.
It seems like the FTPS clients I tried (Filezilla and lftp so far) expect
an un-encrypted data channel by default. Given that lftp implements an
option "ftps:initial-prot" it seems like the authors are expecting a PROT
command to be supported on the server. I am just speculating (not having
read the source code for lftp) but my guess is that if delegate in FTPS
mode provided a PROT command, lftp in FTPS mode would try to use it.
Then there is still the question of what the client would request (by
default older lftp seem to ask for PROT C and newer ones for PROT P). It
seems to me like dynamically selected encryption of the data channel in
delegate might be a lot of work to implement, which is why I suggested
refusing the PROT command when it does not agree with the encryption
> It might be that you are making a configuration which is commonly
> applicable to other implementations of clients and servers, but I'm
> not sure...
You are exactly correct. I am trying to use delegate as a general-purpose
ftp proxy. Personally, I would prefer not to support FTP at all, but our
customers find it very useful. Our network security model requires us to
proxy FTP and in the past we have used ftp.proxy but I am trying to switch
to delegate to add SSL (and better PASV) support.
Anyway, thank you for your work on delegate. It is very useful.