Quota-less Mailboxes are BAD, ummkay!

One of the questions that loves to ask during his presentations is how many administrators in the audience don't have any mail quotas set for their users.  He usually gets a fair number of hands going up and it makes him smile.  He is a big proponent of not putting quotas on users' mail files and his reasoning is sound.  Good thing he doesn't work for MicroSloth.

Ross Smith has written an article on the Microsoft Exchange Team Blog that sums up a number of the differences between Domino and Exchange environments.

Many customers tell me that they do not impose mailbox and/or message size limits on the vast majority of their user population. This poses a problem because you will never be able to adequately design a storage subsystem or maintain the desired database size limits, let alone meet any service level agreements that may be in place.

Additionally, most of these customers do not have defined, measurable, and actionable Service Level Agreements (SLAs) or Operating Level Agreements (OLAs) in place to manage user expectations (i.e. messaging as a service), and thus cannot measure a real cost/benefit with regards to the user population demands.  Ultimately, the lack of mailbox size limits and message size limits can lead to instability in the messaging architecture.

So let me understand this if I can: unless are implemented, it is impossible to design or maintain a stable Exchange environment.  I might be able to agree with the need for message size limitations (we all have horror stories of the marketing team trying to send out 20 MB presentations to the whole company and crashing a mail server in the process), but the fact that you lack mailbox quotas will lead to your system becoming unstable is an absurd statement, even if it is true. The only reason I ever like to impose mailbox quotas is when we are tight for disk space and are waiting for more to be installed.  Since Domino is not reliant upon a like Exchange, the problems with disk space are things that can be easily monitored and solved by throwing money at the problem.  Disk is cheap!!  And any performance impact is on a mailbox by mailbox basis.  An accounting user with a 25 MB mailbox isn't impacted if the VP of HR let's her mailbox grow to over 1 GB.  The other thing to remember is that mailbox performance is impacted greater by the number of emails rather than the size of the mailbox.  The more emails you have, the larger the view and folder indexes have to be and the longer they take to update.

Ross goes on to point out a number of reasons why not having quotas are a bad thing.  Most of his ideas point to the main problem with Exchange in most organizations:  it is no longer a tool to enhance a user's productivity.  Does making a user worry about keeping his mailbox below a certain size make him more productive?  Does searching looking through multiple PSTs to find some long lost email make a user more productive?  Does the loss of email in PSTs due to a hard drive crash or laptop theft increase productivity?  The more limitations you have to impose on users just to allow your system to stay up and running severely hinder their productivity.  It is the same problem when companies try to implement "kill all email older than x days" policies to try to reduce their exposure to litigation.  The sooner the management of a company sees email as a productivity tool and treats it that way, the better off users will be.

If you can afford the hardware, there should be no limitation on mailbox sizes.  Since Domino does field level replication, the size of a mail file will have no impact on the amount of data being transmitted over the network during se rver to server or client to server replication.  One thing you do have to keep in mind is that disk is not the only cost, but backup media, backup time, and restore time is also impacted when the size of the mail stores grow.  Depending on your backup solution, SLAs may have to be written to take mail file sizes into account. 

<< Previous Document / Next Document >>
  • 1) Storage ain’t always cheap - Scott Gentzen
    Created 7/10/2006 8:59:47 PM email | website

    Disk is cheap if you're running your email environment on a pile of cheap hardware.

    I'm no apologist for Microsoft or Exchange, but if you're running on a big SAN, it isn't always as easy as throwing disks in the box. Yeah, it's still a matter of throwing money at it, but between hardware and time it's still not cheap.

  • 2) Compared to what? - Sean Burgess
    Created 7/10/2006 11:48:50 PM email | website

    These days, it seems that nothing is as cheap as everyone says or thinks it is. That being said, is it cheaper to buy more disks when you need space or to buy new servers and have to constantly move users around to different mail stores or servers just to keep the system up and running? And how much is peace of mind worth to you and upper management? Plus, how much does an administrators time cost when he/she and their team have to re-architect the mail environment on a regular basis? As an administrator, there is nothing better than to be able to leave the office and not have to worry about whether the servers will go down during the night and the article made it seem that 4 nines of up-time is something that you have to work hard at to achieve with Exchange.

    At the end of the day, the lesser of all the evils is buying disk.


  • 3) It is a bit theoretical - YF Juan
    Created 7/19/2006 8:42:37 PM email | website

    HD is cheap relative to most other solutions. True. However, it is also true that throwing HD at the size problem has its limits. For example, we have customers who come to us after end users try to send a 1GB file to several people - the file is large but it is for perfectly good/everyday business reason.

    Never written an email solution myself, I am not in the position to comment on the internal workings of most email systems. But, while I would readily accept the argument that a well design email system should be able to do a lot of things - including having no size limit, the reality is also that email has become such a mission critical core system for most enterprises that there is simply no incentive to "push the envelope" in that manner for any sensible IT department.

    I think what is important is for people to take a step back and think about what is the intent as oppose to the technology. The idea is for end users to share (large) files with (many) recipients without causing IT headaches. So, a solution that allows for "attachment offload" is actually the ticket. Naturally, I am biased, but it is also true that many a Lotus Notes shops are coming to us for our secure file transfer appliance solution for this precise reason.

    Regards, YFJ

  • 4) Re: Theoretical - Sean Burgess
    Created 7/20/2006 7:57:48 AM email | website

    I totally agree with putting limits on the size of attachments being sent via email. I have built a number of applications that provide users a way to distribute attachments to groups of people by storing the attachment on the server and sending out emails with links to them. It's quick, painless, and, because it's Notes, secure.

    But the problem with attachment offloading comes when a user tries to search for an email. Without the attachment, sometimes it's hard to find the email you were looking for via full text search. But I guess that's a problem that only Notes users face since Exchange/Outlook doesn't have full text searching.

    My problem is not with the person who complains about not being able to send a 1 GB email attachment, but rather it is when a person who received 100 1 MB emails is told they need to clean out their inbox or, worse yet, blocked from receiving any mail until the problem is resolved. With many Exchange shops setting limits of 100 MB or less (the lowest I have ever heard of was 20 MB), it is almost impossible to use Outlook as a productivity tool since you are constantly having to move all your mail to local pst files.

    And I hate to say this but no user is ever going to step back and think about how they should be using a technology. They simply have a problem that technology should be solving and they don't want to worry about whether or not they should be doing it.

Discussion for this entry is now closed.