Obet,
Nobody is thinking of improving SMTP anymore. They are busy building "the next
big thing" in their very own walled garden. And trying to improve SMTP and
getting all the players to support the improvement is gonna be a major pain.
There are alternatives... they may be more tedious from your POV, but at least
they are there. Just go with the alternative you find acceptable.
--- mike t.
From: Roberto Verzola <rverz...@gn.apc.org>
To: plug@lists.linux.org.ph
Sent: Saturday, 23 July 2016, 16:06
Subject: Re: [plug] Resuming a failed mail transfer
> 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. And not just between users within the
same machine but between users of different machines using different OS even.
The different packets that make up the entire file take different routes to be
gradually assembled at the destination. Whether it is a big or a small file,
retries have always been, at some level or another, a part of Internet
protocols, because slow connections have always been part of the Internet.
Internet protocols keep improving too, or get replaced by newer protocols. And
the solution is so simple, and has existed for such a long time, that I truly
wonder if it has not been incorporated in some mail transfer protocol or
another that we just have not heard of.
Greetings,
Obet
On Sat, 23 Jul 2016 15:26:40 +0800
Mark David Dumlao <madum...@gmail.com> wrote:
> On Jul 21, 2016 18:35, "Roberto Verzola" <rverz...@gn.apc.org> 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 <rverz...@gn.apc.org>
_________________________________________________
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
