Re: Resuming a failed mail transfer

--===============7083505858518318551==
Content-Type: multipart/alternative; boundary=001a1140e9ece0f01e053848784c

--001a1140e9ece0f01e053848784c
Content-Type: text/plain; charset=UTF-8

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.

--001a1140e9ece0f01e053848784c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">On Jul 21, 2016 18:35, &quot;Roberto Verzola&quot; &lt;<a hr=
ef=3D"mailto:[email protected]">[email protected]</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; Why not just upload the file somewhere that supports upload resum=
e then<br>
&gt; &gt; just email the URL. Most FTP servers, and cloud storage, services=
 like<br>
&gt; &gt; Dropbox or Google Drive, supports resuming of interrupted transfe=
rs.<br>
&gt;<br>
&gt; Maybe, but that is too much work, especially if the problem occurs reg=
ularly 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 expect=
ing too much?</p>
<p dir=3D"ltr">Yeah you are.</p>
<p dir=3D"ltr">Regardless of what theyre used for today, some network proto=
cols were designed for something else entirely and enhancements to those pr=
otocols tended to stick within the limitations of those designs.</p>
<p dir=3D"ltr">Email historically came from the mail systems from inside a =
multi-user machine, which worked under the assumption that mailbox files we=
re written atomically and quickly with relatively short, text-based message=
s. Thus there was never a=C2=A0 notion of a partially delivered message, no=
r one that could be resumed.</p>
<p dir=3D"ltr">Furthermore more reliable file transfer was always available=
 throughout the history of mail protocols. In intra-host mail, the fact tha=
t 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 fil=
es were always around. And many mailservers simply had attachment size limi=
ts 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 f=
iles, like email does)</p>
<p dir=3D"ltr">So tldr: the reality is that email was never intended for he=
avy file transfers and that is unlikely to change any time in the near futu=
re. Mail has historically always relied on other file sharing methods.</p>

--001a1140e9ece0f01e053848784c--

--===============7083505858518318551==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_________________________________________________
Philippine Linux Users' Group (PLUG) Mailing List
http://lists.linux.org.ph/mailman/listinfo/plug
Searchable Archives: http://archives.free.net.ph
--===============7083505858518318551==--