[AusNOG] Current "Best Practice" WRT email size

[Shane Short]

paul+ausnog at oxygennetworks.com.au wrote:
>
> Whilst it’s fine to say that the SMTP servers and general bandwidth 
> capacities of ISP’s can easily handle larger messages you also need to 
> take into account the large majority of businesses that still run on 
> ADSL2, if you allow large messages then you destroy that bandwidth for 
> 10 mins or whatever depending on the size, that all impacts the 
> productivity of all users on the site.
>

You're doing this any way, because they have to send the entire email 
before you decide it's too big and reject it-- assuming you're doing it 
at SMTP time, I've seen people who don't and send the ENTIRE email back 
as a bounce. But the congestion surely becomes a network engineering 
issue then, right? Isn't this what we're paid to fix?

And how exactly is this any different from dropbox? You're still needing 
to get that big file out a small pipe, the medium is (largely) irrelevant.

> I know other things like dropbox and the like won’t help with that but 
> I think it’s more of an education requirement about the possible 
> issues with larger transfers of data rather than the question of 
> should I, or should I not allow large emails.
>
> Paul
>
> *From:*AusNOG [mailto:ausnog-bounces at lists.ausnog.net] *On Behalf Of 
> *Robert Hudson
> *Sent:* Thursday, 26 November 2015 1:37 PM
> *To:* Mark Newton
> *Cc:* ausnog at lists.ausnog.net
> *Subject:* Re: [AusNOG] Current "Best Practice" WRT email size
>
> On 26 November 2015 at 13:25, Mark Newton <newton at atdot.dotat.org 
> <mailto:newton at atdot.dotat.org>> wrote:
>
> On Nov 26, 2015, at 1:10 PM, Ross Wheeler <ausnog at rossw.net 
> <mailto:ausnog at rossw.net>> wrote:
> > 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?
>
> It goes to where the users demand.
>
> 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?
>
> > 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”.
>
> Go back to the question, “Why does the limit exist?”
>
> 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.
>
> 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?
>
> 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.
>
> 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.
>
> 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.
>
> Yes, there may be sarcasm in that second sentence.  And the third 
> one.  Alas, I don't make the decision in this instance.
>
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20151126/a84842ec/attachment-0001.html>