Ask Slashdot: Why Haven't They Increased Size Limits for Email Attachments? 260
"Email system are quite capable of sending and receiving large attachments," writes long-term Slashdot reader Stonefish "However, size limits are generally tiny."
And then he tells a story... In the late 1990s I worked for a research organisation maintaining their mail system, and had recently introduced mail size constraints. Within the first day it had blocked a number of emails — including a 700MB attachment.
Being a master of all thing Internet I called up the sender to tell him firstly how such a large email would cause problems for the receiver, and secondly how there were far more efficient ways of sending things. Given that he was on the same campus he invited me down to his lab to discuss this further. (After showing me round his lab, which was pretty impressive apart from the large "Biohazard" and "Radioactive" materials labels on the doors.) He told me that the facility he was sending the attachments to was a supercomputing hub with similar "Fat" pipes to the Internet so the large emails weren't a problem. I then spoke about the "efficiency" of the mail protocol and he said that he'd show me what efficient was and did a quick, "drag, drop and send" of another 700MB file of his latest research results.
He was right, I was wrong, it was efficient from his perspective and all his previous emails were easily available demonstrating when and where they were sent. As a result of this we changed our architecture and bought bulk cheap storage for email as it was a cheap, searchable and business focused approach to communications.
However 20 years plus later, even though networks are tens of thousands of times faster and storage is tens of thousands of times cheaper — email size limits remain about the same. Email remains cheap, efficient and ubiquitous — but we expect people to upload a file to a site and generate a link and embed in a manner that means we lose control of our data or it disappears in 12 months.
What's missing from this analysis? (Wikipedia's page on email attachments notes the intermediate "mail transfer agents" that store and forward email "and may therefore also impose size limits.") But even that page admits some attachment limits are arbitrary.
I always assumed it was an anti-piracy measure. Anyone know the real answer? Share your own thoughts in the comments.
Why haven't they increased size limits for email attachments?
And then he tells a story... In the late 1990s I worked for a research organisation maintaining their mail system, and had recently introduced mail size constraints. Within the first day it had blocked a number of emails — including a 700MB attachment.
Being a master of all thing Internet I called up the sender to tell him firstly how such a large email would cause problems for the receiver, and secondly how there were far more efficient ways of sending things. Given that he was on the same campus he invited me down to his lab to discuss this further. (After showing me round his lab, which was pretty impressive apart from the large "Biohazard" and "Radioactive" materials labels on the doors.) He told me that the facility he was sending the attachments to was a supercomputing hub with similar "Fat" pipes to the Internet so the large emails weren't a problem. I then spoke about the "efficiency" of the mail protocol and he said that he'd show me what efficient was and did a quick, "drag, drop and send" of another 700MB file of his latest research results.
He was right, I was wrong, it was efficient from his perspective and all his previous emails were easily available demonstrating when and where they were sent. As a result of this we changed our architecture and bought bulk cheap storage for email as it was a cheap, searchable and business focused approach to communications.
However 20 years plus later, even though networks are tens of thousands of times faster and storage is tens of thousands of times cheaper — email size limits remain about the same. Email remains cheap, efficient and ubiquitous — but we expect people to upload a file to a site and generate a link and embed in a manner that means we lose control of our data or it disappears in 12 months.
What's missing from this analysis? (Wikipedia's page on email attachments notes the intermediate "mail transfer agents" that store and forward email "and may therefore also impose size limits.") But even that page admits some attachment limits are arbitrary.
I always assumed it was an anti-piracy measure. Anyone know the real answer? Share your own thoughts in the comments.
Why haven't they increased size limits for email attachments?
There are the obvious reasons (Score:5, Insightful)
Meanwhile, their mail server is choking and out of storage space.
Just because you have gigabytes of space on your desktop and a 1g fiber connection, doesn't mean giant emails are a good idea.
Re: (Score:2)
Re: (Score:2)
Re: There are the obvious reasons (Score:2)
The bigger problem is that while large email attachments aren't a technical challenge, the universes' propensity to create better morons outpaces storage and the capabilities of the email client. For example, using a +50gb PST/OST file is going to require constant consistency scanning. Users won't do that, they will make a
Re: (Score:2)
Google offers a more intelligent scheme that automatically converts email attachments over 25gb to Google Drive files with links that permit "many to one".
Which sucks and confuses recipients. Now, this might be okay if there was some standard that email clients could follow to make those links look and act link normal attachments.
Let one of the big players do it and the rest will follow -- like the html email plague.
Re: (Score:2)
One day MS will copy this feature.
Christ I hope not, it is a fucking awful feature that assumes the end recipent has the connectivity and ability to download them. Any cunt dumb enough to email a 25gb+ attachment should be blocked not enabled.
Re: There are the obvious reasons (Score:2)
I'm hoping poster meant 25Mb not Gb. 25Gb is more than the 15Gb free storage you get with a Google Drive. :-)
Re: (Score:2)
Where I live, our corporate 100Mbit connection costs about 10 times what I pay for 1Gbit at home. I haven't even bothered asking what they'd charge for corporate gigabit, because we just don't need it.
Not many companies would want to deal with the storage requirements of people sending hundreds of megabytes worth of attachments to their 200 favorite colleagues. You put that on a damn fileshare and let them know where. If they're documents, you check them into the document management system and tell people a
Re: (Score:3)
There are a few reasons for that. The leased line is a dedicated link for the corporation, not a neighborhood shared endpoint. It is often symmetrical, being that it's 100Mbps in both directions and being a leased line there might actually be contract verbiage specifying that it actually provides that capacity in full. Your 1Gbit home connection probably doesn't have gigabit upstream. It might not even have b
Re: There are the obvious reasons (Score:3)
The price difference between commercial and residential ISP service is the difference between "dedicated" and "shared" bandwidth, as well as "service level commitment" and "best effort" bandwidth obligations.
I have a very reasonably-priced business account at my house, it allowed me to have 5 static IPs for just a few extra bucks/month.
Re: (Score:2)
Re: (Score:3)
Your home 1Gbit is actually a shared bandwidth with no guarantee of 1Gbit at any particular point in time, ISP, massively overprovision as that is the only way they can make those home connections affordable and most of the time you and others are only using a fraction of the available bandiwdth anyway. The corporate 100Mbit will be a true 100Mbit symmetrical connection all the time.
I believe this is true in the US, but it is not here in Norway. Actually, I can't say for sure that it isn't contractually true in some ways. It's possible they technically overprovision home users in that they would not be able to give _everyone_ a gigabit at the same time. On the other hand, if that is the case, then they only overprovision to the point where no one is actually able to notice. As in, even during extreme peaks they are still able to give everyone what they paid for. An ISP that did not sup
Re: (Score:2)
Re: (Score:2)
Re: There are the obvious reasons (Score:2)
It's interesting the point you make is more an issue with mail protocol. I agree the file is being multiplied like that but why was it designed this way? There is this amazing thing called a pointer. Now if all those staff forward it, that's a greater issue but the first email should not balloon like this.
Scale sucks (Score:2)
The difference is the individual versus the collective. The scale of cost and the scale of problems are unpleasant.
One individual can send a few large files. The individual knows that they are there, are only managing them on a machine with large storage and fast networking, and presumably they are removing them from the mail server storage when done.
This fails horribly at scale. When hundreds of people on a multi-thousand person server all start using it for multi-gigabyte archival storage, the cost goes
Re: There are the obvious reasons (Score:2)
When you send a 1 GB file to one person via email on your internal email server, it occupies 2 GB on the server - your sent folder and the recipient's inbox.
When you send a 1 GB video to 100 coworkers, it can take up to 101 GB of storage on the corporate email server (depending on how it is configured). Every time a recipient does a "reply all" commenting on the 1 GB attachment and forgets to not include the attachment, it takes up another 101 GB.
The real fun starts when you send multi-GB file attachments t
because email is deprecated generally (Score:3, Informative)
email exists mostly to keep a formal record (or at least define what a "formal record" is, since everything is just electricity/magnetism anyway) or to interact with external clients.
in your example, the professor was using email because it was the easiest and simplest thing he had that let him send a file and keep a record of it. the thing is, most places have a solution to that now; the standard protocol is to store the file wherever and then send a link, and, yes, this is actually an improvement over emailing ad-hoc chunks.
to answer your question: email became a stopgap solution to many things that are now solved differently, and it turns out that once those things are solved, you don't really need email attachments apart from a few corner cases which don't usually require ginormous send limits.
tl;dr: dropbox, slack, onedrive, google drive, etc. do what email attachments used to do, but better, so no one cares.
Re: (Score:2)
Is dropbox actually still around? Haven't onedrive and google drive been reducing their storage limits, lately?
Isn't it just a lot easier to just email an attachment? Does that somehow seem difficult to you? You drag and drop, and suddenly it's an awkward labeled base64 package that everyone knows how to encode, transmit, receive, and decode.
If you're complaining about bandwidth or drive space, grandpa, this is not 1980.
Re: (Score:2)
i'm referring to the business case, where the use limits are generally whatever the firm pays for.
easier to email an attachment: eh, kinda? it's about the same truth be told. but the problem with emailing attachments isn't, uh, emailing attachments; the problem is version control. everyone ends up with different versions of the file and no obvious way to reconcile them and this sucks. for this we have git (for programs) and document version tracking (for documents), and they are amazing tools.
i'm not compla
Re: (Score:2)
If you're complaining about bandwidth or drive space, grandpa, this is not 1980.
These are perfectly valid obstacles against large attachments.
Bandwidth and Drive space are Not and will never be free.
Large attachments are in fact HIGHLY inefficient in both these respects and operationally for mail servers - the Professor's argument of measuring efficiency is Bogus, since they considered Only their personal human efficiency in terms of their own unique personal workflow.
A 700 Megabyte email to 10 re
Re: (Score:2)
Do you recommend anything in particular for replacing attachments, particularly other than for files sent within a corporation? Should all major email clients implement all major file host services' upload protocols?
Re: (Score:2)
Do you recommend anything in particular for replacing attachments ..
It seems to have become customary for the email service provider to provide this alongside their email Offering, for example Microsoft Office365 / Outlook.com users get OneDrive and it's Integrated within Outlook so it gives the option to automatically upload and/or share the link directly from the Email software.
Google's Google Workspace / Gmail services do the same with Google Drive Integration.
The "attachment limitation" is b
Interacting with a half dozen or more APIs (Score:3)
Drop Box, One Drive, google storage, FTP, hell even SharePoint is a better method
I'm not yet fully convinced that it's practical for each maintainer of a desktop or mobile MUA* to maintain a developer account on each of Dropbox, OneDrive, Google Drive, SharePoint, S3, and whatever other service to which a user of the MUA happens to subscribe. I've also seen problems where the service's operator revokes the MUA's API key once the operator discovers that the API key has leaked to the public through the MUA's build configuration, which is part of a free MUA's complete corresponding source
Re:because email is deprecated generally (Score:5, Interesting)
How many of your options support Linux/VAX/IBM Mainframes? How many of your options are not run by companies that you should really not trust with your sensitive data?
From a user point of view, just attaching a file to an email is *still* the easiest and most 'logical' way. No matter what admins like us think about that.
Re: (Score:2)
Email is an excellent way to send information asynchronously, allowing for efficient multitasking, without having to talk or chat with people on demand. People who use email correctly can save tons of their time and other people's time. Those who use it poorly are doomed to recreated the same problems in the apps that replace it. Email has been declared obsolete and replaced with Teams and Slack, etc., which are basically just chat and phone, and now people ignore it as much as they did email, so I guess
Because of the design (Score:5, Informative)
Re: (Score:2)
Don't just think about back end infrastructure challenges. Those are solvable fairly easily.
Think about end user computers. If everyone is forwarding around gig email files, how much storage is going to be required on their computer? I have had many difficult executives and their assistants who refuse to delete email, ever, and who want every email from the dawn of time to be permanently accessible instantly from their computer - there is no time to wait for that 500 page deck to download from 5 years ago w
Re: (Score:2)
now do that with secure encrypted mailboxes.
Thank goodness! (Score:5, Insightful)
I think current limits are fine, given the push nature of email and how arbitrarily you can send a message to anyone (aka spam) without consent.
With cloud based storage taking over, attachments could almost be done with altogether, in favour of live/snapshot links. But that would be too draconian :-)
Because SPAM (Score:2, Interesting)
But not because spam is big. Private SMTP servers are basically not allowed anywhere on the internet, you MUST have an account at a well known service like gmail. And gmail is only free up to 15GB.
Re:Because SPAM (Score:4, Insightful)
Re: (Score:3)
Welcome to the world of IPv4 address reputation, where not even valid SPF, DKIM, and DMARC will keep a newly established mail server's messages from getting discarded.
Re: (Score:2)
And you haven't kept up to date. I've also run my own e-mail for about 25 years, and today hardly any major servers on the Internet will communicate with my bitty little e-mail sever, because they don't recognize me as a major corporation. As the years have gone by, more and more often, messages sent to me never show up, and messages I send never reach their destination and I never receive any bounce errors. There's no law that says anyone HAS to forward to your server, and... often they just don't.
Thank
Re: (Score:2)
Re: Because SPAM (Score:2)
Look at the question posed by this story. Any admin of any kind, or even a reasonable knowledgeable office worker can answer why this is a stupid idea.
Re: (Score:2)
> I guess I should shutdown my Prvate SMTP server
Deep breath. People are wrong on the Internet.
Anyone single-sourcing opinion online is going to have a bad time.
That said, a good postfix howto for fielding a new ip would be welcome.
And it's a minefield in 2022 to do mail right. Back in the 80's somebody would just hack up some m4 to keep up with reality and post it in a comp.* group. Now it'll take ten years and a committee.
Re: (Score:2)
Private SMTP servers are basically not allowed anywhere on the internet....
I have been running private email servers for about 16 years now. Initially it was on my DSL line, but there were ToS and other reasons I stopped doing that.
I rent a couple cheap private servers ($12/month each), and run Postfix on them. I have had no problems. The only reasons I have a gmail account are because I've had it since gmail was invitation-only (and I like being able to say that), and I use Google services that require a Google account. Nothing of importance goes through it. Otherwise I have no u
Re: (Score:2)
An SMTP server is an SMTP server. There is no such thing as a "Private SMTP Server".
Re: (Score:2)
iCloud's solution seems simple and elegant to me (Score:5, Informative)
Re: (Score:2)
Because clients are dumb. (Score:2)
Both email clients and the people that use them are dumb.
1. First of all, email clients generally download everything immediately when you check for mail. "But I use a webmail service" which means that service doesn't want to store your oversized emails indefinitely because you refuse to delete old email.
2. People are stupid and try to email video attachments of uncompressed audio/video files which clock in at 400MB/minute when the truth is that a highly compressed mpeg4 file could have done the job at a l
Re: (Score:2)
I think clever integration of "drop box" like file storage with a mail service could address most of the issues raised here.
In any case, for (1), if you have an overall mail box size limit, then it doesn't really matter if some emails are large. Large emails are probably stored more efficiently than many small emails anyway.
For (2), you could still allow a much larger limit, just not the typical 10-20MB. And also, your mail service could do that for you anyway, so you don't have to think about it.
Re: (Score:2)
I think clever integration of "drop box" like file storage with a mail service could address most of the issues raised here.
With how many brands of "'drop box' like file storage" must each mail client integrate?
BASE64 is the problem (Score:2)
Because of this BASE64 encoding the attachments are also mostly inseparable from the text email they are attached to. All this would be solved if there was a way to upload an attachment to a SMTP server separate to the email in binary format. On the recipient side it could be accessed by reference rather than as part of the message body.
Som
Re: (Score:2)
This is a case of those who refuse to learn from the mistakes of history are doomed to repeat them. None of those options are good, for a litany of reasons.
Push (Score:5, Interesting)
>"Why haven't they increased size limits for email attachments?"
Because Email isn't something you CHOOSE to receive. It really is that simple. As a sysadmin, you don't want to allow riffraff to push gigabytes of crap to all of your users. Not only could it potentially eat up all your bandwidth, but so many users care nothing about storage (and in the enterprise, secure and reliable/backed up storage can be costly). A single 500MB attachment sent to a great number of your users could chew up hundreds of GB of space. And users are notorious about never cleaning up their Email. And then there is spam...
Email is more about messaging, not file transfer. There are other services you can link the file to for which the Email is just the notification. Plus Email was never designed to be secure (and mostly still isn't).
Re:Push (Score:4, Informative)
>"Speaking of fax machines and spam (e)mail, if those still haven't died in 2022, wonder how long email will continue to hang around as a pointless burden?"
Like it or not, Email still has a LOT of value because it is:
1) Universal- it works for everyone on every platform. Most everyone has it, understands it, and can use it.
2) Standard- it is based on open and well-known standards
3) Flexible- can be used for smaller file transfer and messaging and you can control how you are notified or when you want to check it and how it is filtered. No real limits on message length.
4) Available- you can get service from so many places easily.
5) Changeable- It can be changed quickly and easily, especially if you have your own server.
6) Anonymous- Well, not completely, but it much more so than things tied to your phone or tied to some service that insists on identifying and tracking you. And it allows you to NOT give out things like a phone number.
7) Independent- you can set up your own services so you are completely in control if you wish.
8) Archiveable- easy to save, forward, store, print, index, search, transfer, etc.
9) Time conscious- There is no expectation or need to respond immediately. It doesn't demand immediate attention and interrupt work. It allows for a better and more thoughtful response on your own schedule.
I have yet to see anything that can replace Email for all that Email does. I am not about to sign up for some carrier service that locks me to a platform, or give out my personal cell number. So although it is far from perfect, it is extremely valuable/useful.
Personally, I find things like texting (SMS or similar IM technology) extraordinarily annoying and invasive, other than things that really need to be real-time or near-real-time (for which is is very useful).
Re: (Score:2)
storage (Score:2)
Because you'll start sending everything through email, and you will never delete any of it. The storage demands will be ever growing for historical things you'll never look at again.
What is reasonable? What if your mailbox was limited to 10G, and the biggest email you could send was 10G, but that would fill up your mailbox all at once? How long do you expect it to take to send your 10G email?
I have a coworker with a 50G active mailbox. She has about another 80G in older archived mail. She keeps everything
Re: (Score:2)
And all of those attachments are now stored in both email and in file systems outside of email. Email is not a backup system.
Re: storage (Score:3)
For that matter, the original question is like asking why residential mailboxes aren't all the size of a warehouse so you can just drop pallets off at any address.
fucking obvious (Score:3)
Re: fucking obvious (Score:2)
We get large enough dumb signature already (Score:2)
Seriously, half my organization put a company logo at the end of their emails. That logo is 3MB large. They send email invitation to event as 15MB jpg. Don't give them more power to do stupid things!
Re: (Score:2)
To: original sender
Cc: original recipients
Subject: Re: something everyone on this list should know about
Please take me off this mailing list. Thanks
[another 3MB jpeg logo]
> hey here's something everyone on this mailing list should know about!
> [original 3MB jpeg logo that went out to everyone]
Because email is so inefficient (Score:2, Interesting)
1. Encoding is crap. For legacy compatibility reasons the best email attachment encoding available is base64, where each 3 bytes block of source data gets converted to 4 characters, so suddenly your 700MB attachment is 931MB of MIME encoded email data.
2. There's no de-duplication. If you send an email to all@example.com then suddenly the 1,000 or so mailboxes residing at example.com each have their own copy of your 931MB email, causing a sudden 931GB jump in mail storage utilization.
3. Because email isn't s
Very simple (Score:3)
As someone who has had to manage these things, I can give you a very simple answer:
Our email server is not your personal file server. When large file attachments are allowed, people use email to do all their file transferring, which consumes a staggaring of storage space AND network.
And of course they won't delete those emails afterwards, and then when people's quotas fill up they tear help desk a new one for preventing them from doing what they "paid for" and demand larger quotas.
Email is for exactly that: Email.
If you want to transfer large files, there are a bajillion systems you can use as an alternative.
Attachments where a hack (Score:3)
Slashdot's quality is really dropping these days. Email attachments were a hack that were never part of the original spec. You literally take binary data and encode it as text (which takes up more space than the original binary file) so it can piggyback on the email. We used to have problems all the time with large email attachments failing to send and backing up users outboxes. Come on, this is basic stuff, people!
OBXKCD (Score:2)
GMail doesn't even bother (Score:2)
GMail doesn't even bother and sends you to Google Drive when trying to send files larger than 20 megabytes, even on Google Workspace/G Suite.
What is this, 1998?
I doubt this guy has ever run a server (Score:2)
I've seen just how bogged down a mail server can get when someone sends even a 20MB attachment to all 1000+ people who have a departmental email account...
Ask again... (Score:2)
... after a mad spam gang with a large botnet Joe-Jobs you with messages carrying huge attachments.
Why don't email clients support modern HTML? (Score:2)
This is the real question. Outlook is based on the IE 6 browser engine, and even then is was bastardized. Email should support a subset of HTML5 with CSS3 to allow for proper responsive design and modern layouts.
Large attachments I can do without. I'd much rather just add the file to my drive instead of having to download the file, then just move it back to the cloud.
"They?" (Score:3)
Not everyone has fast, unlimited internet (Score:2)
Living in a rural area, I have internet limitations. My satellite internet has a 10 GB/month data cap. My crappy wireless internet runs at 3 megabits/second maximum. If someone sent a large file to me, it'd work against my data cap or with my other internet service, it'd take hours to download.
We don't all live in a city with a fast internet infrastructure.
(FWIW, I'e been on the Starlink waiting list for about a year and it may take another one before I even get close to having it)
Ask the lawyers (Score:2)
Re:Email is not a file transfer service (Score:4, Informative)
Sending attachments in the mail has never been better than a shoddy stop-gap.
Bullshit. There is nothing wrong with attachments.
Re: Email is not a file transfer service (Score:3)
Re:Email is easy to DDOS (Score:5, Funny)
Many years ago, in the early days of spam, I decided to get back at a spammer by sending a hundred copies of an e-mail with a 10 MB GIF attached saying "Stop spamming me!". I figured that would clog his account and seriously annoy him.
Then they all came back as undeliverable e-mail, with the attachment included...
Re:SMTP is not a file transfer protocol (Score:4, Funny)
SMTP is not a file transfer protocol. That's why.
Of course it is! Why else would it be called Simple Multimegabytefile Transfer Protocol?
Re: Email is not a file transfer service (Score:5, Interesting)
Attachments are uuencoded, increasing their size considerably, and people's penchant for sending large images attachments to multiple recipients will only further clog mail servers and users accounts.
Are file-sharing services really that troublesome?
Re: (Score:3)
Re: Email is not a file transfer service (Score:5, Informative)
Attachments haven't generally been uuencoded in something like 30 years now. Attachments are base64 encoded nowadays, which is similar to uuencoeding but uses a different charset (the base64 charset is compatible with more 7 bit charsets than uuencoding is).
Base64 (and I believe uuencode) requires four ASCII characters to represent 24 bits of binary data, on an 8 bit system that results in a size increase of 33% ovet the original binary file. While this is significant, I would tend to agree that with the much larger storage capacities available to servers nowadays, an increase over the typical 10M size limit is warranted. The problem, however, is more one of momentum than it is one of server capacity. Basically put, there are a lot of servers that still limit the size to 10M and as such if you have a server that accepts a message larger than that, then attempt to relay it to a server that has that limit, the message bounces and you must then send a bounce message back to the sender. In some cases this can turn your server into a potential source of backscatter [wikipedia.org]. Also most MTA software comes with a limit of 10M set by default, and many admins either don't see a good reason to change this, or don't care, or know any better.
Re: Email is not a file transfer service (Score:2)
Now you have Onedrive. So I'd expect M$ to remove attachments from mail soon.
That way they can scan and collect all your data and hand it to any three letter agency even if it's not in your home country.
Re:Email is not a file transfer service (Score:4, Insightful)
As someone who has implemented e-mail clients and servers over the years, I'll tell you that e-mail is irreparably broken, at this point, we've added enough bandages on it through decades of triage that it's somewhat useable in its current state and thanks to pure f-ing magic, we managed to make it look pretty darn good... but at its heart it's a steaming piece of doo doo.
Yes, large attachments are useful. But suppose people were to send entire 4GB movies through their e-mail. Every single SMTP server along the path would have to invest in receiving, storing, virus scanning, and forwarding of that file.
That may sound like no big deal, but most countries actually have actual legal requirements of e-mail archival for some period of time.
Then there's the deduplication issue, mail servers don't disassemble mail messages when storing them. So, a mail server will actually leave the message in tact and since almost all mail is transferred in 7-bit friendly formats such as MIME/64, that adds a minimum of a 1/7th overhead to the size of the mail and more than likely a 1/6th overhead and that's just in its stored form, not including additional headers for transfer.
And this may not sound like such a big deal, but if a 4gig file were to go viral through e-mail, and they would... then we would be forced to store, by law, unaltered mails of approximately 5GB of size all over the Internet. And as I said, it can't be deduplicated because it's stored unaltered in the message itself.
Maybe we should addresses error management.
SMTP IS NOT a protocol with any data authentication, error detection, error correction, etc... it's 100% dependent on TCP which in itself has terrible integrity.
I can go on... but yes, you're right... from a purely technical perspective, sending a 1MB file or a 4000MB file via e-mail, other than just being precisely the wrong system to transmit large files is entirely capable of transferring large files on at least the 3rd or 4th try.
But from a practical perspective, it's a damn stupid means of transporting large files and simply shouldn't be depended on. e-mails can contain links. That should be good enough.
Re: (Score:3)
You are talking like the new inexperienced guy with "not invented by my generation" mindset.
You are wrong by many aspects:
If one first recognizes that Internet e-mail is an antique that we're basically stuck with, that's a start.
Email is as old as the internet, and started slightly earlier. Do you feel stuck in an antique internet?
As someone who has implemented e-mail clients and servers over the years, I'll tell you that e-mail is irreparably broken, at this point, we've added enough bandages on it through decades of triage that it's somewhat useable in its current state and thanks to pure f-ing magic, we managed to make it look pretty darn good... but at its heart it's a steaming piece of doo doo.
These are baseless rants. Email is exactly mirroring the way standard mail is handled. This is the most efficient, reliable and meaningful way to do it.
And this may not sound like such a big deal, but if a 4gig file were to go viral through e-mail, and they would... then we would be forced to store, by law, unaltered mails of approximately 5GB of size all over the Internet. And as I said, it can't be deduplicated because it's stored unaltered in the message itself.
This is why bulk email is bad
Data Integrity and TCP (Score:3)
it's 100% dependent on TCP which in itself has terrible integrity.
Eh? Every packet in a TCP stream includes a checksum. It's not completely foolproof, but it's pretty darn good. When's the last time you ever had a file corrupted during transmission because of an undetected error in TCP transmission? I don't recall this ever being an issue.
Re:Email is not a file transfer service (Score:4, Funny)
What could possibly go wrong?
Re:Email is not a file transfer service (Score:5, Informative)
You.. Must be young.
Because "Email" was literally THE method of file transfer back in the early 80's.
You'd send a message to a central repository server requesting a specific file, which would then be sent to you (sometimes days later, depending) in a message.
It's where uuencode comes from, and it was partially inherited by Usenet.
(And yes, that's all extremely simplified, I don't care to go the numerous 70's and 80's datanets, FIDO, and god knows what)
Re: Email is not a file transfer service (Score:2)
Early 80s? Email was used a lot, yes, ftp by email was widespread wherever ftp was blocked.
Re: (Score:3, Insightful)
Re: (Score:2)
10 GB would only allow for 14 large attachments as described in the summary. And since most mail clients don't allow easily culling attachments from old emails, there this can cause a problem for people who want to keep all their important emails but don't want to use a large amount of space.
My point is that it's a usability problem, but not for the sender.
Mozilla Thunderbird can help (Score:2)
Speaking of which, not everybody knows that Thunderbird allows you to delete attachments in received emails. It also allows you to detach the attachment and store a local copy of the attachment on your machine, where you can either update it, resize it, or compress it and the link to the email remains.
I receive PDF files for a group I volunteer for. The senders don't know about reducing the size of PDFs so I detach the attachment and reduce the size by about 60%. This also works for the users that send 1
Re: (Score:2)
"All my sent and received email, more than 20 years worth, and many with very large attachments are stored locally and take up less than 10 GB"
That's about 1 years worth of email for any random sales rep working for my corporate overlords. They store 2 years worth of email within exchange, archive the rest going back 7. Sales reps cover a LOT of different types of media for review. Our exchange group hate working on their email problems because exchange can suck when the profile is bigger than 10 GB.
Som
Re: (Score:2)
The "Tesla" litters the "road" with broken quotes...
Re: (Score:3)
Do you need help? Did you forget to take your medicines? You seem angry for some reason.
"Nobody was sending email". And then you list some institutions that do where your BBS comment is about as relevant as your anger.
There we also plenty of BBS portals that were nothing but a gateway into those networks used by those institutions you so happily discounted as apparently not important.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
And once again, the problem is not e-mail attachments, it is stupid, short-sighted management.
Re: I missed email from the late 1990s... (Score:2)
That adds up to 6 GB of storage, once upon a time that was a lot of money, but today when an 8 TB SATA drive sells for $150-200 retail, it is little more than an example of "penny-smart, pound-foolish."
Re: (Score:2)
Re: (Score:2)
You just admitted linking to child porn, have fun in prison.
Oh, except you are a liar.
Re: (Score:2)
my punch cards beat your floppy disks.
Re: (Score:2)
ugh, I was swapping 8KB EEPROMs today, I wish that machine supported disks.
Re: (Score:2)
Having any cloud storage (even garbage ones), a link can be sent instead of an attachment
Watch half of your sent links result in replies to the effect "I'm sorry I missed downloading the attachment before it expired from the server; please resend."
Re: (Score:2)
and that 700MB attachment takes 960MB to encode, what's this "efficient" they're talking about in article.
The usual limit in most companies is about 100MB, and anyone asking for 700MB should be ax murdered. Wrong transfer mechanism for the job, set up sftp server.
Re: (Score:2)
oh it's just one file, drost.zip