3 ms·

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 pri

by 542458 10y ago

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.

zeveb 10y ago
> 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.
- u801e 10y ago
  > 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 https://tools.ietf.org/html/rfc5321 [2] http://www.yenc.org/yenc-draft.1.3.txt http://www.yenc.org/yenc-draft.1.3.txt
  - tinus_hn 10y ago
    > We really shouldn't have to use an encoding scheme that has that kind of overhead. But we do.

by 542458 10y ago

zeveb 10y ago

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

u801e 10y ago
> 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 https://tools.ietf.org/html/rfc5321 [2] http://www.yenc.org/yenc-draft.1.3.txt http://www.yenc.org/yenc-draft.1.3.txt
- tinus_hn 10y ago
  > We really shouldn't have to use an encoding scheme that has that kind of overhead. But we do.