""[EMAIL PROTECTED]"" <[EMAIL PROTECTED]> said: > Just want to add my take on this subject. It's related to the IMAP > access control but more in a global way and not on a per-user basis. > > It would be real nice if there was a way to disable IMAP search > capability within dbmail using a config line in dbmail.conf. > > The reason is that no matter how much optimization goes into IMAP > search, it's just way too slow and overload the backend too much for the > feature it offers. Even with fulltext search enabled, the performance > issue will not go away as IMAP folders can easily contain 10s of > thousands of entries.
Sounds reasonable. But if we're going to start partitioning off features, we should adopt some rationale about how we do it. What if someone wanted to allow SEARCH, but only header searches? That would involve checking configs fairly deep down in the imap parser, which is already a cobweb of hackery. Even if we replaced the imap parser with something more easily worked on, would we even want to allow for disabling such minutiae? [snip] > This can be done by adding the following fields to the users table: > > can_imap (obvious) > can_pop (obvious) > can_sieve (is allowed to have sieve scripts (for later, when Sieve is > implemented) If we want to do this per-server, per-clientid and per-user, we probably need a separate table... I wouldn't want to clutter up the users table with multiple rows of these, nor the config table with user and clientid information. So, new table it is? Aaron
