Greetings:

We do a lot of secure FTP. In regards to you point #2, it isn't a routing issue as such, it's a NAT issue. The FTP protocol includes the IP address of the client machine in the data portion of the packets. NATting firewalls have to change not only the headers of the initial FTP packets, but have to reach into the data packets and change the IP addresses as well. FTPS encrypts packets from the get-go, so what happens is the NAT firewalls change the packet headers, but don't change the client IP in the data. So the server tries to respond to the IP address in the data packet, which are usually IANA private, and definitely wrong no matter what, and it doesn't work.

There are several solutions. Some FTP clients that support FTPS have a spot where you can tell them what their outside IP address will be. It inserts that address into the data packet so the firewall doesn't have to change it. That works OK for people who have a static external address. It doesn't work well for road warriors. A more robust solution is FTPES. That protocol modification does the initial negotiations (which the NAT firewalls have to change) unencrypted, and then switches over to encrypted for passwords and data transmits.

SFTP can also a good choice, but on Linux FTP servers the user setup is different. FTP servers can be given a list of users & passwords separate from the host's user setup. SFTP is really SSH, and so the users are typically given accounts on the box. This isn't necessarily a problem, it's just different.

Good luck.

No, but I am successfully connecting against a dovecot imap server over SSL. Works like a champ.

Our SAN is keeping 4 copies of the data (2 local and 2 remote) and it costs us about $3.50 per GB/month over 3 years for SAN and bandwidth, but without power or data-center space factored in. I think you're paying a little too much.

I'm not saying that there aren't people who would like to see it changed. I'm questioning their ability to actually do it. Have the language syntax defined by an ANSI or ISO if you're that worried about it.

To actually manage to fork the language, they would have to get a group of enough people who all wanted to see the same changes in the language to actually agree to undertake the work themselves. It will never happen. They would then have to convince other, less militant users (the other 99.5% of the Java users) that their implementation of the language is better than Sun's. It will never happen.

If forking a language was feasable, I think that you would see a lot more of it. It might be possible to make a superset of a language that could work and might go on to have some life of its own, but if the fork breaks the existing language code it would be dead on arrival.