What do you mean keep? Once they release this 50mb limit it's pretty much set in stone forever as other email providers will assume gmail users can accept it. If they removed/lowered it then emails would break.
They would sunset the feature and migrate all attachments to Google Drive, I think they did the same with Picasa and forced a move to Google Photos (I might not remember the product names correctly, I didnt use it but family members did)?
What do you mean by "emails would break"? They would be rejected by Googles MX servers, and the sending server would relay a bounce message to the sender explaining the problem... That is just a normal function of email.
All MX servers have arbitrary limits. Those limits can be increased/reduced at will without "breaking email"
It is already a common case that people send emails which are larger than the receiving system is willing to accept and are therefore rejected. They then receive a bounce and make alternative arrangements for transferring the file.
I mean, what's so stupid about it? If they need to move a large file, why shouldn't email be able to handle it? Why should we have different systems for moving small files and large ones?
If the answer is "limitations of the email system", then that's a failure of the people who designed and built email, not a failure of the user.
Stuff isn't free; email was intended to be a way for people to exchange electronic messages, not a way for people to transfer petabytes of HTML, JavaScript, images, movies, file archives & The Aristocrats.
I can send 5+ gig files around with Google Drive/Dropbox/Box/oneDrive for free, or up to 100gig files for less than I pay for email already. So it's not the price of storage or bandwidth that's the problem.
And transferring files is definitely part of what email was built to do - attachments are part of the MIME spec, after all. Remember, we're talking about somebody trying to send a ~51MB powerpoint file. That's a far cry from petabytes.
What users who try to send very >50MB files via email are trying to do is reasonable given email's purpose and nature of the internet. It's just that email isn't well-designed enough to handle it.
> And transferring files is definitely part of what email was built to do - attachments are part of the MIME spec, after all.
MIME was added well after the fact. RFC 821 (SMTP) is from 1982; RFC 2045 (MIME) is from 1996. Even back then, many of us were cranky seeing BAse64-encoded MIME data in emails and newsgroups, and considered it a bit uncouth to send more than a screen or two's worth of encoded data.
Remember too that Base64 encoding increases file size by 33%.
What do you do if the connexion drops after 49MB have been sent?
Email is not poorly-designed; it's just not designed to do this particular thing being asked of it, although it often does succeed anyway.
Now that we've had email for 35 years, is it worth designing an improved replacement? Sure! Ought it to include very-large-file support? Sure! But good luck getting anyone to use it — a good part of why email succeeded where X.400 failed is that it's simple.
> Remember too that Base64 encoding increases file size by 33%.
We really shouldn't have to use an encoding scheme that has that kind of overhead. According to the SMTP RFC 5321 section 3.1.1.4 [1], data sent during the DATA phase may contain any of the 128 ASCII characters (though control characters should be avoided). Based on my testing with a couple of commercial SMTP servers I have accounts on, it appears that it will allow almost all characters (0 - 255) through unaltered or escaped except for NUL, CR, LF, and . (in the first column only).
Interestingly enough, the binary newsgroup hierarchy uses an encoding termed yEnc [2] that actually uses almost all ascii characters (other than the ones I mentioned above) to encode binaries and puts the resulting data directly in the body of the news article. It appears that it would work just as well over SMTP and only has roughly a 2% overhead compared to the original file size. Unfortunately, that encoding is just a defacto standard and has not, to my knowledge, ever been submitted as an RFC or used outside of binary newsgroups.
GMail is less than useful for sending attachments, assuming they still do stuff like blocking .zip files containing executables. I can't use my GMail account to communicate with customers at all.
Yeah this is a conspiracy, definitely not for preventing people from sending malware around.
If you are sending executables to your customers and you're not signing them or they are not checking the signature every time, you are doing your customers a disservice and they are bound to get exploited sooner or later. If you teach them to open executables from mail they will and it won't be limited to yours.
Sigh. Yes, they're compiled here. Yes, they're signed. Yes, some people actually do know what they're doing. No, executables distributed in zipfiles are not now, and never have been, a prime vector for malware distribution.
> Me too. I use send zip files to my customers every now and then.
That `Me too` is in response to
> GMail is less than useful for sending attachments, assuming they still do stuff like blocking .zip files containing executables. I can't use my GMail account to communicate with customers at all.
What ? I am not saying I buy that logic. I am even trying to explain where the confusion comes from and in doing so showing you didn't explicitly write what's attributed to you (sending .exe files in archive files).
It happens a lot in threaded discussions here that a parent's opinions or points get carried over to child posts and then grand-children posts who seems to assume every answers only adds up details to reinforce the opinion instead of nuances.
I downvoted you for being a dick in the way you respond to the comment wrongly assuming you send .exe files. That is my only assumption here.
Oops sorry. I thought I was responding to GP. His response was not very polite, dismissing my comment as a conspiracy theory and assumed (wrongly) I was sending exe files.
And then I was accused of being a dick. Perhaps I should detach before I give people more wrong impression about me.
I built a gmail plugin several years ago that let you send arbitrarily large attachments w/ web download so you didn't have to use google drive, but had a terrible time marketing and promoting it. Now it seems like there are a lot of third party options in the space, is this really an issue given the services available?
It says Gmail but is on the G Suite blog and mentions specifically G Suite Editions. So was wondering earlier today if it applies to G Suite Gmail Only or all gmail customers including @gmail.com?
My main question is however how will the receiving more help if the sending limit is still low? Are there any top email providers such as Microsoft, Yahoo, etc, that support sending more than 25MB emails?
I think when sending emails to other gmail/g suite users the send limit should be 50mb, but when sending to anyone else should be 25mb, since 99% of others would only be 25mb receiving limit and would be a lot of email bounces otherwise.
For years, I've used a web hosting company instead of attachments. A simple alias uploads a file to the web host, and I can just paste in a URL.
Dreamhost gives so much space that I just leave stuff up there and almost never remove it, so the link stays good; and since it's my own domain name, it will remain good even if I change hosts.
I guess Drop Box and Google Drive are the modern equivalents, but my URLs are nice and simple and I have complete control. Really, I'm surprised more people don't do it this way.
Dreamhost gives you gigabytes of space even on the basic $9/month plan, and they add more storage over time until you basically have unlimited space.
The one thing they don't like is to use your account as a place to back up a 500 gig drive. You will get an automated warning if you do (based on my experience). The rule of thumb is use, don't abuse.
Awesome. Right now the industry standard is to limit incoming mail to 25mb attachments. Once it becomes common place to accept larger sizes we can squash out these technological relics.
50 comments
[ 6.0 ms ] story [ 206 ms ] threadRight...
Anyway, this is a welcome change. I've bumped into the 20 MB limit a bunch of times...
All MX servers have arbitrary limits. Those limits can be increased/reduced at will without "breaking email"
It is already a common case that people send emails which are larger than the receiving system is willing to accept and are therefore rejected. They then receive a bounce and make alternative arrangements for transferring the file.
However, this seems arbitrary enough to not have that effect.
However, this seems arbitrary enough to not have that effect.
So, it is a what move to fill it up with mails.
If the answer is "limitations of the email system", then that's a failure of the people who designed and built email, not a failure of the user.
And transferring files is definitely part of what email was built to do - attachments are part of the MIME spec, after all. Remember, we're talking about somebody trying to send a ~51MB powerpoint file. That's a far cry from petabytes.
What users who try to send very >50MB files via email are trying to do is reasonable given email's purpose and nature of the internet. It's just that email isn't well-designed enough to handle it.
MIME was added well after the fact. RFC 821 (SMTP) is from 1982; RFC 2045 (MIME) is from 1996. Even back then, many of us were cranky seeing BAse64-encoded MIME data in emails and newsgroups, and considered it a bit uncouth to send more than a screen or two's worth of encoded data.
Remember too that Base64 encoding increases file size by 33%.
What do you do if the connexion drops after 49MB have been sent?
Email is not poorly-designed; it's just not designed to do this particular thing being asked of it, although it often does succeed anyway.
Now that we've had email for 35 years, is it worth designing an improved replacement? Sure! Ought it to include very-large-file support? Sure! But good luck getting anyone to use it — a good part of why email succeeded where X.400 failed is that it's simple.
We really shouldn't have to use an encoding scheme that has that kind of overhead. According to the SMTP RFC 5321 section 3.1.1.4 [1], data sent during the DATA phase may contain any of the 128 ASCII characters (though control characters should be avoided). Based on my testing with a couple of commercial SMTP servers I have accounts on, it appears that it will allow almost all characters (0 - 255) through unaltered or escaped except for NUL, CR, LF, and . (in the first column only).
Interestingly enough, the binary newsgroup hierarchy uses an encoding termed yEnc [2] that actually uses almost all ascii characters (other than the ones I mentioned above) to encode binaries and puts the resulting data directly in the body of the news article. It appears that it would work just as well over SMTP and only has roughly a 2% overhead compared to the original file size. Unfortunately, that encoding is just a defacto standard and has not, to my knowledge, ever been submitted as an RFC or used outside of binary newsgroups.
[1] https://tools.ietf.org/html/rfc5321
[2] http://www.yenc.org/yenc-draft.1.3.txt
But we do.
With less than useful I agree (switched to fastmail...)
This is another example of them, subtly forcing you to use google drive for files.
If you are sending executables to your customers and you're not signing them or they are not checking the signature every time, you are doing your customers a disservice and they are bound to get exploited sooner or later. If you teach them to open executables from mail they will and it won't be limited to yours.
> Me too. I use send zip files to my customers every now and then.
That `Me too` is in response to
> GMail is less than useful for sending attachments, assuming they still do stuff like blocking .zip files containing executables. I can't use my GMail account to communicate with customers at all.
from GP.
It happens a lot in threaded discussions here that a parent's opinions or points get carried over to child posts and then grand-children posts who seems to assume every answers only adds up details to reinforce the opinion instead of nuances.
I downvoted you for being a dick in the way you respond to the comment wrongly assuming you send .exe files. That is my only assumption here.
And then I was accused of being a dick. Perhaps I should detach before I give people more wrong impression about me.
My main question is however how will the receiving more help if the sending limit is still low? Are there any top email providers such as Microsoft, Yahoo, etc, that support sending more than 25MB emails?
I think when sending emails to other gmail/g suite users the send limit should be 50mb, but when sending to anyone else should be 25mb, since 99% of others would only be 25mb receiving limit and would be a lot of email bounces otherwise.
Dreamhost gives so much space that I just leave stuff up there and almost never remove it, so the link stays good; and since it's my own domain name, it will remain good even if I change hosts.
I guess Drop Box and Google Drive are the modern equivalents, but my URLs are nice and simple and I have complete control. Really, I'm surprised more people don't do it this way.
Dreamhost gives you gigabytes of space even on the basic $9/month plan, and they add more storage over time until you basically have unlimited space.
The one thing they don't like is to use your account as a place to back up a 500 gig drive. You will get an automated warning if you do (based on my experience). The rule of thumb is use, don't abuse.
https://www.dreamhost.com/legal/unlimited-policy/
It's pretty off-putting - instead of just sending or adding a warning message, GMail blocks such files.
Who even uses Drive? Let alone share anything using it.