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.

Fastmail can send emails up to 70MB (which due to encoding usually means the attachment can be 50MB).

I see a lot of on prem exchange implementation with limits at 50mb, 100mb.

Rackspace can send 50MB

Disappointed that this only covers receiving. There have been many times where I had to send a file of 27MB, etc.

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.

They do, recently they even started blocking 7z...

Rename .zip to .zpi or .izp or pzi, ... then it works.

With less than useful I agree (switched to fastmail...)

Me too. I use send zip files to my customers every now and then.

This is another example of them, subtly forcing you to use google drive for files.

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.

Which part of my comment did I say that I am sending executables?

Confusion comes from this:

> 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.

Well you're wrong. And you even downvoted me. My point still stands over your wrong assumptions.

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.

OT, but how can you tell who downvoted you?

you can't (well, unless they tell you).

Note that this is for receiving emails only; for sending large files, you'll still need to use Google Drive.

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.

how many do you have? and how large is it? I think Dreamhost will ban you one day.

Ban??? Where do you get that idea?

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.

Abuse or not just their call. Hosting the files for emails aren't general web hosting.

https://www.dreamhost.com/legal/unlimited-policy/

Yes, point taken. A couple of megs here and there, accessible via URL, shouldn't concern them. If it gets to be gigs, then it might become and issue.

Yet I still won't be able to email encrypted archives around.

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?

Will GMail support binary files and password protected archives again?

It's pretty off-putting - instead of just sending or adding a warning message, GMail blocks such files.

I wonder if you can send a 50MB attachment if using smtp-relay.gmail.com

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.

I guess it's slightly better than sending seventeen 1.44M floppy disks in the mail. Slightly. ;-)

Why not wetransfer.com? Sending attachments up to 2 GB through their free service is pretty painless, and sure beats Google Drive.

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.

[1] https://tools.ietf.org/html/rfc5321

[2] http://www.yenc.org/yenc-draft.1.3.txt

> We really shouldn't have to use an encoding scheme that has that kind of overhead.

But we do.

This only covers receiving files > 25MB.

Are we stupid?

Who even uses Drive? Let alone share anything using it.

I dont trust them to keep this feature, but more as a means to force people to use Google Drive.

You think they are going to go backwards in terms of quotas like this, in the future?

Right...

Anyway, this is a welcome change. I've bumped into the 20 MB limit a bunch of times...

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.

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.

The pure market share could have been a motivating factor for parent post. I assume that things behave differently when you're the #1 at something.

However, this seems arbitrary enough to not have that effect.

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)?

Gmail Attachments already count toward your drive space.

So, it is a what move to fill it up with mails.

Wow, that's good to know. It looks like one step before the force on more to Google Drive