On Jul 24, 2016 6:04 PM, "Roberto Verzola" <[email protected]> wrote: > > > there was never a notion of a partially delivered message, nor one that > > could be resumed. > > I find it hard to believe this one. The Internet from the beginning has always been about partially delivered files.
Not only is there no "single" coherent Internet design (the network protocols comprising different parts of what we recognize as tne Internet often have conflicting and overlapping goals and responsiblities) but mail - as in the intrahost messaging system - preceded the Internet. It was barely syntax sugar over appending text to a shared file - the existence of which meant that you were already sharing files reliably. So message resume was just not factored into the design. And to add a "simple" feature as resume takes more work than you might think. it would require, for instance, indexing all the incompatible mailbox formats with reliable, non-repeatable ids. SMTP - client-side - would have to be overhauled to reliably send message sizes or wait for application-layer ACKs to message chunks (messages arent chunked right now) in a time when we can barely trust outlook not to mangle MIME. And then theres defining what to do in the case of multiple redundent relay servers - who stores the incomplete message? the server that happened to be roundrobined that minute or an authoritative sender or the ultimate receiver? Or multiple levels of smarthosts / relay servers which are all user-transparent... what happens when transmission needs to be resumed at an intermediary? Can (or should) users read partial messages? What happens if a partial message is updated while reading? How do MIME attachments get chunked? Is there a checksum mechanism? How do you deal with brute force message injections (smtp is largely unauthenticated at the receiving end - hence why spam works)? etc... No doubt a decent programmer can make clean room designs to the questions above - which is probably why we have a hundred different messaging protocols - but thats because we have the luxury of thinking about the problem after years of real world testing. They simply were never factored into email protocols and its not easy to add them in now. > > Greetings, > > Obet > > On Sat, 23 Jul 2016 15:26:40 +0800 > Mark David Dumlao <[email protected]> wrote: > > > On Jul 21, 2016 18:35, "Roberto Verzola" <[email protected]> wrote: > > > > > > > Why not just upload the file somewhere that supports upload resume then > > > > just email the URL. Most FTP servers, and cloud storage, services like > > > > Dropbox or Google Drive, supports resuming of interrupted transfers. > > > > > > Maybe, but that is too much work, especially if the problem occurs > > regularly because you have a slow connection. Email with attachments is > > such a universal Internet event that I expect by this time that such > > 30-year (at least!) old technology as resumed file transfers would have > > found their way and become part (transparent and automatic) of the process. > > Or am I expecting too much? > > > > Yeah you are. > > > > Regardless of what theyre used for today, some network protocols were > > designed for something else entirely and enhancements to those protocols > > tended to stick within the limitations of those designs. > > > > Email historically came from the mail systems from inside a multi-user > > machine, which worked under the assumption that mailbox files were written > > atomically and quickly with relatively short, text-based messages. Thus > > there was never a notion of a partially delivered message, nor one that > > could be resumed. > > > > Furthermore more reliable file transfer was always available throughout the > > history of mail protocols. In intra-host mail, the fact that you shared a > > filesystem meant that there was no point to duplicating the files. In > > host-to-host mail, other methods for serving and transferring files were > > always around. And many mailservers simply had attachment size limits and > > the like so large attachments never got a serious consideration. (it would > > be trivial to dos a server or user that arbitrarily accepted large files, > > like email does) > > > > So tldr: the reality is that email was never intended for heavy file > > transfers and that is unlikely to change any time in the near future. Mail > > has historically always relied on other file sharing methods. > > > -- > Roberto Verzola <[email protected]> > _________________________________________________ > Philippine Linux Users' Group (PLUG) Mailing List > http://lists.linux.org.ph/mailman/listinfo/plug > Searchable Archives: http://archives.free.net.ph
_________________________________________________ Philippine Linux Users' Group (PLUG) Mailing List http://lists.linux.org.ph/mailman/listinfo/plug Searchable Archives: http://archives.free.net.ph
