Summary:
Should IT impose file size limits on email users? While limits can help IT manage the beast that is enterprise email, they also can hinder business processes. Perspectives from those who deal with this issue everyday, email-focused VARs.-------------------------------
"
[Should] security and stability of an email infrastructure be a separate issue from whether Beth in accounting, or Pete in marketing, or Ed in Editorial can store 200 Mb worth of email or 2 Gb worth of email," asked Edward F. Moltzen of
CRN on a July 14th
article.
Ah, the
conundrum of
email size limits. Should it be set? What limit is reasonable? How would the limits impact actual business processes? What happens to the limits when the email (attachment) size gets larger, as it always does?
Stripping away all the rhetoric, the gist of the problem with message size and in-box limits comes down to the attachments. After all,
nobody is going to
compose a
10MB email purely
in text; it’s the large
attachments that
hog the
resources. Exacerbating the problem is the common
moral hazard of not just sending attachments, but sending them with numerous CCs and BCCs, because the capability is there.
Theoretically, there is no technical reason why email cannot be designed to be robust enough to handle unlimited size. However, the problem of building an email solution that does it well is that it has to be architected specifically with this requirement in mind from the start. Adding to this Herculean goal is the IT truism that what is considered
large size today is often the mere
starting size tomorrow.
Now, let's face the facts here. Nothing is more
core than
email in most of today's
business processes. The surest way for IT to rouse the ire of the bosses is when there is an email problem. Under the motto of
if it ain’t broke, don’t fix it, no sane IT department of an enterprise with a keen
sense of self-preservation is going to push the envelop on the email front. So, it is theoretically possible and technically feasible to allow unlimited size, but it is not going to happen, given the current code base for both
Exchange/Outlook and
Domino/Notes.
So, what do the
email-focused value-added resellers (VARs), who are paid to confront and resolve such issues everyday, do? What our (Accellion’s) email-focused VARs are telling me is that looking at the issue as a purely email size limit problem is a myopic way of framing the problem. Namely, take a step back;
email is nothing but a tool to get things done. And, the key thing that users are really asking for with large email size is the ability to easily exchange large file/attachments as the business process requires.
What we are seeing in actual field usage is that while limiting the size of messages and in-boxes is a
common practice, these limits have the undesirable effects of
restricting legitimate business processes that require large emails/attachments. Sure, there are the
FTP sites,
USB key Sneaker-Net, and the good old fashioned
CD/DVD burners -- but nothing comes close to email's ubiquity and ease of use for end users. So, the question is not so much how/what size limits to impose. Rather, it is about how to let users operate in an efficient manner with increasing attachment sizes without requiring extensive and on-going contortionist trainings for both IT and end users.
We are seeing an increasing number of
email-focused VARs adding
Accellion Courier Secure File Transfer Appliance (
SFTA) to their arsenal because it allows end users to use the familiar email application to get things done, while offloading attachments from email servers to a complementary secure file transfer appliance for IT's ease of management and ease of mind. As a result,
happy users can go about their business without the frequent disruption of dealing with email limits, and
IT (and the
VAR) can look like a
hero for solving an enterprise problem with a simple solution.
In life.
No pain is gain,
sometimes.
ACA Guy
