> - no compression build in
who cares? PDF, JPG, ZIP are already compressed and I don't see any real need to compress other small files.
> - converts the 8bit to 7bit, usually by base64, actually increasing the file size by a good percentage
>- the emails are many times stored in the plain text format, so also waste disk in both in the local sent and remote inbox
Again, who cares about 20% overhead in the age of the Websites preloading Javascript-Code in the 100MByte range for a simple Guest Book?
> - no dedupe, so you end with the same file multiple times, even worse because emails clients today like to quote everything and keeping all attaches when replying
Honestly I do not know any relevant communication protocol having effectivve deduplication.
> - the smtp server tries to send, but the other side may not accept that big file, ending being rejected and bounce back to the user
Which is a simple act of sending an envelope with some hundred bytes of data. No resources wasted in current All-in-Connect-SMTP-enviroment. Back when mail was actually routed that was really bad but nowadays it just means the server in the next room tells youo after a second it can not send the data.
> there is no valid standard for that max size, the old unofficial standard was 10mb, but each server can use whatever they want... but others may choose a different value, so it is not reliable to increase it
True. But name one alternative which does this better. At least it leaves the choice to the administrator.
> - if the remote server timeouts, gets out of disk space, whatever, the all email will be re-transmitted, there is no resume, no fallback... so yes, i already seem many times huge emails timeout day after day and waste a huge amount of bandwidth
Honestly, in 30 years of using email I haven't seen this more than once or twice. And Email was my mail business.
> - the same for receiving, pop3 or imap, you have basically the same problems... cloud email is https for the client, but still stores the email in the 7bit expanded version and still have not deduplication nor compression (at least for the user quota, the backend may really have some tricks hidden)
Are there really any Webmailers transmitting the binary data in base64 over HTTP? Doesn't make any sense at all.
> - if you send a 200MB file to 200 persons, you will in worse case transfer that file 200 times too
Actually: No. Carbon-Copy transfers copies in a very efficient way, basically only sending it once per target domain and in case of routed SMTP maybe even only one copy for several domains, no matter how many people are inside those domains.
> - again, it is almost impossible to change the smtp, you have a huge amount of old servers that will never change their config or software versions, and so break any attempt to fix the issue
SMTP alias the MTA is very easy to expand. Only the MUAs tend to be a big pile of crap, especially if they are from Microsoft. Using MIME you could do all sorts of shit but eg Outlook, mostly Outlook tbh, simply says "fuck you" to standards.
> So this compared with something like a webdav, that is basically a https file share, 8bit native and that can be access by browser OR mounted by all OS, just
> like a USB driver, well, smtp is a bad way to transfer files, it is much better to send a email with the webdav or cloud storage url than to attach the file
WebDAV is as much an alternative to SMTP as the London Speakers Corner is an Alternative to a drivers licence.
>you may say that bandwidth is not a problem, but not all people have high speed internet connection and again, everything compared with something like https download, webdav or cloud storage, email is still a bad way to transfer files
Well, we are talking about 20% overhead at best. Even Slashdot loads like 15MBytes of useless Javascript-Crap for EVERY SINGLE Page. I won't care if my JPGs grow by 0,5MByte in an email therefore.