topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • Wednesday April 24, 2024, 2:06 am
  • Proudly celebrating 15+ years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Author Topic: Is it possible to SFTP a file to an email inbox?  (Read 2604 times)

kalos

  • Member
  • Joined in 2006
  • **
  • default avatar
  • Posts: 1,824
    • View Profile
    • Donate to Member
Is it possible to SFTP a file to an email inbox?
« on: September 02, 2022, 04:16 PM »
Hello

SFTP and SMTP have very similar naming but are they the same in terms of security?

I need to SFTP a file to an email inbox but it seems there are several alternative ways they do that (e.g. via a web interface) which means that it is not that secure.

Any experience?

Thanks!

Ath

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 3,612
    • View Profile
    • Donate to Member
Re: Is it possible to SFTP a file to an email inbox?
« Reply #1 on: September 02, 2022, 05:00 PM »
No, no and no.

SFTP
SMTP

The only thing they have in common is "Transfer Protocol", but there are about 50* more of these.

* (the number is rather irrelevant)

x16wda

  • Supporting Member
  • Joined in 2007
  • **
  • Posts: 888
  • what am I doing in this handbasket?
    • View Profile
    • Read more about this member.
    • Donate to Member
Re: Is it possible to SFTP a file to an email inbox?
« Reply #2 on: September 02, 2022, 05:37 PM »
Assuming you want to transfer a file securely to someone, just use 7-zip and compress the file using AES encryption and a secure password (20+ chars, mixed letters and symbols, no dictionary words). Then email the file. But use a different method to send the password. Also you have to be concerned about the maximum size of an email that the recipient's mail system will accept.

But any way you look at it, if you need to get the file into someone's mailbox securely, then you need to encrypt it separately.
vi vi vi - editor of the beast

Deozaan

  • Charter Member
  • Joined in 2006
  • ***
  • Points: 1
  • Posts: 9,751
    • View Profile
    • Read more about this member.
    • Donate to Member
Re: Is it possible to SFTP a file to an email inbox?
« Reply #3 on: September 02, 2022, 07:14 PM »
Is there a reason why it needs to go into an email box specifically, or use SFTP specifically? If all you really need is to securely get a file to someone, there are plenty of other file sharing methods which have various levels/layers of security.

Shades

  • Member
  • Joined in 2006
  • **
  • Posts: 2,924
    • View Profile
    • Donate to Member
Re: Is it possible to SFTP a file to an email inbox?
« Reply #4 on: September 04, 2022, 01:37 PM »
As others said, you couldn't be farther from reality with SMTP and SFTP (or FTP/FTPS).

While Exchange setups for companies in Azure are often set for attachments greater than 10 MByte in total size (message + attachment), most Linux-based mail servers use the default of 10 MByte of total size (message + attachment). The attachment is less than 10 MByte actually, because the message part of an email contains much more data than most users realize. Add to that the default setting of HTML message content and even more data has to be reserved for the message part. As you most of the time do not know how mail messages are being distributed, most services still use the 10 MByte limit, just to be on the safe side.

Better use a 3rd party service for transferring files. WeTransfer is well known, at least in Europe. There are more of them, but that is the only one I remember, because I rather set up my own Google drive/OneDrive-like instance on my own web server. Well, if you are in complete control of your web server (and have a officially registered domain name or static IP-address that faces the internet) it takes hardly any effort to enable the WebDAV functionality that is baked into every web server software (Apache, NginX, IIS, LightHTTPd etc.), because it is part of the official HTTP protocol for many years already.

From your description I couldn't gather the following, so it likely does not apply to you. I'll add it anyway:
If you need to send/receive content to computers (plural) you own or at least manage, you can use simple executables inside the command-line to transfer content. In such a case, file size of the content is usually not a problem. Examples of such software: SCP (available in default Windows installations), WinSCP, CarotDAV. Not advised but the Windows command FTP is also still available.

If the remote computer has access to SharePoint, you might as well use that. But if not, it is easier to install NextCloud on your web server, or a similar tool. Makes things much more configurable in a pretty nice web interface. With such a setup you can use your browser, a Nextcloud (or equivalent) app on your phone or computer, GUI tools like WinSCP and CarotDAV to connect to the remote server and transfer that way. Mind you, the command-line tools from the previous paragraph also work without problem with this setup. You can make things (much!) harder for yourself in case you also run your own DNS server. In that case you'll need to at least have configured "forward" DNS resolving correctly.

While your Google-drive/OneDrive-like setup will not be as fast as the Google/Microsoft service, it will not be much slower if your ISP provides a decent enough connection to your house. And you will feel you have accomplished something regarding networking. Never hurts to put that on a CV.

If you insist on using SMTP as a way to transfer files, you can automate a lot by using a command-line SMTP mailer on the source computer and the remote computer will need to use a command-line POP3 mail receiver if you use a 3rd party mail service. Again, you will need to have a correctly configured internet domain at the source. You will also need to have both "forward" and "reverse" DNS resolving set up properly. Then you'll need to configure DKIM + SPF + DMARC correctly as well, else the 3rd party mail service won't transfer your mail messages. Worse, they direct your messages directly to their thrash can and most of the time don't even inform you about this. All for valid reasons, but I digress.

Command-line SMTP mailers such as CMail and SendMail are surprisingly capable, if everything is setup correctly. Too bad the whole SMTP/POP3 story is such a pain to setup. Oh, and you are still bound by the 10 MByte limit, so don't go this route at all. I added it for completeness.

SFTP then. WinSCP can act as a SFTP client. If I remember correctly, it can also do FTPS. These two protocols share FTP in their name...and that is all they share. These are very different ways of transferring content. The FTP and FTPS protocols are akin. SFTP isn't alike at all. SFTP is however much safer than FTP and FTPS. FTP and FTPS are very old protocols and are deemed very unsafe to use. Actually, lots of modern browsers have stated that they won't support FTP(S) anymore at all.

There is actually one thing more SFTP, FTP and FTPS have in common. All require a client and a server to be setup, before transfer can take place. In my opinion, FTP and FTPS should have set out to pasture many years ago. While it is not difficult to acquire a free SFTP client, free SFTP server software is a lot more difficult to come by. You'll find a lot of "free" ones, but those are all trial-versions. And severely limited. And most of them are terribly expensive, if you wish to buy a license. You should think of 800 USD and up. So good luck finding a proper SFTP server you can really use for free.

A whole lot of words to say that it will be much easier to simply use a 3rd party service, like OneDrive/Google-drive/Dropbox/Mega and whatever else you can think off. Personally, I find the tool: CarotDAV very handy for setting up connections to my own WebDAV server, but also for Google-drive/OneDrive/Dropbox and many others. And it is usable with a GUI, as well as the command-line. And because it uses HTTP and can use parallel connections, it is actually pretty fast. Faster than FTP/FTPS.

Example: For my purposes there is daily need to push a set of about 300 Mbyte in severely compressed archives from one continent to another. When testing with FTP/FTPS on my on-premise server, this set needed almost 1 hour to transfer completely. Using the same Linux server and having WebDAV configured, that time went to slightly over 10 minutes for a complete transfer. For reference, I also tested with Google drive and a full transfer took around 8 minutes.

As we need to comply with wishes from customers who absolutely do not want their content to be transferred through any other servers than EU servers (GPDR demands strictness on their end as well), practically all 3rd party services are excluded from use for our purpose. But my boss isn't complaining, a difference of about 2 minutes and a lot less legal headache is totally worth it. Which was the reason behind the need to investigate what our options were years ago.