[AusNOG] Current "Best Practice" WRT email size

[John Lindsay]

I have had this discussion with both customers and the managers and staff running the mail servers.

There is no right answer but I observe Apple iCloud state limits for their service which they are at pains to describe as _personal_ as:
	• The total number of messages you can send each day (200 messages)
	• The number of recipients you can message each day (1000 recipients)
	• The maximum number of recipients per message (100 recipients)
	• The size of incoming and outgoing messages (20 MB, up to 5 GB with Mail Drop turned on)

The problem businesses face is that their staff are motivated to get stuff done and get it done quickly. If the corporate mail server won’t handle the message they go use gmail, iCloud and/or DropBox or similar.

If you want to be in the business of providing a service to your paying customers then provide a service that is useful to them and don’t dictate terms because they have options and they will choose the one that gets stuff done and gets it done quickly.

Cheers,

jsl

John Lindsay
johnslindsay at mac.com
+61403577711

> On 26 Nov 2015, at 12:50 PM, Grahame Lynch <grahamelynch at commsdaymail.com> wrote:
> 
> At CommsDay we send attached PDFs to thousands of corporate customers daily.
> 
> There are a few who balk at anything over 500k. We would never send an attachment over 1 Mb in a mass format. We have to work with the lowest common denominator as our emails are for "paid subscriptions"
> 
> It's not just about what is technically possible but also what "looks like" spam. A bunch of emails with big attachments hitting the same domain at once looks like spam under such policies.
> 
> On 26 November 2015 at 09:10, Ross Wheeler <ausnog at rossw.net <mailto:ausnog at rossw.net>> wrote:
> 
> On Thu, 26 Nov 2015, David Hughes wrote:
> 
> Please pull it back to something with operational relevance.
> 
> Not sure if this is "operationally relevant" or not, I hope so...
> I've spent several hours over the last few days trying to find some "authorative", current, relevant guide as to what is considered "best current practice" guidelines for email attachment sizes.
> 
> 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?
> 
> 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".
> 
> Of course, he doesn't care about any operational issues, about the fact that even if I did increase my server to that size, "most of the rest of the world" wouldn't accept his mail and it'd bounce back anyway. Turns out, he's "mostly" expecting to receive these files... and the "undeliverable" mail he was complaining about didn't even leave the other parties ISP! (Try explaining THAT to someone who doesn't want to know!)
> 
> Lots of places still seem to have a 10MB limit, some smaller, some greater, but generally still in the low-tens-of-megabytes range.
> 
> Would love to find a reference - partly to keep myself up to date with what everyone else is doing, and partly to be able to point this guy to so it's not just "Ross saying no".
> 
> Thanks,
> R.
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net <mailto:AusNOG at lists.ausnog.net>
> http://lists.ausnog.net/mailman/listinfo/ausnog <http://lists.ausnog.net/mailman/listinfo/ausnog>
> 
> _______________________________________________
> 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/99595d44/attachment.html>