<html><head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head><body bgcolor="#FFFFFF" text="#000000">
<div>> We have an in-house (but publicly visible) file transfer 
service (a
 corporate drop-box, if you will).  Because apparently 
uploading/downloading from this service uses significantly less 
bandwidth than it would use to transfer the file via email, and the disk
 space on the server dedicated to this <br>
service is much cheaper than mail
 server storage.  And maintaining two systems is easier and cheaper than
 maintaining one.<br>
  <br>
Go have a look at your netflow logs and tell me how much bandwidth SMTP 
traffic *actually* accounts for. I would wager it's probably less than 
your windows update traffic :).<br>
It's also worth noting that an envelope size limit here doesn't prevent 
bandwidth waste from the customer end anyway, they send you the entire 
envelope BEFORE you can tell them it's too big and tell them to sod off.
 Repeat this 5 times while the customer tries to rezip/recompress or 
just sends it again because they don't understand your bounce message.<br>
</div>
<br>
<br>
<span>Robert Hudson wrote:</span><br>
<blockquote 
cite="mid:CAOu9xN+b766AXUm3hG0QTO6RLappdvkdhFQ-=9Z5xvb_4qo7Tw@mail.gmail.com"
 type="cite">
  <div dir="ltr"><br><div class="gmail_extra"><br><div 
class="gmail_quote">On 26 November 2015 at 13:25, Mark Newton <span 
dir="ltr"><<a moz-do-not-send="true" 
href="mailto:newton@atdot.dotat.org" target="_blank">newton@atdot.dotat.org</a>></span>
 wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Nov 
26, 2015, at 1:10 PM, Ross Wheeler <<a moz-do-not-send="true" 
href="mailto:ausnog@rossw.net">ausnog@rossw.net</a>> wrote:<br>
> I know email is being constantly asked to take ongoing abuse and to
 become the defacto file-transport-and-archive system of choice, 
particularly by the technically incompetent, but how far does it go?<br>
<br>
</span>It goes to where the users demand.<br>
<br>
There’s no specific reason why email can’t be a defacto 
file-transport-and-archive system of choice. It’s carried by TCP just 
like every other file-transport-and-archive system, and everyone has 
clients for it. If the users want to use it for that, what’s wrong with 
it?<br>
<span class=""><br>
> Case in point: earlier this week, I had a call from a customer 
"needing" me to increase our mail size. (I thought we were 'reasonably 
generous' in current global terms, at 16MB per message). I asked what he
 considered it needed to be, his response was that "right now" he needs 
50-60MB, but that he thought it shouldn't have any limit - but if it had
 to, that 300-500MB per message would "probably do for now”.<br>
<br>
</span>Go back to the question, “Why does the limit exist?”<br>
<br>
SMTP servers used to have the limit because large files took a long time
 to send, bandwidth was expensive, storage space also cost a lot of 
money, and if a message was too big the client would probably crap its 
dacks when it tried to receive it anyway.<br>
<br>
Even a decade ago, 10 Mbyte limits were the norm. You’re currently happy
 with 16 Mbytes, even though all the resources which were extant when 
the limits were first envisaged have scaled by, what, a factor of 1000 
in the right direction?<br>
<br>
You currently have a limit which prevents your users from sending a RAW 
format image off their digital camera as a file attachment. That seems 
unusually small to me.<br>
<br>
Is there any specific reason why you couldn’t update it to 1 Gbyte?  If 
you had allowed it to grow at the same rate as bandwidth and 
Mbytes-per-dollar storage costs over the last ten years it’d probably be
 closer to 10 Gbytes by now, so setting it to 1 Gbyte is an order of 
magnitude less than organic growth.<br></blockquote><div><br></div><div>We
 have an in-house (but publicly visible) file transfer service (a 
corporate drop-box, if you will).  Because apparently 
uploading/downloading from this service uses significantly less 
bandwidth than it would use to transfer the file via email, and the disk
 space on the server dedicated to this service is much cheaper than mail
 server storage.  And maintaining two systems is easier and cheaper than
 maintaining one.</div><div><br></div><div>Yes, there may be sarcasm in 
that second sentence.  And the third one.  Alas, I don't make the 
decision in this instance.</div></div></div></div>


  <pre wrap="">_______________________________________________
AusNOG mailing list
<a class="moz-txt-link-abbreviated" href="mailto:AusNOG@lists.ausnog.net">AusNOG@lists.ausnog.net</a>
<a class="moz-txt-link-freetext" href="http://lists.ausnog.net/mailman/listinfo/ausnog">http://lists.ausnog.net/mailman/listinfo/ausnog</a>
</pre>
</blockquote>
<br>
</body></html>