EmailDiscussions.com

EmailDiscussions.com (http://www.emaildiscussions.com/index.php)
-   FastMail Forum (http://www.emaildiscussions.com/forumdisplay.php?f=27)
-   -   Fastmail says attachment's too big (http://www.emaildiscussions.com/showthread.php?t=72913)

m46ah_30 8 Aug 2017 08:23 PM

Fastmail says attachment's too big
 
I've been trying to send a .AVI file as an attachment in an email to three recipients through my "full" membership. I started with a 40 mb file which was returned. I decreased it to a 30 mb size that was again returned.

Am I trying to send too big a file or might I be running up against the limits of the file size my recipients can receive (which I don't know)?

BritTim 8 Aug 2017 11:00 PM

My understanding is that all accounts (including those with legacy plans) can now send and receive messages with an encoded size of up to 70 MB. This is inexact, but usually means you can send attachments of up to around 50 MB (before encoding for robust transmission).

If you are being told a 30 MB (or even 40 MB) attachment is too big, I am nearly sure this is a limitation at the recipient's end. The usual way to deal with this is by placing the attachment in a DropBox, or similar, instead.

janusz 9 Aug 2017 12:18 AM

Quote:

Originally Posted by BritTim (Post 603488)
The usual way to deal with this is by placing the attachment in a DropBox, or similar, instead.

... And a new and unusual way is to use https://send.firefox.com/
Quote:

Send files through a safe, private, and encrypted link that automatically expires to ensure your stuff does not remain online forever.

m46ah_30 9 Aug 2017 01:51 AM

Thank you
 
None of us has a Dropbox account so that's out.

I did send the rejected video to each recipient as a .zip file and it went through for reasons I can not discern.

I tried the Firefox tool and it works quite nicely for this purpose. I wish I knew how to contact the appropriate people at Mozilla to express my satisfaction and urge the to make the tool permanent!

Berenburger 9 Aug 2017 02:39 AM

Quote:

Originally Posted by BritTim (Post 603488)
If you are being told a 30 MB (or even 40 MB) attachment is too big, I am nearly sure this is a limitation at the recipient's end. The usual way to deal with this is by placing the attachment in a DropBox, or similar, instead.

Or https://wetransfer.com.

fmail_fan 9 Aug 2017 03:26 AM

Quote:

Originally Posted by m46ah_30 (Post 603491)
I wish I knew how to contact the appropriate people at Mozilla to express my satisfaction and urge the to make the tool permanent!

FYI, there is a Feedback button at the top/right of the main Firefox Send page (https://send.firefox.com/).

FredOnline 9 Aug 2017 03:38 AM

Quote:

Originally Posted by m46ah_30 (Post 603491)
None of us has a Dropbox account so that's out.

Has it suddenly become difficult/complicated to get a Dropbox account?

I don't recall any problems getting my account.

m46ah_30 9 Aug 2017 05:42 AM

Quote:

Originally Posted by FredOnline (Post 603494)
Has it suddenly become difficult/complicated to get a Dropbox account?
I don't recall any problems getting my account.

Fred... I don't see where I made any indication that I didn't have one because it's complicated. I (we) don't have one because I (we) have no pressing need for one. I can count on three fingers the number of times in the past several years when I needed or wanted to give anyone access to a large-enough file. If you're happy having your dropbox, consider me pleased for you; I'm content not having one more thing I have to find a use for.

sflorack 10 Aug 2017 10:58 AM

For sending large files, I've often setup a website through an FM alias and provided the link to the recipient.

ioneja 13 Aug 2017 10:53 AM

Quote:

Originally Posted by sflorack (Post 603524)
For sending large files, I've often setup a website through an FM alias and provided the link to the recipient.

Yep -- the FastMail files system is a secret weapon -- shhhh, don't tell anyone -- the OP has all that is needed to upload a file and set up a simple website link to share it.

Start here: https://www.fastmail.com/help/files/usage.html

Then go here: https://www.fastmail.com/help/files/website.html

And then you'll be addicted to a great little system built into your account.

soromak 16 Aug 2017 03:36 AM

Quote:

Originally Posted by ioneja (Post 603587)
Yep -- the FastMail files system is a secret weapon -- shhhh, don't tell anyone -- the OP has all that is needed to upload a file and set up a simple website link to share it.

Start here: https://www.fastmail.com/help/files/usage.html

Then go here: https://www.fastmail.com/help/files/website.html

And then you'll be addicted to a great little system built into your account.

This is only a partial solution if you want to send some files. How about receive?

With 150MB attachment size limit at MS Exchange Online (Office 365) a lot of people keeps sending larger and larger attachments. I hope Fastmail that also seems to be aiming into business users will match up Microsoft.

ioneja 16 Aug 2017 04:06 AM

Quote:

Originally Posted by soromak (Post 603605)
This is only a partial solution if you want to send some files. How about receive?

With 150MB attachment size limit at MS Exchange Online (Office 365) a lot of people keeps sending larger and larger attachments. I hope Fastmail that also seems to be aiming into business users will match up Microsoft.

Right, in that case, for larger inbound files, a file sharing platform is highly recommended. Email is just not naturally suited to large files IMO. 150MB attachment size is unusual. Best way to handle large files inbound is really a service like HighTail.com -- we use that to send really large files back and forth with clients... or something like Dropbox, Google Drive, OneDrive, etc...

janusz 16 Aug 2017 04:23 AM

Quote:

Originally Posted by ioneja (Post 603606)
Email is just not naturally suited to large files IMO.

Why? Just curious....

ioneja 16 Aug 2017 05:46 AM

Quote:

Originally Posted by janusz (Post 603607)
Why? Just curious....

For a bunch of reasons, but here are two big ones, for starters:

1) In the most practical sense, email attachment sizes are not standardized across email providers, which make it a pain in the neck, even today, in 2017. For example, as far as I recall, Office 365 is 150MB, Gmail is 25MB, Yahoo is 25MB, FastMail is 50MB last time I checked, Runbox is 130MB (which translates to 100MB since that's the encoded maximum), AOL (yes, still used by many people) is 25MB, Zoho Mail is 20MB. Yandex 25MB, iCould 20MB. And on and on.... Since no one can really agree on a standard size, it's by default very limited and causes confusion and issues across the board. Stick to around 10-15MB and you are safe with just about everyone.

2) Using email for large files is very inefficient for bandwidth and storage. Here's one example of what I mean:

If I want to sent a 100MB video file to 10 people via email, I can easily chew up massively more bandwidth and/or storage than a streaming/sharing service, for example. Once I send it, that's 10 copies of that data -- encoded (which is about 30% larger BTW) that is sent out. Boom. Huge waste off the bat. Then there will be 10 unique copies stored in 10 separate accounts on various servers, depending on the recipients. More waste. Then, each time that video is played, most email clients will download the whole thing locally, and if you don't save it locally, each time you view it, it will download the whole thing again. We're talking incredible inefficiency. Think of how many copies are actually sitting out there on so many hard drives... and then if people start forwarding and replying with inline attachments... we're just chewing up space like crazy... tons and tons of copies just floating around like dead weight. It doesn't make sense. Even backups of the local and/or remote email database (again, depending on the client and service you are using) -- you are potentially inflating backup storage with multiple copies of a big file... over and over, across every recipient of the file, ever. Just crazy.

Not to mention you've TOTALLY lost control of that file with no hope of putting that genie back in bottle, or at least restricting its distribution or auditing it's trail.

I mean, it gets pretty nasty when we start dealing with cell phone data bandwidth and streaming time/quality and general limits on cell phone plans... just as another point of consideration.

But compare all that to using a simple file sharing service like Dropbox. Now, Dropbox has a couple of ways of sharing a file... so this example is just one possible scenario I could paint... so for this let's say the recipient does NOT have a Dropbox account, so you would send them a shared link for them to download or view the file. Using the same scenario above... you send a LINK to 10 people, NOT the actual file. Right there you've saved a huge amount of bandwidth from the start. Your email client is sending a LINK and nothing else, saving 10 copies right there. Then, on their end, their email server is only storing a LINK. Again, massive savings. Then, on top of that, Dropbox creates a low-res streaming version of the video clip for you to save bandwidth so that if you are on your cell phone then you can actually watch a version of it, and even skip around -- so it doesn't even download the whole file unless you WANT to... thus saving even more bandwidth and storage for those that don't end up looking at the file. The savings are incredible... which ultimately translates to time and money.

In fact, how many times have you sent a file to 10 people and only 2 people looked at it? With email, their server and/or email client already has a copy of it, and they haven't even bothered to look at it. In this example, only 2 people access the Dropbox shared file.

Then think of the backups and forwards... you are backing up and forwarding just a link to the file... not the file itself. The logic goes on and on. Again, that's just one approach with file sharing via Dropbox... you have other methods within Dropbox that DO make unique copies on their hard drives as well. But even then, the data savings is notable with email.

In the most practical sense in my business, as a media producer, I have access to terabytes upon terabytes of video footage from my phone for my clients, and I can share any clip I want to with merely a link, that shows up near-instantly, and uses comparatively NO bandwidth unless my client wants to view some or all of a specific clip. My email is kept to minimal resources and a large file is accessed only when needed, using zero local storage (unless I want to download it).

So really, there is no comparison. Just for those two basic reasons alone, anything bigger than 25MB makes NO sense to me to send via email. First, because you don't know if the recipient's email server can handle it, and second, it just wastes energy, bandwidth, storage, and ultimately money. And if you are dealing with a recipient on limited data plans it can actually become a nightmare.

On top of that, file sharing systems have become very elaborate so that very useful tracking, delivery, feedback systems, management, security, auditing and other cool features are available now in some of those services... things that most email services are just inherently not good at. A very useful advantage of using a great file sharing system is good security that requires additional authentication to view a file. For example, a video clip meant just for a client can be restricted in some services to a specific login and expiration, and I can track exactly how many times the file has been accessed and by whom. It's not perfect, since the client can still do something stupid with the large file if they can download it locally, but it puts one extra layer of auditing in place that doesn't exist with email. Once you send a large file via email, on the other hand, you literally have NO auditing or control over the file again, with no idea what happened with it. This is especially important when dealing with things that have liability or privacy concerns.

The features are all over the map for each of these services, but two of the most powerful ones are box.com and hightail.com, both of which I've used for massive projects with clients. Dropbox Plus and Dropbox for Business have some of those similar features, but not quite as advanced in some key areas. Google Drive and OneDrive have some decent flexibility too, but I get very frustrated with them as they have some specific limitations for auditing and deliverability. If you want to go the privacy direction, then SpiderOak has some excellent features... the list goes on.

In my experience, once you get above about 10MB, the immediacy and convenience of email starts hitting obstacles, with increasingly diminishing returns as you increase attachment size. Once you go above 25MB, you lose Gmail and other major providers... and once you pass 50MB you've lost most of the big players. Once you go over 100MB you are just chewing up bandwidth and file storage like crazy, and it doesn't make much sense. At least not when even Dropbox can handle files that are theoretically unlimited, up to the capacity of your storage.

Just my two bits.

Terry 16 Aug 2017 07:34 AM

As stated above try https://send.firefox.com/

soromak 16 Aug 2017 01:57 PM

Quote:

Originally Posted by ioneja (Post 603608)

In my experience, once you get above about 10MB, the immediacy and convenience of email starts hitting obstacles, with increasingly diminishing returns as you increase attachment size. Once you go above 25MB, you lose Gmail and other major providers... and once you pass 50MB you've lost most of the big players. Once you go over 100MB you are just chewing up bandwidth and file storage like crazy, and it doesn't make much sense. At least not when even Dropbox can handle files that are theoretically unlimited, up to the capacity of your storage.

Just my two bits.

Gmail has increased message size limit for inbound to 50MB (outbound of larger attachments is done by Google Drive) and Office 365 increased it to 150MB based on the feedback from users.And I can see an increased trend of businesses moving to MS Cloud. So definitely there is a demand for larger attachment size from average user base. Just adding more and more services for sharing large files is more complicated for an average user sending large Powerpoint file and with a need to create more accounts at different file sharing platforms and so on poses a security risk and requires additional costs.

janusz 16 Aug 2017 04:45 PM

Quote:

Originally Posted by ioneja (Post 603608)
For a bunch of reasons, but here are two big ones, for starters:

Thank you, ioneja, for your detailed explanation.

The underlying (and unstated explicitly) background to my question was something like: is there a technical specification which puts a strict limit on the message size? (something like 'the length in bytes has to fit into a 32-bit integer'). I could not recall such a rule, but I'm far from claiming I know every verse of every relevant RFC :p

Your arguments, ioneja, are not of technical nature, they are based on your idea of best working practices, including "don't be a hog". I agree with some, but not all, of them. As they are a matter of opinion, I see no point in arguing about them in public.

Thank you again for presenting your point of view.

janusz 16 Aug 2017 06:30 PM

Quote:

Originally Posted by soromak (Post 603611)
Gmail has increased message size limit for inbound to 50MB [...]And I can see an increased trend of businesses moving to MS Cloud

This means all file-exchanging parties have to have an account with either Gmail or MS Cloud.

Quote:

Originally Posted by soromak (Post 603611)
with a need to create more accounts at different file sharing platforms and so on poses a security risk and requires additional costs.

Why there is a need to create more accounts at different platforms? Why one isn't sufficient?

BTW, one can download a file from Dropbox without opening a Dropbox account. I bet this goes for most, if not all, file sharing services.

ioneja 17 Aug 2017 02:35 AM

Quote:

Originally Posted by janusz (Post 603612)
Your arguments, ioneja, are not of technical nature, they are based on your idea of best working practices, including "don't be a hog".

Yep, my POV is entirely based on best working practices and the reality of working with super large files with lots of clients and projects over the years. I've probably tried every service out there, and every single one has issues. And yes, "don't be a hog" - lol. As for a technical reason why email wouldn't work, I can't give one.

And I agree with those that find this whole thing frustrating at times. I don't know how many times I've had to step a client through the process of sending me large files, and there is no magic bullet. So I tend to just use all the major services and whichever one my client gravitates to, is the one our particular relationship defaults to. It's occasionally messy.

Going back to best practices and trying to be relevant to the OP, my main point is to choose a file sharing platform that the whole party/group can agree upon, and try to stick with it... and that email itself is not going to cut it in the current practical world we live in, when dealing with really large files. So might as well just get on with it, and pick a system and then support each other to make use of those tools. Get the job done, right?

Ideally, there would be one universal protocol that is widely understood, implemented and accepted, with no additional accounts or tools, that could do it all seamlessly, but we're not there yet.

ewal 17 Aug 2017 06:21 PM

For large folders/files, 2-way collaboration, auditing etc I use Filezilla Server.

Small investment of time upfront and minimal effort thereafter.

Of course you need an always-on machine and sufficient upload bandwidth.

send.firefox.com looks great for quick one-off needs.

radtux 20 Aug 2017 12:17 PM

Sending via Dropbox is fine. Just share the link. Thats it. I do it all the time. Create a link on the fly and share it across the social networks/ chat applications etc.


All times are GMT +9. The time now is 08:55 AM.


Copyright EmailDiscussions.com 1998-2022. All Rights Reserved. Privacy Policy