sending files via email between unix servers

[Srinivas_9]

Unix GURU's
I am trying to find a solution to transfer files from a client machine(HP&SUN) we support to our machine(HP&SUN). Both are on different networks. Since we support several clients setting up ftp on each of the client's server boxes is painfull and some clients unwilling.

I am looking at sending those files in a mail to our machine. So multiple senders one receiver.
We are expecting to receiving mails in the scale of 10 a day each approx 100 - 250MB size.
I was planning to write a tool on the receiving side polling for the mails coming in.
I tried to send the files as a attachment using uuencode and then uudecode at the receiving end. This is OK with small files, but with 100MB expected I am not sure if this is the right solution. Also i need to come up with a smart script to glean the /var/mail/.
when i use uuencode and mail it to say lotus notes /outlook, i get the file as attached.
Can we have a similar solution instead of encoding the attached file in the /var/mail/?


Is there any tool within the unix / open source available out there.
I am just looking at ideas, before I embark on a solution and realise there is a better solution out there.
Please keep in mind there are no PC's involved, just mailing files between two unix servers with the receiving side having a good mechanism to segregate based on some information in the subject.

Thanks for your time
Srinu

[A. Clay Stephenson]

Since you are receiving files, there is nothing to setting up ftp on the client end. You simply have to have ftpd running on your server. The overhead of an FTP transfer will be much less than that of sendmail + uuencode and the scripting will be no more difficult.

All you need to do is send this Perl script to each client and agree on a receiving directory on your server. Invoke as ftpput.pl -u for full usage. It will do the transfers; automatically retry if you like; and return a valid status. The password can be kept in .netrc on the client end (or passed on the command line). You should be able to encode any needed metadata in the filename itself.

[Srinivas_9]

Thanks Mr.Stephenson
I will give a try at your script.

But I doubt this will work when the both the servers are in completely different networks.

In other words can i use this script to send a file to some unix server in your work place assuming that u provided me the IP, username, password and the receiving directory? Even though my network is not configured to recognize your IPaddress?

[A. Clay Stephenson]

Routing for ftp is no different than routing for mail --- assuming that the firewall rules permit it. You will have to setup ftp accounts for these users (or allow anonymous ftp connections) or allow them to use a common account.

[Steven E. Protter]

Shalom Srinu,

I also have a script that permits sendmail attachments, based on something I found a while back on ITRC.

Problem is, 250 MB attachment? I'm sure sendmail is probably capable of sending the thing, but there will be a giant sucking sound (Thank you Ross Perot) when that file starts to transfer across networks.

If it passes through any smtp relay servers, the attachment could be stripped out as too large.

http://www.hpux.ws/mailfile2

I recommend setting up openssh and public keys between the servers and using the scp command to transfer the files.

SEP

[Bill Hassell]

Large email (more than a few megs) will ALWAYS be a huge problem. The reason is that unlike ftp where the two computers talk directly to each other, email must be passed along between mail servers (store and forward) once it leaves your local network. Most of your customers probably run some PC email system like Exchange or Lotus, which then filters incoming mail according to a myriad of rules (spam and virus filters, oversize, etc). So anything larger than 1-2 megs will probably get trashed. Unfortunately, the old days of bouncing the email back with a delivery failure (and reason) is almost unused anymore due to forged addresses so you won't even know that the email was silently deleted at your customer sites.

Automated FTP (or secure FTP) is by far the most useful solution. You will likely have to arrange for FTP firewall rules on your side as well as on your customers' firewalls. It will be MUCH faster and MUCH more reliable than email and will also have immediate feedback on failures.