Re: [SAGE] choosing the proper max SMTP message size

[Brad Knowles <brad@xxxxxxxxxxxxxxxxx>]

On 1/2/08, Gary Richardson wrote:

>  My feeling is that modern servers and software can handle large messages
>  sizes easily.

On individual messages, sure.  But a 500MB attachment being sent to 
all 100,000 people in the company?  Okay, so I actually only 
personally ever saw someone sending a 50MB attachment to all 1000 
people in the company, but that's still an instantaneous growth of 
50GB of disk space, which is a *huge* chunk of work to do in a very 
short time.

Oh, and then there was the guy who was sending his entire CD and DVD 
collection by e-mail to another person outside of the company, in 
chunks of 500-700MB each.

>                 Bandwidth typically isn't a problem either, unless you're
>  trying to cut bandwidth costs.

Many companies have small remote offices that might be connected back 
to the main office via MPLS or fractional T-1, and only have 64Kbps 
or 128Kbps available to them at any one point in time.  Smaller 
companies may have xDSL for their remote offices, but when you start 
talking about large numbers of copies of gargantuan-size messages, 
there is no amount of bandwidth they could reasonably have that would 
be sufficient.

>                                  Even then, mail servers  accept the
>  message before they calculate the size, so the message has already
>  been transfered once.

Modern MTAs and clients will tell the remote end how large the 
message is before they attempt to send it, as part of the standard 
ESMTP extensions.  So, you can at least reduce the bandwidth cost for 
those things where you know beforehand that the message would fail 
before being completed.

>  The bigger issue I have experienced is that mail clients don't handle
>  large attachments well. Outlook is crashy to begin with, but opening a
>  message with a 100MB attachment is painful.

Back in 1999, I was seeing people casually sending around messages 
using Outlook with 50MB+ PowerPoint slide attachments.  These usually 
had lots of unnecessary and worthless audo and video crap embedded, 
and were frequently done for things like explaining the vision, 
mission, and product plan of the company to the customers.

Those messages would, in turn, be sent by upper management to all the 
employees of the company, and yes each and every person *MUST* have a 
private copy sitting in their personal mailbox, they weren't allowed 
to put this stuff up on any kind of internal webserver or anything.


Note that this was for the largest ISP in Belgium, and all those 
users had direct 100Mbps connections to the company backbone where 
the servers were connected.  It was not uncommon for the primary mail 
server for all of our hundreds of thousands (and later, million+) 
customers to be taken down for extended periods of time (in some 
cases, hours), just to try to clean up the latest instance of this 
kind of crap.

>                                               Pulling a 10mb+ attachment
>  from an IMAP server into Mail.app isn't smooth either.

I knew there was a reason why I still liked POP3.  ;)

>                                                          About the only
>  mail client I've used that handles large attachments will is gmail (or
>  any other webmail client for that matter). I suppose that doesn't
>  count either, since it's really just a webpage.

Yeah, doesn't count.  You still have to store all that crap on the server.

--
Brad Knowles <brad@xxxxxxxxxxxxxxxxx>
LinkedIn Profile: <http://tinyurl.com/y8kpxu>