Re: Resuming a failed mail transfer
Michael Tinsay <tinsami1-/[email protected]> Mon, 25 Jul 2016 10:54:49 +0000 (UTC)
| Newsgroups | gmane.org.user-groups.linux.philippine |
|---|---|
| Message-ID | <[email protected]> |
--===============3983839446890498617==
Content-Type: multipart/alternative;
boundary="----=_Part_4854361_344330995.1469444089895"
------=_Part_4854361_344330995.1469444089895
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Obet,=C2=A0
Nobody is thinking of improving SMTP anymore. =C2=A0They are busy building =
"the next big thing" in their very own walled garden. =C2=A0And trying to i=
mprove SMTP and getting all the players to support the improvement is gonna=
be a major pain. =C2=A0There are alternatives... they may be more tedious =
from your POV, but at least they are there. =C2=A0Just go with the alternat=
ive you find acceptable.
--- mike t.
From: Roberto Verzola <[email protected]>
To: [email protected]=20
Sent: Saturday, 23 July 2016, 16:06
Subject: Re: [plug] Resuming a failed mail transfer
=20
> there was never a=C2=A0 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 alw=
ays been about partially delivered files. And not just between users within=
the same machine but between users of different machines using different O=
S even. The different packets that make up the entire file take different r=
outes 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 p=
rotocols. And the solution is so simple, and has existed for such a long ti=
me, that I truly wonder if it has not been incorporated in some mail transf=
er protocol or another that we just have not heard of.
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 th=
en
> > > just email the URL. Most FTP servers, and cloud storage, services lik=
e
> > > 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 proces=
s.
> Or am I expecting too much?
>=20
> Yeah you are.
>=20
> 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.
>=20
> Email historically came from the mail systems from inside a multi-user
> machine, which worked under the assumption that mailbox files were writte=
n
> atomically and quickly with relatively short, text-based messages. Thus
> there was never a=C2=A0 notion of a partially delivered message, nor one =
that
> could be resumed.
>=20
> Furthermore more reliable file transfer was always available throughout t=
he
> 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 woul=
d
> be trivial to dos a server or user that arbitrarily accepted large files,
> like email does)
>=20
> 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. Mai=
l
> has historically always relied on other file sharing methods.
--=20
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
------=_Part_4854361_344330995.1469444089895
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head></head><body><div style=3D"color:#000; background-color:#fff; f=
ont-family:Courier New, courier, monaco, monospace, sans-serif;font-size:10=
px"><div id=3D"yui_3_16_0_ym19_1_1469442827241_51981"><span>Obet, </sp=
an></div><div id=3D"yui_3_16_0_ym19_1_1469442827241_51981"><span><br></span=
></div><div id=3D"yui_3_16_0_ym19_1_1469442827241_51981" dir=3D"ltr"><span =
id=3D"yui_3_16_0_ym19_1_1469442827241_52456">Nobody is thinking of improvin=
g SMTP anymore. They are busy building "the next big thing" in their =
very own walled garden. And trying to improve SMTP and getting all th=
e 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 th=
ey are there. Just go with the alternative you find acceptable.</span=
></div><div id=3D"yui_3_16_0_ym19_1_1469442827241_51981" dir=3D"ltr"><span>=
<br></span></div><div id=3D"yui_3_16_0_ym19_1_1469442827241_51981" dir=3D"l=
tr"><span><br></span></div><div id=3D"yui_3_16_0_ym19_1_1469442827241_51981=
" dir=3D"ltr"><span>--- mike t.</span></div><div class=3D"qtdSeparateBR" id=
=3D"yui_3_16_0_ym19_1_1469442827241_52455"><br><br></div><div class=3D"yaho=
o_quoted" id=3D"yui_3_16_0_ym19_1_1469442827241_51986" style=3D"display: bl=
ock;"> <div style=3D"font-family: Courier New, courier, monaco, monospace,=
sans-serif; font-size: 10px;" id=3D"yui_3_16_0_ym19_1_1469442827241_51985"=
> <div style=3D"font-family: HelveticaNeue, Helvetica Neue, Helvetica, Aria=
l, Lucida Grande, Sans-Serif; font-size: 16px;" id=3D"yui_3_16_0_ym19_1_146=
9442827241_51984"> <div dir=3D"ltr" id=3D"yui_3_16_0_ym19_1_1469442827241_5=
1983"> <font size=3D"2" face=3D"Arial" id=3D"yui_3_16_0_ym19_1_146944282724=
1_51982"> <hr size=3D"1" id=3D"yui_3_16_0_ym19_1_1469442827241_52454"> <b><=
span style=3D"font-weight:bold;">From:</span></b> Roberto Verzola <rverz=
[email protected]><br> <b id=3D"yui_3_16_0_ym19_1_1469442827241_52534"><spa=
n style=3D"font-weight: bold;" id=3D"yui_3_16_0_ym19_1_1469442827241_52533"=
>To:</span></b> [email protected] <br> <b><span style=3D"font-weight:=
bold;">Sent:</span></b> Saturday, 23 July 2016, 16:06<br> <b id=3D"yui_3_1=
6_0_ym19_1_1469442827241_52536"><span style=3D"font-weight: bold;" id=3D"yu=
i_3_16_0_ym19_1_1469442827241_52535">Subject:</span></b> Re: [plug] Resumin=
g a failed mail transfer<br> </font> </div> <div class=3D"y_msg_container" =
id=3D"yui_3_16_0_ym19_1_1469442827241_51987"><br>> there was never a&nbs=
p; notion of a partially delivered message, nor one that<br clear=3D"none">=
> could be resumed.<br clear=3D"none"><br clear=3D"none">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 machi=
ne but between users of different machines using different OS even. The dif=
ferent packets that make up the entire file take different routes to be gra=
dually assembled at the destination. Whether it is a big or a small file, r=
etries have always been, at some level or another, a part of Internet proto=
cols, because slow connections have always been part of the Internet. Inter=
net protocols keep improving too, or get replaced by newer protocols. And t=
he solution is so simple, and has existed for such a long time, that I trul=
y wonder if it has not been incorporated in some mail transfer protocol or =
another that we just have not heard of.<br clear=3D"none"><br clear=3D"none=
">Greetings,<br clear=3D"none"><br clear=3D"none">Obet<br clear=3D"none"><b=
r clear=3D"none">On Sat, 23 Jul 2016 15:26:40 +0800<br clear=3D"none">Mark =
David Dumlao <<a shape=3D"rect" ymailto=3D"mailto:[email protected]" hr=
ef=3D"mailto:[email protected]">[email protected]</a>> wrote:<br clear=
=3D"none"><br clear=3D"none">> On Jul 21, 2016 18:35, "Roberto Verzola" =
<<a shape=3D"rect" ymailto=3D"mailto:[email protected]" href=3D"mailto=
:[email protected]">[email protected]</a>> wrote:<br clear=3D"none">=
> ><br clear=3D"none">> > > Why not just upload the file som=
ewhere that supports upload resume then<br clear=3D"none">> > > ju=
st email the URL. Most FTP servers, and cloud storage, services like<br cle=
ar=3D"none">> > > Dropbox or Google Drive, supports resuming of in=
terrupted transfers.<br clear=3D"none">> ><br clear=3D"none">> >=
; Maybe, but that is too much work, especially if the problem occurs<br cle=
ar=3D"none">> regularly because you have a slow connection. Email with a=
ttachments is<br clear=3D"none">> such a universal Internet event that I=
expect by this time that such<br clear=3D"none">> 30-year (at least!) o=
ld technology as resumed file transfers would have<br clear=3D"none">> f=
ound their way and become part (transparent and automatic) of the process.<=
br clear=3D"none">> Or am I expecting too much?<br clear=3D"none">> <=
br clear=3D"none">> Yeah you are.<br clear=3D"none">> <br clear=3D"no=
ne">> Regardless of what theyre used for today, some network protocols w=
ere<br clear=3D"none">> designed for something else entirely and enhance=
ments to those protocols<br clear=3D"none">> tended to stick within the =
limitations of those designs.<br clear=3D"none">> <br clear=3D"none">>=
; Email historically came from the mail systems from inside a multi-user<br=
clear=3D"none">> machine, which worked under the assumption that mailbo=
x files were written<br clear=3D"none">> atomically and quickly with rel=
atively short, text-based messages. Thus<br clear=3D"none">> there was n=
ever a notion of a partially delivered message, nor one that<br clear=
=3D"none">> could be resumed.<br clear=3D"none">> <br clear=3D"none">=
> Furthermore more reliable file transfer was always available throughou=
t the<br clear=3D"none">> history of mail protocols. In intra-host mail,=
the fact that you shared a<br clear=3D"none">> filesystem meant that th=
ere was no point to duplicating the files. In<br clear=3D"none">> host-t=
o-host mail, other methods for serving and transferring files were<br clear=
=3D"none">> always around. And many mailservers simply had attachment si=
ze limits and<br clear=3D"none">> the like so large attachments never go=
t a serious consideration. (it would<br clear=3D"none">> be trivial to d=
os a server or user that arbitrarily accepted large files,<br clear=3D"none=
">> like email does)<br clear=3D"none">> <br clear=3D"none">> So t=
ldr: the reality is that email was never intended for heavy file<br clear=
=3D"none">> transfers and that is unlikely to change any time in the nea=
r future. Mail<br clear=3D"none">> has historically always relied on oth=
er file sharing methods.<div class=3D"yqt6970806912" id=3D"yqtfd26602"><br =
clear=3D"none"><br clear=3D"none"><br clear=3D"none">-- <br clear=3D"none">=
Roberto Verzola <<a shape=3D"rect" ymailto=3D"mailto:[email protected]=
" href=3D"mailto:[email protected]">[email protected]</a>><br clear=
=3D"none">_________________________________________________<br clear=3D"non=
e">Philippine Linux Users' Group (PLUG) Mailing List<br clear=3D"none"><a s=
hape=3D"rect" href=3D"http://lists.linux.org.ph/mailman/listinfo/plug" targ=
et=3D"_blank">http://lists.linux.org.ph/mailman/listinfo/plug</a><br clear=
=3D"none">Searchable Archives: <a shape=3D"rect" href=3D"http://archives.fr=
ee.net.ph/" target=3D"_blank">http://archives.free.net.ph</a><br clear=3D"n=
one"></div><br><br></div> </div> </div> </div></div></body></html>
------=_Part_4854361_344330995.1469444089895--
--===============3983839446890498617==
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
--===============3983839446890498617==--