/var/spool/cron/tmp?
My first guess would be, each of these files is collecting input from an instance of a cron job. When the job would finish, the cron daemon would use the file to mail the output to the job's owner.
Trouble is, although the target FTP server is down, the jobs are not giving up, but seem to be retrying again and again. And the cron daemon will most likely keep restarting new instances of the same jobs, until you do something. (A variant of "sorcerer's apprentice syndrome", I think.)
Depending on how often the cron jobs are scheduled, your process table might eventually become completely filled with cron job processes. At that point, no new processes can be started... which also means no one can log in to fix the problem. If it gets that bad, the only way to fix it may be to TOC the system.
Before removing those files, use the "fuser" command on them. Check out the process IDs listed: if they are related to those cron jobs, kill the processes. At that point, the files may seem to vanish on their own (because the cron daemon will be submitting them to sendmail, which will probably push the contents first to /var/spool/mqueue, and eventually to the job owner's mailbox).
If the files are already so large the attempt to mail them would cause problems, you might want to truncate the files instead of deleting them before killing the process that is holding the file.
The simplest "command" to truncate a file is to use the output redirection operator with no command, like this:
> /var/spool/cron/tmp/bigfile
MK
MK
