Dealing with users that like to leave HUGE mailboxes on the server

webquarry

Verified User
Joined
Mar 19, 2004
Messages
171
I'd like to hear anyone's strategy for dealing with users that like to leave huge mailboxes on the server and then access those mailboxes via imap...

As you know, the mbox format is DA's weakest link. Under a qmail (maildir) system I can easly write a script to toss read mail after a couple of months. That's not so easy with mbox.

Any suggestions?
 
If I touched my users email, they'd crucify me. I email them and politely ask that they clear it out - after I explain the IMAP problems.
 
hostpc.com said:
If I touched my users email, they'd crucify me. I email them and politely ask that they clear it out - after I explain the IMAP problems.

I agree there. On some qmail systems that I administer, they have me archive read mail that is older than 6 months. The user can still get to it but it doesn't clog up their mail folders. Old mail is covered in their policy to that effect anyways. Or course your solution doesn't stop anyone from DOS'ing the server simply by setting a catchall mailbox and leaving it to collect junk mail for a few months and then attempting to open it a few times via squirrelmail...

I think it is better to have the problem dealt with BEFORE it becomes an issue. Perhaps tweeking squirrlmail so that it won't read files over a certain size or something to that effect.... That would encourage them to keep things lean and mean.

Anyone have any ideas?
 
Switch to courier using the howto on these forums :p

But back to serious. If its part of your terms of service that the mailbox will be raked for spring/summer cleanings (you might call it), making your customers responsible for saving the mail to a different location, then you could create a perl script to read through each users mailbox, identify if the email has been read and how old it is, if it matches simply remove from the mailbox file

Thankfully this hasn't been an issue so far for me however if it did become one, I would consider it My problem and not the customers since I don't limit email other than that of their parent account (except spamming of course).
If it became severe I would switch to courier regardless of DA's stand on it. Just because they don't officially support it doesn't mean it won't work. :cool:
Email is also sacred for us you could say what the user does with it is not my business unless abuse is detected that causes problems for others on or off the server.
 
Last edited:
So are you implying that much of the problem stems from DA's choice of imap daemon then? What do they use, wu-imapd?
 
I've only had this twice so far.
One time with my own e-mail account, which now transfers all mail older than a month to a different location on our own intranet.

One time with an reseller I know quite well, he forgat to set his mail client back to fetch and delete instead of fetch and leave on server. Even with pop3d it was really noticeable.
He changed his setting back, and after that I haven't had much problems with it anymore.


But if I would get problems with it again, I'd politely ask the customer to transfer it offsite, even if I have to explain the problem DA has...
 
Shouldn't disk quota stop this from happening?

And what is the problem imap accounts specifically that leave tons of old email?
 
We actually have some users who leave their mail on our servers on purpose, and have over 1Gb email accounts.

On our existing system, it uses Qmail (like Plesk), and when they check email the IMAP daemon (courier) goes a bit high on CPU usage for a short while, while courier software reads in the directories/files.

But I guess with DirectAdmin, a 1Gb email account would literally crash the server, right? Those users have email since like 2000, so we cannot force them to delete their messages. And with mbox, i dont think it would even help to make new directories, like with the Maildir format, right?
 
I'm answering only the last part of your post:

mbox format does create separate files, one for each directory.

I'm of the rather firm opinion that 1G mailboxes (probably less than half that size) should not be maintained on mbox, but rather in Maildir.

I don't see it as a problem because I consider webhosting to be webhosting, and I believe that folk who have greater email needs than the limited email support we give them with webhosting can buy other products from us, products which do use Maildir.

Jeff
 
jlasman said:
I'm answering only the last part of your post:

mbox format does create separate files, one for each directory.

I'm of the rather firm opinion that 1G mailboxes (probably less than half that size) should not be maintained on mbox, but rather in Maildir.

I don't see it as a problem because I consider webhosting to be webhosting, and I believe that folk who have greater email needs than the limited email support we give them with webhosting can buy other products from us, products which do use Maildir.

Jeff

I've been searching, but is there any real disadvantage to mbox vs Maildir? Any reason DA is married to the mbox format perhaps?

We offer an entire system for people to conduct business on. Email is pretty integral to that... especially keeping email records, etc. so I can understand people NOT wanting to delete older email (unless it is really old, like 5 years or 10 years old, then better put it in the archives).
 
The disadvantage to mbox is when users have lots of messages. The imap server has to parse through the entire mbox file to retrieve a single message. In general, the maildir format provides better performance due to not only the format but also the MDAs that support it.

DA is married to mbox because the conversion to maildir is a major one and backwards compatability would be a mess.
 
Well if DA released a major upgrade v2.x I guess we might get maildir in that.

I have in the past manually done a mbox to maildir conversion on a server and I think its just the case a script needs to be made that will universally work on all servers. No easy task I know. But its not impossible to do.
 
I can think of two other advantages to Maildir rather than mbox format:

1) with mbox format you cannot receive email while your pop or imap client is reading your mbox file, so the server will temporarily delay receipt of mail to a mbox format mailbox that's in use for reading.

2) Since mbox defines the start of an email as a line beginning with:

From

followed by a space followed by anything, any lines beginning that way in an incoming email will have a ">" character appended to the beginning of the line to avoid it being read as a break between emails. Perhaps you've noticed this and wondered why; if so, now you know.

Jeff
 
jlasman said:
I can think of two other advantages to Maildir rather than mbox format:

1) with mbox format you cannot receive email while your pop or imap client is reading your mbox file, so the server will temporarily delay receipt of mail to a mbox format mailbox that's in use for reading.

2) Since mbox defines the start of an email as a line beginning with:

From

followed by a space followed by anything, any lines beginning that way in an incoming email will have a ">" character appended to the beginning of the line to avoid it being read as a break between emails. Perhaps you've noticed this and wondered why; if so, now you know.

Jeff

Hehe didn't realize that. I've really only worked with the Maildir format (right now using Courier), because from the start everyone was saying how poor mbox was, and how Maildir was "the way to go". From what everyone is saying here, I guess I was right the first time around using Maildir.

I've been researching on this forum/board, and I see there is a thread on how to convert over to Courier and that, but since DA doesn't internally support Maildir or is against Maildir, is that wise?

This MIGHT be a deal breaker and may force us to use Plesk (gawd i hope not, i like everything else about DA).

Even for our own emails, we have like 5-10 computers at any one time all checking and syncing mail using IMAP, and they are all checking the same email accounts like sales, support, etc. So if you say mbox will block further emails (which makes sense, since the OS must block it from reading/writing a single file at the same time), then even our own corporate email won't work using the mbox format from what you've said, or at least won't work properly, because if timing is bad, and the computers are all checking emails about sequentially, new emails and stuff will never get delivered or greatly delayed at least?
 
Maildir has it's own issues as well... the main one being that you'll have a separate file for every email; you might use tens or even hundreds of thousands of directory nodes devoted to email; you could even full up hard drives that way.

You're right in that when a mailbox is locked no one else can download it, and yes, that could cause delays. It was because of the limitations of mbox that Maildir was invented.

But Plesk?

Then you'll use qmail; a mail transfer agent that hasn't been updated by the author since 1998.

I've never tried the suggestions in these forums for implementing Maildir. I don't know if anyone has been totally successful with it or not. The biggest issues will be keeping the required programs up to date, and managing the changes required to /etc/exim.conf.

Jeff
 
Am I right exim can work with maildir so it could be done so that courier replaces pop and imap with exim still used for smtp, So I guess a plugin could be developed which installs courier and does the email conversion. That way DA don't need to change the core control panel and administrators have the choice which they want to use.
 
Care to try it?

I've read every thread mentioning Maildir, but I'm not willing to take the plunge on my production servers.

If you are, we'll be happy to read of your results.

Jeff
 
I got no problem trying to get a working solution with maildir and courier but I wont be able to develop a plugin I lack the coding skills.
 
I don't think it makes much sense to write a plugin for something that only has to be run once.

I think a script would be alot better idea.

If you can record everything you've done in a working switch, we can probably figure out how to script it.

Jeff
 
Agreed.

The script I wrote to do the complete conversion works well for me, but it has yet to be tested on a populated system.

I'm working on a Centos 4 x86_64 version now based on the current courier-imap codebase. This is almost done... again, let me know if you'd like to test it.
 
Back
Top