Average users don't really know what to do. They delete messages (even "good" ones) when their archive grows beyond what their tools (i.e. client+connection+server) can manage.
Then they really don't _need_ them, do they now??
(Sorry. *slaps mouth* -- But really, IMHO, people who care that little about their mail, don't have any need to do much more than read it and delete it anyway. My real question to _them_ is why bother with IMAP anyway??)
But anyway... Try putting up a comment (in a FAQ?) to your users suggesting that they group emails by topics if they have more than a few thousand in a single mailbox. They really should be reading some documentation anyway if they're seeing problems. -- Not that an average user is likely to, but they should be.
Or how about this...?
Average users could also be provided a server-side option (if you wanted to write it, that is) whereby every so often the mail server would run a script to check the sizes of their mail folders, if the setting was turned on.
(It could be turned on/off via a web CGI-controlled property of their LDAP entry, or by a special 3-5 line PERL-based IMAP script they can download to setup a pre-defined folder/message/flag in their mailbox if they want the feature, or... well, practically anything along those lines. -- Of course it'd be even easier if IMAP defined flags for Mailboxes and not just for messages... but *shrug* if you use LDAP/SQL authentication it shouldn't be a big deal to add an attribute. Otherwise, it'll take some thought how to _hide_ the particular "indicator message" that the server script needs from the users' view. -- Actually, maybe a special file could be dumped in the maildir... ...uh... What kind of things are ignored in a maildir anyway? I guess I should read up on that. hmmm)
Anyway, the server then just periodically (via cron every week? 3 days? month?) runs a script during off-peak times to check the size of every maildir, and if the feature is turned on for a particular user, any of their mailboxes (they probably only have their INBOX anyway if they use this feature!) that has more than say 5000(?) messages will have the oldest (oldest by IMAP/maildir internal date, not MIME header date, in case of badly "Date"-ed mails) 3000 or so moved into a subfolder with a special sequential name of some type. The subfolders created could use date-based names maybe, or an incremented "Mail Archive xx", or... whatever you might prefer really.
I mean, really... if they don't care about their mail well enough to know the "good" messages from the "bad" then they don't care how it's handled very much, do they? -- Just so long as it's available to them, right? -- And honestly, this kind of thing is a fairly good/simple way to handle mail archiving, IMO. Even your above-average users might like to use the feature in some cases... just to simplify their organization of mail. *shrug* You never know.
How many people actually use and have need to access 10-20,000 messages *actively* over and over from just 1, single, solitary folder? I mean, really?!
This question is really the moral answer to this thread: whoever does so
is not being well supported. The technical answer is beyond IMAP protocol.
Sam already did a timid proposal by letting the web client create monthly
directories for archiving purposes. That solution does not compress
unused e-mail messages, doesn't even record which messages are being
read, nor how often they give positive search results. Does not record
what messages are spam. All that is not relly the job of an imap server,
it is a mail archiver. I don't have one, I rarely see a good one, and I
never heard about using such a tool for private mail.
You're absolutely correct. Archiving has nothing to do with the IMAP server. Not directly anyway.
If these are the only users you see having problems with overloaded mail folders, then you really don't have a maildir problem... you actually do have a mail archiving problem. And I'm glad you seem to recognize that. :)
Will Courier have an integrated archiver, one day? Ciao Ale
Why not write one? It doesn't have to be (particularly) complex. Just has to either understand Maildir so it can move messages about (reuse maildir code from the other courier servers?), or connect via IMAP itself (PERL, Java, Python, etc. should all support IMAP access with built-in or readily available modules) to move the messages around after checking their timestamps.
*shrug* It's a thought anyway.
-jab
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
